28 February 2017

a possible variant of the CIS-48 OFDM modem

This signal was copied on 9905.0 KHz/USB at 0922 UTC 22 February, although the poor quality of the recording (it mostly depends on the signal weakness) some interesting characteristics can be obtained from its analysis.
Once the signal has been processed with a pass-band filter, the spectrum reveals the presence of 48 tones (Fig. 1) which are confirmed by the SA-OFDM module: in particular the 48 tones are 62.5 Hz spaced and are keyed at a symbol rate of 50 symbols/sec (Fig. 2); the "magic K" value is very good, ie 1/4, meaning a quite consistent result.

Fig. 1
Fig. 2
The poor quality of this sample does not allow to detect what kind of modulation is used in the channels (possibly 4-ary?) anyway it's possible to see that a special/service symbol, consisting of a certain combination of used/unused & modulated/unmodulated tones, is sent each 102 symbols (Fig. 3):

Fig. 3
The body of the signal is preceeded and followed by 6 tones, the initial ones are modulated with BPSK at 100 symbols/sec (Fig. 4)

Fig. 4
The CIS-48 OFDM modem is mentioned several times in radioscanner.ru forum and my friend KarapuZ, who helped in the identification, addressed me to one of his posts just related to CIS-48:
From these readings I may understand that some variants of this modem are on-air and most likely this is one of these: better and further recordings just of this signal, as well as your comments, would be needed.


25 February 2017

a new S4285-like waveform (most likely a new Iraqi waveform)

The signal appears on-air as a PSK-8 modulation of a 1800Hz single tone, symbols rate is the quite usual 2400 Baud (Fig. 1). ACF is 120 msec, that makes 288 PSK-8 symbols per frame or a 864-bit length period (Fig. 2).

Fig. 1
Fig. 2
The structure of the frame resembles the well-known Stanag-4285 waveform: the initial 63 symbols preamble is followed by four data blocks, each block consisting of 51 unknown symbols (user data) and 7 known symbols (mini-probe); the last block is transmitted w/out the miniprobe (Fig. 3). As said, each frame is transmitted each 120 mesc.
Looking at the constellation, the two pronounced points lead to think to a BPSK modulated preamble which is probably not scrambled (just as in Stanag-4285) and use Walsh modulation (Fig. 4).

Fig. 3
Fig. 4

The recording was sent me by KarapuZ and his friends, translators have identified the language as Iraqi (sometimes voice comms were copied in between the data exchanges) and are inclined to think  to marine coast stations. Transmissions were copied on several USB frequencies such as 7997.0, 8228.0, 8250.0, 8458.0, 8613.0, 17380.0,...

24 February 2017

chasing HAARP

photo from Chris Allen twitter account
On 19-22 February, scientists used the HAARP (High-frequency Active Auroral Research Program) research instrument to conduct multiple experiments, including the so-called "Luxembourg Broadcast" and creation of "Artificial  Aurora". Radio listeners  were able to tune HAARP radio transmissions in real time by following Chris Fallen, Assistant Research Professor in the Space Physics Group at UAF, on twitter during his experiments at HAARP.  
I too tried to  follow the HAARP transmissions on 21 and 22 February and other than a fake transmission I had also a copy, or better a "track", of the 22 February Artificial Aurora transmission: short report follows below.

21 February,  a fake transmission
The alarm clock rings at 0300 UTC (0400 CET), just a coffee and then in front of the radio hoping to catch the Luxembourg Broadcast scheduled for that session/time. Propagation is quite good and I tune alternately to 2.8 and 3.3 MHz (the advertised frequencies), although both the frequencies are under my eyes in the portion of the band displayed in the SDR waterfall. Since the exact frequencies of the transmissions are not known until shortly before the experiment begins, I follow the operational updates published in @ctfallen, a special twitter account.
Looking for the Luxembourg Broadcast on 2.8 and 3.3 MHz, at 0314 UTC I copy a short CW transmission on 2.8, repeated few seconds later on 3.3 MHz (Fig. 1). The Morse coded message is the bare "vvvvv de haarp" which exhibits a wrong keyd "p" (uh?). The too-simple message, the not uniform separation between tones, the wrong "p" and the HAM style of the keyer make me think of an European "joker" and thus of a fake transmission!
I send images and recordings to Chris Fallen and his team, warning about a possible fake transmission by some European joker: initially they tend to confirm the reception, but after further analysis they realize that the copied transmission was really a fake (as supposed).

