22 September 2017

TE-204 (Rockwell AN/USC-11) 75Bd in-band frequency and time diversity HF modem

TE-204 (AN/USC-11) is most commonly used by Allied Air Forces as an air-to-ground messaging system as well as in ground and naval applications. The transmission was heard on 11220.0 KHz/USB, HF-GCS frequency, at 2145 UTC.
The modem converts the incoming serial binary data stream into an FSK audio signal at baseband and appears on-air as MFSK-4 150Bd/440Hz (Figure 1) although the real transfer speed is 75 Baud (75 bit/s in synchronous mode, 75 baud using Baudot chars in the async mode): the reason is in the "in-band frequency and time diversity" mode used by this modem.

Fig. 1 Over-the-air parameters
Four data subcarriers are used at 935 Hz through 2255 Hz with tones spaced every 440 Hz: TE-204 transmits a "mark" on 935 Hz for 6.67 msec period followed by another 6.67 msec period at 1815 Hz. Similarly, a "space" is transmitted at 1375 Hz for 6.67 msec period followed by another 6.67 msec period at 2255 Hz (Fig. 2).

Fig. 2 in-band frequency and time diversity mode
This effectively provides an in-band frequency diversity function for each data bit while also transmitting the same data bit over two(!) separate 6.67 msec periods of time, thus achieving a in-band frequency and time diversity function while transmitting only one tone at time (so the speed is the half of the measured one). As for above, from the perspective of the data-transfer, the modem works as a FSK-2 75Bd/880Hz modem.
No special preamble or SOM/EOM codes are employed, decoding the signal as in the depicted mode will be possible to get the 64-bit KG-84 sync sequence.
By the way, the TE-204 modem is embedded in the  Rockwell Collins MDM2001 Multimode HF Modem.

18 September 2017

unid STANAG-5066 RCOP/UDOP client, Swedish Army (update-3)

wrapper protocol MTU and data-block length 
As shown in Figure 1, if the length of the data-block is longer than the max allowed value (1977 bytes in this case) it is segmented into smaller blocks. The timestamp header in the segmented block remains unchanged while the current data-block number and the data-block length are updated. The data-blocks are not filled if their length is smaller then the maximum allowed value. [1]
Fig. 1
Moreover, the maximum lenght of the data-block changes according to the length of the Source/Dest IDs, as shown in Fig. 2
Fig. 2
Now let's have a look at a D_PDU which transports the wrapper protocol. The S-5066 D_PDUs are visible once removed the 188-110A overhead and synched the bitstream on the sequence 0xEB90 (all D_PDUs, regardless of type, begin with the same 16-bit synchronisation sequence).
As shown in Fig. 3, the Application Data, ie the data coming from the S-5066 client application (our wrapper protocol), begin just after the Application Identifier field of the UDOP/RCOP U_PDU. It's worth noting that  the Apllication Identifier is "0x8008", that just belongs to the values which are available for user-defined applications (S-5066 Annex F, table F5).
Fig. 3
So far I found the same 4-byte sequence "00 00 00 01" for both RCOP and UDOP protocols and, in my opinion, it is a sort of identifier of the wrapper protocol PDU (Fig. 4)
Fig. 4
Given the initial 4-byte "identifier" and the lengths of all the headers, the Maximun Transmission Unit (MTU) of wrapper protocol is equal to 2039 bytes for both RCOP and UDOP protocols:

4 + 56 + 1975 + 4 = 2039 bytes

4 + 54 + 1977 + 4 = 2039 bytes

As for above, the maximum lenght of the data-block must vary according to the lenght of the sender/destination IDs and the used timestamp format (9 or 10 digits):

*10-digit timestamp {10,2367731361} (15-byte length)
1975 bytes (Dest ID = 5 bytes)
1977 bytes (Dest ID = 3 bytes)

*9-digit timestamp {9,nnnnnnnnn} (13-byte length)
1977 bytes (Dest ID = 5 bytes)
1979 bytes (Dest ID = 3 bytes)