Fig. 1 - the 21 Feb 0314UTC fake transmissions

22 February,  Artificial Aurora transmission
Too tired to wake up early in the morning, I choose for an off-line listening and program SDR-Console for a timed IQ recording starting at 0330 untill 0500 UTC 22 February. In the afternoon I analyze the file and, given the propagation conditions and the HAARP antennas beam, I decide to read the recordered band using the powerfull QRSS viewer by I2PHD ("Argo"). Since the need to know the exact frequencies, as said, I browse the 22 February operational updates in @ctfallen. Indeed, for Artificial Aurora experiments they have to match the frequency to the specific peak plasma density altitude by operating a low power scanning ionosonde and then pick the main transmitter frequency based on the ionosonde analysis.
At ~0400 UTC Chris Fallen says:
3.4 MHz (and 9.5 MHz probe) tune in! If in Aalaska maybe try to photograph the artificial auroral spot"
here we are: using the IQ file navigator I move on 3.4 MHz @ 0400 UTC to dig the signal ...and I find it: although weak, a track of the Artificial Aurora transmission is visible just in the place and time at which it was to be. Quoting Fallen,  "the broadcast only sounds like a silent carrier wave, as if a radio DJ fell asleep and neglected to change the record" (Fig. 2). Note that the 1025Hz track in the QRSS waterfall is due to the 1 KHz offset (I was tuned on 3999.0 KHz/USB) plus the 25 Hz calibration error of my receiver.

Fig. 2 - the 22 February 0400 UTC Artificial Aurora transmission

Operation of the HAARP research facility, including the world’s most capable high-power, high-frequency transmitter for study of the ionosphere, was transferred from the U.S. Air Force to UAF in August 2015. Research funding agencies include the National Science Foundation, Department of Energy’s Los Alamos National Lab and the Naval Research Laboratory.

For more details on the dates and times of Fallen’s experiments, as well as information, visit:
Information is also available at the HAARP website, the UAF:  
and the official UAF HAARP Facebook page:

Address from The SWLing Post page:

19 February 2017

a 3G Multicast Data Link w/ NAKs?

few days ago, 16 Feb, I copied a 3G-HF transmission on 10958.0 KHz/USB consisting of an initial FLSU PDU (BW5 burst) followed by 13 not-ACKed LDL PDUs (BW3 bursts) and ending with a single BW4 burst: since LDL is a stop-and-wait ARQ protocol, ACK burst were expected. This scenario recalls the 3G Multicast Data Link with NAKs (MDLN) protocol previously copied and reported here (Fig. 1).

Fig. 1
I could not find official NATO/Stanag documentations about the 3G Multicast but only some "proposed" papers; Multicast MDL Protocol is still cited as "still in development" in STANG-4538 Amendment 2 Draft 0.3, the one at my disposal, thus the following are my suppositions based on the clues which I can see, so, comments are welcome (after all, this blog is just a collection of notes and experiences of a digital signals enthusiast and amateur analyst and does not claim to be a scientific blog).

Multicast Data Link protocol (MDL/MDLN) shares many of the characteristics of the other 3G data link protocols but unlike the 3G ARQ protocols, MDL links employ the one-way link setup: each transmission begins with an TM,  FTM or FLSU PDU that indicates the MDL mode that will be used in the remainder of the transmission.
The MDL_Data PDUs use the BW2 and BW3 burst waveforms used in HDL and LDL: in this case the MDL-288, a stream of 288-byte bursts, is used (as known the BW3 data section can be any multiple of 32 bytes, from 32 up to 512 bytes).
Fig. 2 - BW3 frame
The transfer ends with a BW4 burst, Fig. 3, most likely acting as MDL_EOM PDU (any PDU sent using BW4 in the forward direction is an EOM PDU).

Fig. 3
Sending an FLSU_Terminate would impose a triple demodulation requirement [1] on the receiving stations (they do not expect BW5 bursts) thus, as it happens in LDL transfers, the calling station sends an MDL_EOM PDU (BW4 burst) to signal the receiving stations that the datagram has been transferred, and hence will send no more MDL_Data PDUs for the current datagram.  MDL_EOM PDU would use BW1 burst in case of MDL-5k (HDL BW2 used for MDL_Data)?

Once demodulated, the received datagram transports Harris Citadel off-line encrypted messages (Fig. 4) 

Fig. 4

[1] Dual Demodulation clarifying example:
PU1 issues a FLSU_Request to PU2, requesting LDL ARQ traffic. PU2 issues a FLSU_Confirm that is not received by PU1 due to poor propagation. Since PU2 must only look for at most two waveforms, it looks for the LDL Forward Packet waveform (BW3) and the LDL_EOM PDU (BW4). Thus, in order to terminate the link due to missing the FLSU_Confirm, PU1 must send a LDL_EOM followed by a FLSU_Terminate.

16 February 2017

STANAG-4538 "Circuit Mode" (a 3G-2G switching)

an interesting sample of a 3G-2G switching copied on 7780.0 KHz/USB: the handshake is performed with FLSU bursts (ie 3G-ALE) and user data are sent using MIL 188-110A serial (a 2G HF waveform), last FLSU bursts terminate the link (Fig. 1).

Fig. 1

In this scenario the traffic service is termed “Circuit Mode” in STANAG-4538 and  is used when an HF data continuous waveform (not a burst waveform) will be used to convey traffic after link establishment. The FLSU_Request specifies the traffic waveforms that will be used during circuit mode, for example MIL 188-110A (as in this recording), STANAG 4285, STANAG-4539 or other. Once circuit mode begins, any station can initiate transmissions using the specified traffic waveform. A CSMA/CA process is recommended to avoid collisions (Fig. 2)

Fig. 2

Same operational contest was copied on 11132.0 KHz/USB (Figs. 3a, 3b): these are more likely  test sessions that involves both the packet mode (the used datalink protocols are HDL+ and LDL over BW3-BW4 burst waveforms) and the circuit mode (the HF waveform is MIL 188-110A serial). These (test?) transmissions are probably from Algerian Military.

Fig. 3a
Fig. 3b

A STANAG-4538 circuit mode traffic was also copied by my friend Mike (ak mco) on 9003.0 KHz/USB (Fig. 4) who sent me his recording.  The sample consists of n-transmissions, each composed of a MIL 188-110A transfer running at 300bps, preceeded and terminated by BW5 bursts which control the link. More precisely, 188-110A frames transport Harris proprietary Citadel encrypted data, Fig. 5, so it's difficult to say what sits behind.

Fig. 4
Fig. 5

(9003.0 KHz)

10 February 2017