It's interesting to note in Fig.5 that in case of use of UDOP protocol each D_PDU is transmitted twice unless the last. This makes sense to improve the reliability, since the nature of UDOP protocol itself (a basic connection-less protocol) and the use of S-5066 non-ARQ service.
Also note in Fig.5 that the C_PDU is segmented into 200-byte size C_PDU segments (each segment will be encapsulated in one D_PDU !): as you see, the overhead bytes added by C, S and U sublayers are present only in the first segment (although it's repeated).

Fig. 5
Curiosly, the used C_PDU-Segment size (200 bytes) is the same than the one used in the segmentation examples depicted in STANAG-5066 C.4.2 Edition 3, in our case the max size of C_PDU is 2051 bytes (Fig. 6).
Fig. 6

Since the Maximum C_PDU-Segment size within a D_PDU is a configurable parameter, the choice of a 200-byte size and the "double send" of the UDOP D_PDUs are probably a STANAG-5066 configuration implemented to support the wrapper protocol client. 

STANAG-5066 Addresses and "Magic Strings" 
So far, these are the heard S-5066 Addresses and "Magis Cstrings":

[006.046.000.zzz] block

[006.046.001.zzz] block
HEH002     --"--


[1] you may read other posts about this topic by browsing the tag Swedish Army

15 September 2017


05775.0: RCV: Russian Navy HQ Black Sea Fleet, RUS 1912 CW, "RIC87 DE RCV QTC 209 8 7 0915 209 = ..."
06248.8: HWK01: Swedish Armed Forces, S 0632 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, Circuit Mode tfc to PFY using S5066 unid UDOP client (29Ago17) (AAI)
06280.4: HWK01: Swedish Armed Forces, S 0739 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, Circuit Mode tfc to HWK01 using S5066 unid UDOP client (29Ago17) (AAI)
06329.0: OSY: Sailmail Brugge, BE 0620 USB (cf + 1500Hz) Pactor-III, working vessel PG8069  (06Sep17) (AAI) [1]
06424.5: IDR: Italian Navy S.Rosa Rome, I 0825 J3E/USB radio-check with offshore ships, daylight QRG (29Ago17) (AAI)
06733.0: 5UL: Italian Navy ship, I 0935 J3E/USB call to IDR, asking "QRV on F1B" and KG-84 traffic using RATT 75Bd/850 (29Ago17) (AAI)
06873.5: XDV: DHFCS Unid station, UK 0604 USB 188-141A handshake XSS / 188-110A serial modem (29Ago17) (AAI)
06931.0: ---: Unid 0750 USB THALES (prob. TRC-1752) traffic using proprietary S4285 waveform 600bps/L, ARQ mode (29Ago17) (AAI)
06957.0: ---: German red Cross, D 0725 USB PacTOR-I, call to DEK8810 (29Ago17) (AAI)
06980.0: ---: Unid 0712 USB 3G-HF 2-way FLSU handshake / tfc using HDL12 (29Ago17) (AAI)
07401.0: ZEMD: Zollboot Emden, D 0608 USB 188-141A call ZLST (12Sep17) (AAI)
07457.0: ---: Unid 0656 188-110 Appendix B OFDM 39-tone followed by Arabic voice comms (26Ago17) (AAI)
07505.8: ---: French MoD, F 1310 USB THALES HFXL modem tests using 9-10 x 3KHz channels, STANAG-4539 compatible waveform (12Sep17) (AAI)
07520.0: ---: Unid 0715 USB 3G-HF FLSU/HDL failed call (12Sep17) (AAI)
07667.0: ---: Unid 0709 USB 3G-HF 2-way FLSU handshake / tfc LDL512, Harris ' Citadel' encrypted 977-byte file (29Ago17) (AAI)
07692.0: 2LG: Moroccan Police, MRC 2041 USB 188-141A call to 2QH (25Ago17) (AAI)
07776.0: KA37: Unid (Tunisian Net?) 1857 USB 188-141A sounding (08Sep17) (AAI)
07890.0: KB24: Algerian Military, ALG 1613 USB 188-141A call NX10 (09Sep17) (AAI)
07902.0: WARSZAWA1: Polish MoI (MSWiA), POL 0828 USB 188-141A, call to KRAKOW (04Sep17) (AAI)
07930.0: ---: Unid 0619 USB 3G-HF 2-way FLSU handshake / HDL+ transfer (12Sep17) (AAI)
07990.0: HWK01: Swedish Armed Forces, S 0758 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, Circuit Mode tfc to PFY using STANAG-5066 unid UDOP client (12Sep17) (AAI)
08067.0: ---: Russian Mil/Intel, RUS 0717 (cf) FSK 50Bd/500, 128-bit ACF (prob. Moroz) (12Sep17) (AAI)
08079.0: CENTR2: MFA Bucarest, ROU 0657 USB 188-141A handsahake OJP embassy / 188-110A Serial, sending STANAG-5066 email (12Sep17) (AAI)
08132.0: BP21: Bundespolizei Küstenwache Patrol Vessel 'Bredstedt', D 0752 USB 188-141A handshake / R&S GM2100 serial modem PSK-8 waveform, positions report email to BPLEZS using R&S X.25 (26Ago17) (AAI)
08142.5: ---: Unid 0606 USB THALES (prob. TRC-1752), traffic using proprietary S4285 waveform 600bps/L, ARQ mode (12Sep17) (AAI)
08162.0: 035: Hungarian Army, HNG 1356 USB 188-141A handsahake 082 / opchat using HARRIS AVS scrambler (12Sep17) (AAI)
08190.0: CINUS: Guardia di Finanza patrol boat, I 0813 USB 188-141A call to MESSINA (26Ago17) (AAI)
08207.0: AB3: Maltese Navy vessel, MLT 0817 USB 188-141A handshake ABA / voice radio-check using callsigns 0A (for ABA) and O??? (for AB3) (14Sep17) (AAI)
08303.0: IDR: Italian Navy HQ S.Rosa Rome, I 0810 J3E/USB calling IHAN (prob. ship ANTEO) for radio-check, no reply (12Sep17) (AAI)
08582.0: PWZ33: Brazilian Navy, B 2005 (cf) Pactor-FEC 100Bd, navigational warnings, 2026Z s/off (30Ago17) (AAI)
09038.0: GRIFFIN: TF Griffin Camp Bondsteel, HRV 0810 USB USB 188-141A sounding (31Ago17) (AAI)
10368.0: ---: Australian MHFCS net, AUS 1025 ISB: FSK 600Bd/340Hz on LSB, FSK 50B/340Hz on USB (08Sep17) (AAI)
11028.0: CM1: Algerian Air Force, ALG 0812 USB 188-141A handshake COF/ 188-110A Serial, Harris Citadel encrypted tfc (09Sep17) (AAI)
11083.0: RDL: Russian Navy, RUS 0820 FSK/Morse "RDL RDL RDL 22222 0315 0519816 08 16408 6555O ..." (09Sep17) (AAI)
11160.0: ---: Unid 0657 (cf) R&S-ARQ 228.6Bd/170 (ALIS), calling address 210 (05Sep17) (AAI)8JKY
11262.0: JOTA: Spanish Air Force, E 0940 J3E/USB ATC working AME3506 leaving Spanish airspace  (09Sep17) (AAI)
11360.0: KORSAR: Ruassian AF, RUS 0857 J3E/USB radio check with other ground nodes: POLIS, PROSELOK, DAVLENIYE, KLARNETIST, POLOTNOJ, KASTY, MAGNETRON (09Sep17) (AAI)
11450.0: ---: Unid 1519 USB Chinese Navy 4+4 PSK-8 75Bd modem (25Ago17) (AAI)
11478.0: ---: Unid 0820 USB 3G-HF FLSU async call (09Sep17) (AAI)
12129.5: ---: Russian Gov/Intel/Mil?, RUS 0753 (cf) FSK 100Bd/2000, no traffic (05Sep17) (AAI)
12138.8: ---: Russian unid source, RUS 0900 USB MFSK-21/13 tones, 31.5/63 Bd, 125/250 Hz spaced (11Sep17) (AAI)
12151.0: ---: Russian Gov/Intel/Mil?, RUS 0826 USB CIS-3000 PSK-8 3000Bd followed by CIS MFSK-64 (32+32) (05Sep17) (AAI)
12164.0: K4MT: M42b Russian Diplo Network, RUS 0720 CW call "NT9P NT9P NT9P DE K4MT K4MT K" (08Sep17) (AAI)
12164.0: K4MT: M42b Russian Diplo Network, RUS 0736 (cf +1000Hz) FSK 50Bd/500 5FGs msg, followed by CW "QRU ? K" (08Sep17) (AAI)
12200.0: 4MTK: Unid 0834 CW call 9PNT "9PNT DE 4MTK" (05Sep17) (AAI)
12209.0: ---: Russian Gov/Intel/Mil?, RUS 0930 USB CIS-60 OFDM 60-tone 35.5 Bd HDR modem, female voice prob asking QSL (05Sep17) (AAI)
12221.0: ---: Unid (prob. Bulgarian Diplo Net) 0915 USB RFSM-8000 modem using data-masking, tfc with stn operating 5 KHz upper (05Sep17) (AAI)
12464.0: RFH71: Russian Navy LS Novocherkassk (142), RUS 0908 CW msg to RCV Black Sea HQ "RCV DE RFH71 2 9 3 1 5 5 1 2 0 1 2 9 3 K" (05Sep17) (AAI)
12464.0: RFH71: Russian Navy LS Novocherkassk (142), RUS 0721 CW, "RCV DE RFH61 QYT QSX 10984 K" (08Sep17) (AAI)
12464.0: RJI48: Russian Navy (prob. Naval Aviation Transport), RUS 0953 CW msg to RCV Black Sea HQ "RCV DE RJI48 RJI48 QSA2 QRV K" (05Sep17) (AAI)
12464.0: RMX62: Russian Navy, RUS 1003 CW msg to RCV Black Sea HQ "RCV DE RMX62 RMX62 QSA? K" (05Sep17) (AAI)
12949.0: ---: 0738 USB BPSK 19200Bd burst system, 24KHz bandwidth (12Sep17) (AAI)
13062.7: TR: Unid Spanish user 0855 USB voice-call to DP announcing a message is going to be sent (in Spanish language), STANAG-4285 600bps/L with KG-84 encryption (05Sep17) (AAI)
14411.0: RDL: Russian Navy, RUS 0847 (cf) FSK/Morse/250Hz, 5FGs msg: "RDL RDL RDL 36855 52267 36855 52267 36855 52267 K" ("36855 52267" rptd 3 times) // 14664.0 KHz (06Sep17) (AAI)
14440.0: IQNS: Russian Military, RUS 0859 CW msg to 8JKY "8JKY 8JKY 8JKY DE IQNS IQNS ZYW SYL ZNIL QYT9 K" (06Sep17) (AAI)
14462.0: ---: Unid 0812 USB 3-of-6 multitone 40Bd/400Hz modem, sending all symbols set. (06Sep17) (AAI) [2]
14540.0: RJF94: Russian Naval Aviation Transport, HQ Moscow RUS 0859 CW msg to RJF95 "RJF95 RJF95 DE RJF94 RJF94 QSA? K" (06Sep17) (AAI)
14556.0: RIW: Russian Navy HQ Moscow, RUS 0844 CW msg to RJP30 "RJP30 DE RIW QSA? QTC k" (06Sep17) (AAI)
15016.0: ANDREWS: USAF AFB, US 0949 J3E/USB test count "1 2 3 4 5 5 4 3 2 1" (06Sep17) (AAI)
15016.0: SIGONELLA: US NAS, 0952 J3E/USB test count "1 2 3 4 5 5 4 3 2 1" (06Sep17) (AAI)
15157.0: ---: Unid 1238 USB BPSK 4800Bd, unid burst traffic using 6KHz bandwidth (no WBHF) (25Ago17) (AAI)

11 September 2017

MFSK 21/13 tones 31.5/63 Bd (125 and 250 Hz spaced)

unid MFSK modem spotted on 12138.8 KHz/USB, according to the suppressed carrier during MFSK, and switching from 21-tones 31.5Bd (125Hz shift) to 13-tones 63Bd (250Hz shift).  Note also the espansion of the spectrum since the occupied bandwidth varies from 2600Hz (MFSK-21) to 3000 Hz (MFSK-13).

Fig. 1
Fig. 2
Apart from the two edge tones, the MFSK-13 uses the same ten odd tones of the MFSK-21 waveform:

Fig. 3
Transmissions may have different duration, maybe depending on the length of the messages to be sent: from few seconds up to 6 minutes (the longest I copied). Sometimes the transmissions use only the MFSK-21 waveform and two adiacent channels for the peers (maybe ISB?):

Fig. 4

The MFSK-21/13 signal was also copied on 9280.0 KHz (frequency of the carrier) and reported in radioscanner here. They ascribe the transmissions to not well identified "domestic" (Russian?) telecomm operators.


8 September 2017

K4MT/NT9P Net, Russian Intel/Diplo (M42b)

K4MT/NT9P network, also known as Enigma designator M42b, is a quite common Russian Intel/Diplo network which uses both CW-Morse and FSK 50Bd/500: I spotted several trasnmissions this morning on 12164.0 Khz, just before a G3 (strong) geomagnetic storm passing: FSK is transmitted with its cf at +1000Hz.

Fig. 1
In this recording, FSK follows a CW call "NT9P NT9P NT9P DE K4MT K4MT K" and in turn it's followed by a "CFM QRU K" request: most likely the CW is used for setup or operators chat. The FSK is a Baudot 5FG coded stream using a preamble and 7-bit period (fig. 2):

Fig. 2
note the markers at every group of 50 x 5FGs (Fig. 3):
Fig. 3

7 September 2017

unid burst waveform, BPSK 4800Bd / 6KHz Bandwidth

Bursts copied on USB 16975.0 and 17157.0 KHz, in the 16-17 MHz Marine band segment. The waveform uses BPSK modulation at 4800 Baud and a bandwidth of 6 Khz, the copied bursts have a duration of ~386 and ~505 msecs.
Speed and bandwidth lead to think to MIL 188-110C App.C "WBHF" but this standard povides BPSK/4800Bd waveform only for 9 KHz bandwidth.

Fig. 1

Fig. 2

Fig. 3

1 September 2017

PWZ-33 Bazilian Navy and Pactor-FEC frame lengths

Some days ago my friend KarapuZ pointed my attention on a FSK transmission running on 8582.0 KHz/USB and that, at a first glance, appeared a bit uncommon. Once analyzed and decoded it was identified as PWZ-33 ERMRJ (Estação Rádio da Marinha no Rio de Janeiro) belonging to Brazilian Navy and operating in Pactor-FEC at 100Bd/200: just another proof of the "Occam's razor" (simpler theories are preferable to more complex ones).
Given the time we spent on signal analysis and the differences between Pactor-FEC modes, maybe is worth to publish a short post about it.

Pactor-FEC is a synchronous simplex system based on Pactor and used for broadcast transmissions, ie it has no acknowledge return channel and the receiving stations perform error correction. The Pactor-FEC modem uses a FSK 200Hz shift waveform and operates adaptively so the baud rate can be either 100 or 200 Baud: during daylight time the speed of 200 Baud may be successfully used, while in night time, due to the propagation distortions,  the speed may necessitate a reduction to 100 Baud. 
The speed influences the period lenght of Pactor-FEC and due to the positive/negative coding, the BEE software is a bit confused and computes periods lengths as the double of the real ones and shows seemingly equal period lengths in both the cases (Figure 1):

200Bd speed: frame length 194 bits (period: 388 = 194+194)
100Bd speed: frame length 97 bits (period: 194 = 97+97) 

Fig. 1
Indeed, altough Pactor-FEC frames consist of the same fields (header, data, status and 16 bit CRC calculated over the entire frame  except the header) their lengths differ.   As per above: at speed of 100 Baud the data field is 64 bits (8 bytes), while at 200 Baud the data field increases to 160 bits (20 bytes) as shown in Figs. 2,3. 

Fig. 2 - Pactor-FEC 100Bd/200 frames
Fig. 3 - Pactor-FEC 200Bd/200 frames
To increase reliability data are transmitted twice (in positive/negative), as shown by a decoding of a short fragment in Fig. 4

Fig. 4

In contrast to Pactor, all data blocks are in consecutive order with no or little space between them: indeed, Pactor 200Bd has 250-bit length frames (Fig. 5).

Fig. 5 - Pactor 200Bd Vs Pactor-FEC 200Bd
You may find many other informations about Pactor-FEC as well as about PWZ-33 (I'd like to ask QSL: I know they confirm reception reports): this is just a little contribution to shed a bit light on Pactor-FEC.