04618.0: BP25: German Police vessel Bayreuth, D 0622 USB MIL 188-141 2G-ALE handshake BPLEZS followed by R&S GM2100 HF modem transporting X.25 traffic (09Feb17) (AAI)
05420.0: HN02: Algerian Military, ALG USB 0809 MIL 188-141 2G-ALE calling PY01 (09Feb17) (AAI)
05528.0: ---: Unid 0818 USB Thales Systeme-3000, ALE followed by analog voice scrambler (09Feb17) (AAI)
05695.0: ---: Unid 0640 USB 3G-HF HDL traffic (27Jan17) (AAI)
05702.0: ---: Unid (prob. French Ny) 1422 J3E/USB voice comms in French followed by RATT 75Bd/850 (2 KHz offset) witH KG-84C encryption (07Feb17) (AAI)
05708.0: ICZ: USAF Sigonella, I 0705 USB MIL 188-141 2G-ALE handshake PLA Lajes voice/AMD radio check [HOW COPY?// ][L/C, HOW ME OVE] [L,C. ICZ OUT.//] (26Jan17) (AAI)
05859.0: TXFA5: Spanish Police, E 0759 USB MIL 188-141 2G-ALE terminating link with TYMG1 (09Feb17) (AAI)
05893.0: ---: Unid 0815 USB TADIRAN Autocall MFSK-4 (09Feb17) (AAI)
06706.0: SL2: Slovakian Mil, SVK 0759 USB USB MIL 188-141 2G-ALE handshake PO1 followed by voice comms (03Feb17) (AAI)
06792.0: ---: Russian Military, RUS 1828 USB CIS-112 OFDM 112-tone 22.22Bd BPSK modem (26Jan17) (AAI)
06938.0: HBLZDRD1: Roumanian Military, ROU 0803 USB USB MIL 188-141 2G-ALE handshake HFJCDRD1 followed by MIL 188-110A, Harris Citadel off-line encryption (03Feb17) (AAI)
07706.3 ---: Unid 1820 USB Chinese MPSK 4+4 75Bd π/4 DQPSK modem (31Jan17) (AAI)
07771.0 ---: Rusian Military, RUS 1832 USB AT3004-D OFDM 12-tone modem BPSK 120Bd (31Jan17) (AAI)
07780.0: ---: Unid 0820 USB 3G-ALE Linking Protection FLSU handshake followed by MIL 188-110A serial modem (03Feb17) (AAI)
07810.0: GR2: Moroccan Army, MRC 1811 USB MIL 188-141 2G-ALE sounding (31Jan17) (AAI)
07814.3: C3: Moroccan Army, MRC 1811 USB MIL 188-141 2G-ALE calling G24 (31Jan17) (AAI)
08058.6: KWT94: Unid US DoS station 0908 USB MIL 188-141 2G-ALE sounding (04Feb17) (AAI)
08174.0: KF01: Unid (prob. Tunisian Military, TUN) 0923 USB MIL 188-141 2G-ALE handshake ND01 flwd by MIL 188-110 App.B OFDM 39-tone modem (04Feb17) (AAI)
08195.0: ---: Unid 1014 (cf +1500Hz on USB) R&S ALIS 228.65Bd/170 calling address 40 (03Feb17) (AAI)
08207.0: ---: Unid 0943 USB probably CODAN 3212 HF-modem (modified STANAG-4539) (03Feb17) (AAI)
08453.0: FUO: French Navy, F 1443 USB STANAG-4285 600bps/L "FT DE FUO QSL O 291420Z JAN 17 TIME 1443Z BON QUART AUSSI KKKKKK" (29Jan17) (AAI)
08603.0: ZSJ: South African navy, AFS 1810 USB Saab Grintek MHF-50 modem (26Jan17) (AAI)
10900.0: RO3: Polish Military, POL 0847 USB MIL 188-141 2G-ALE handshake BA6 followed by short MIL 188-110A serial modem (08Feb17) (AAI)
11032.0: ---: Unid (Bulgarian Diplo ?) 0930 USB RFSM-8000 modem with data-masking (31Jan17) (AAI)
11106.0: EK9: Greek Military, GRC 1007 USB MIL 188-141 2G-ALE calling GEF (31Jan17) (AAI)
11111.0: STAT22: Tunisian MoI net, TUN 1039 USB MIL 188-141 2G-ALE handshake STAT152 followed by traffic in PacTOR-II 100bd/200 (05Feb17) (AAI)
11130.0: C3: Moroccan Military, MRC 1023 USB MIL 188-141 2G-ALE calling GS51 (05Feb17) (AAI)
11135.0: HQ3: Unid net 1312 USB MIL 188-141 2G-ALE calling GANOB1 (05Feb17) (AAI)
11135.0: HQ4: Unid net 1339 MIL 188-141 2G-ALE calling to GANOB6 [CMD AMD][IFBUIFSHSBIBN] (09Feb17) (AAI)
11424.0: TXFA8: Spanish Police, E 0947 USB MIL 188-141 2G-ALE calling TZCP1 (01Feb17) (AAI)
11430.0: ---: Unid 0903 USB 3G-HF LDL traffic using HARRIS Citadel encryption (08Feb17) (AAI)
11466.0: ---: US Navy (prob. Niscemi, I) 1315 USB (cf) CV-786/TRC-75 FSK 75Bd/850 bursts with KG84-C encryption (05Feb17) (AAI)
11470.0: ---: Unid (prob. Russian source) 1004 (cf) FSK 50Bd/500 modem idling (31Jan17) (AAI)
11500.0: ---: Unid (prob. Russian source) 0940 (cf) FSK 100Bd/500 modem, no apparent ACF (31Jan17) (AAI)
12160.0: CD: Moroccan Army, MRC 0919 USB MIL 188-141 2G-ALE calling ZS1 (31Jan17) (AAI)
12160.0: J63: Moroccan Army, MRC 0920 USB MIL 188-141 2G-ALE sounding (31Jan17) (AAI)
12160.0: P301: Moroccan Army, MRC 0918 USB MIL 188-141 2G-ALE calling C3 (31Jan17) (AAI)
12216.0: FC4FEM1: US-FEMA Region 4 Office Thomasville, GA 0858 USB MIL 188-141 2G-ALE sounding (31Jan17) (AAI)
12228.0: ---: Unid (Bulgarian Diplo ?) 0905 USB RFSM-8000 modem with data-masking (31Jan17) (AAI)
12496.0: ---: Russian Navy, RUS 0902 (cf) CIS Navy "Akula" FSK 500Bd/1000 (31Jan17) (AAI)
12499.8: ---: Unid 0910 (cf) unid BPSK 127.3 Bd modem (31Jan17) (AAI)
14557.0: REA4: Russian Air Force, RUS 1340 (cf) CW-FSK "... 11240 21272 71000 80001 = REA4 K" then into FSK 100Bd/800 reversals (08Feb17) (AAI)
15619.0: ---: South African Navy, AFS 0745 USB Saab Grintek MHF-50 modem (07Feb17) (AAI)
15626.0: ---: Russian Intel, RUS 0740 USB CIS FTM-4, MFSK-4 150Bd (effective 37.5:Bd) 4000Hz modem (tones at: -6, -2, +2, +6 KHz) (07Feb17) (AAI)
16156.0: M42: Russian Diplo, RUS 1230 (cf) FSK 75Bd/500 bursts, 12x10 5F groups (27Jan17) (AAI)
17422.0: ---: Russian Intel/Diplo, RUS 0855 USB MFSK-64 (32+32) 45Bd modem (07Feb17) (AAI)

8 February 2017

STANAG-4538: 3G-ALE FLSU calls with Linking Protection

Chasing 3G-HF transmissions in the 11 MHz band I copied several Fast Link SetUp calls carried by Burst Waveform 5 (BW5) payloads that after decoding appeared at least strange. Other than FLSU protocol, BW5 is also used by its closely associated FTM protocol and their PDUs (ie their Protocol Data Units) are distinguished by the first three bits of the 50-bit paylod: "001" for an FLSU PDU versus "100" for an FTM PDU:

Fig. 1
Well, a large part of the FLSU PDUs did not exhibit a valid protocol identifier but rather the not expected value "000"; other fields have inconsistent values in respect of the context and the destination/source addresses in the responses do not match the ones in the calls (Fig. 2). Decoder errors? yep, it could be... certainly is not a manufacturer implementation.

Fig. 2
Another sample of such weird BW5 PDUs is shown in Figure 3, probably an async FLSU call: decoder errors are still possible but, as you see, repeated errors in the same positions are rather unlikely. Moreover, the first 15 PDUs clearly exhibit alternating patterns that, in my opinion, make sense only in case of Linking Protection mode enabled.

Fig. 3
But how Linking Protection works in 3G-ALE networks?
Linking Protection (LP) encrypts only the PDUs used for link setup, traffic setup, link maintenance, link termination, and data link acknowledgement. LP scrambles PDUs using a scrambling algorithm that depends on a key variable, the time of transmission of the PDU, and the frequency on which it is sent (the latter two dependencies enter via a so-called “seed” that is distinct from the key variable): this achieves the two purposes of authenticating each transmission, and combining the called-PU network number with the other bits in an LSU PDU. Indeed, the network number of the called station is used in the linking protection as shown in Figure 4:  the network number is replicated to match the length of the LP encryption key in use in the network, and then exclusive-ored with that key for use as the key in the LP algorithm. 

Fig. 4
The seed format is shown in Figure 5, one may read the description of the fields in the paragraph "9.2 Seed Format" of STANAG-4538 profile: for the scope of this post I consider only the fields CVI and Word 

Fig. 5
The CVI (Code Validity Interval) field specifies time-units within each day. Normally, this field contains a count of the number of CVIs that have completely elapsed since midnight network time; the Word field is used to count PDUs within a CVI.

For what concerns the formation of the seed and the scrambling procedure, it's important to note that  once a linking process is started using a specific CVI, the calling PU must not change the CVI even if a CVI boundary is crossed during the linking process.
That said, the scanning asynchronous-mode call PDUs are scrambled using alternating Word Numbers 00000000 and 00000001 and the call PDU that concludes an asynchronous-mode call is scrambled using Word Number = 00000010. This means that the same 50-bit PDU is scrambled 15 times (in this sample) using two alternating keys, that's the reason of the alternating patterns seen above (Fig. 6).

Fig. 6
One could say that  the last PDU contains a valid 3-bit identifier in the protocol field  ("001") but I think it's a coincidence. Indeed, the scrambling procedure use the SoDark-6 algorithm (48-bit length) and then only the last rightmost 48 bits of each FLSU PDU are scrambled so the remaining bits, ie the first leftmost two bits, are sent without scrambling.
An example of "unprotected" asynchronous FLSU call can be read here

7 February 2017

a modified/proprietary MIL 188-110B/C Appendix C waveform

It may happen that manufacturers sometimes modify one or more parameters of standard HF waveforms and then obtain proprietary waveforms (and modems) as in the case of these signals, copied today on 8207.0 KHz/USB around 0940 UTC (Fig. 1).

Fig. 1
The different fadings that affect the bursts lead to think to two stations operating in half-duplex mode. Each burst has a ~2520 msec duration and consists of a 1500Hz single tone modulated with PSK-8 modulation at a costant symbol rate of 1800Bd (Fig. 2): that's a bit odd since we are used to observe PSK-8 modulations coupled with 2400Bd speed and 1800Hz sub-carrier.

Fig. 2
Things get more interesting analyzing preamble and data blocks structure. The first part of the preamble consists of seven blocks of 184 PSK-8 symbols and the data blocks are structured in frames consisting of 287 PSK-8 symbols (ie 861-bit period), as shown in Figure 3.

Fig. 3a
Fig. 3b

This is clearly a MIL 188-110B/C Appendix C (or STANAG-4539) modem, but what about the symbol-rate (1800Bd) and the sub-carrier (1500Hz)?
As said above, modem manufacturers may change one or more parameters of the HF waveforms: in this case we face a sort of underclocked STANAG-4539 modem, ie the modulation speed is reduced from 2400 to 1800 Baud as well as the sub-carrier frequency from 1800 to 1500 Hz.
Let's see a trick (thanks to KarapuZ) that prove that it's a S4539 modem: correcting the baud-rate and shifting the signal (Fig. 4) we get the right S4539 3200bps/short interleaving waveform which can be easily processed and demodulated (Fig. 5).

Fig. 4
Fig. 5
By the way, the signals transport STANAG-5066 data.

Another clue to identify the modem/manufacturer is the 1250Hz "roger beep" sometimes heard during voice-comms before the data transmissions. Helps are welcome.

A good "candidate" could be the CODAN 3212 HF-modem, this modem use a modified STANAG-4539 (188-110B App.C) to fit 2400 Hz channels (thanks to Johannes for the hint):

5 February 2017

CV-786 (TRC-75) FSK 75Bd/850Hz bursts

CV-786 is a synchronous wideband FSK mode compliant with STANAG-4481, shore-to-ship RATT FSK 75Bd/850 waveform: in this sample the bursts transport KG-84C on-line encrypted contents. I copied a long-run transmission (...hours) on 11464.0 KHz/USB with 2 KHz offset; given the strong signal, the tx site could be the US military base in Niscemi, Sicily Island Italy.

CV-786 mode is built in Rockwell-Collins MDM-2001 HF Modems and used in TRC-75 transceivers: