28 January 2018

CLOVER-2000 ARQ mode

This is a full transfer session recorded on 11135.0/USB 1414z between stations HQ4 and GANOB3 (supposedly belonging to an Egyptian network). Link is established and terminated using 2G-ALE  188-141A  and data are sent using a CLOVER-2000 HF modem.
Quoting from wikipedia "CLOVER is the name of a series of modem waveforms specifically designed for use over HF radio systems: CLOVER-II was the first CLOVER waveform  developed by Ray Petit, W7GHM, and HAL Communications in 1990-92.  CLOVER-2000 (aka XCLOVER or 8 Tone CLOVER) is a higher-rate and wider bandwidth version of CLOVER developed in 1995. CLOVER-400 is a special 400 Hz wide waveform that was developed for Globe Wireless"
CLOVER-2000 uses eight tone pulses spaced at 250-Hz centers, contained within a 2 kHz bandwidth between 500 and 2,500 Hz (Figure 1)

Fig. 1 - CLOVER-2000 spectrum
The eight tone pulses are sequential, with only one tone being present at any instant and each tone lasting 2 ms. Each frame consists of eight tone pulses lasting a total of 16 ms, so the base modulation rate of a CLOVER-2000 signal is always 62.5 symbols per second regardless of the type of modulation being used (Figure 2).

Fig. 2
In ARQ mode, all CLOVER Control Blocks use BPSK modulation and data (structured in 255-byte blocks) may be sent using five different types of modulation: BPSK, QPSK, PSK-8, 2APSK-8 (PSK-8 + 2-level Amplitude Shift Modulation), and 4APSK-16 (PSK-16 plus 4 ASM). The FEC broadcast mode of CLOVER-2000 is usually disabled although special formats are available for specific applications.
Since CLOVER-2000 is an adaptive system, you may find different modulations in the same transfer, as confirmed by the analysis of the heard trasnmission: in the following Figures I analyzed the tone #4 in different data blocks:

Fig. 3 - PSK-2
Fig. 4 - PSK-4
Fig. 5 - PSK-8
Fig. 6 -2APSK-8
An example of 4APSK-16 modulation, from a different recording, is shown in Figure 7: you may note the 4  levels of amplitude modulation. The recording is from radioscanner.ru

Fig. 7
➤ update
The sent message is encrypted BZIP2 compressed since the presence of the BZh11 sequence which marks the start of the compressed file (thanks to J.S4538). The name of the transferred file is in clear text "E_UNKNOWN_807_2701201.txt" in the header of the demodulated stream (thanks to KarapuZ for demodulation).

Fig. 8 - BZIP2 "BZh11" sequence
Fig.9 - file name

My friend J.S4538 also commented that the message is sent using the "2020 Binary Transfer Protocol" developed by HAL COMMUNICATIONS, the stations IDs in the play are ABORAMA1 (GANOB3 in ALE) and BASE41 (HQ4 in ALE).

25 January 2018

STANAG-4538, HDL+ BW7 frame structure

"The HDL+ protocol is used to provide acknowledged point-to-point delivery of datagrams from a transmitting PU to a receiving PU across an already-established HF link, with selective retransmission (ARQ) of data received in error. The datagram passed to the HDL+ entity for delivery is a finite-length ordered sequence of 8-bit data bytes (octets). Because it can adaptively employ a variety of signal constellations and degrees of coding, the HDL+ protocol can deliver datagrams of all sizes with high efficiency, under fair to very good channel conditions [...]"
"In an HDL+ data transfer, the sending PU and the receiving PU alternate transmissions in the manner depicted in Figure 1. Each transmission by the sending PU contains an HDL+ data header PDU (using BW6 waveform), followed immediately by an HDL+ data PDU (using BW7 waveform) containing payload data packets. After receiving each HDL+ header+data combination, the receiving PU transmits an HDL+ ack PDU (using BW6 waveform) containing acknowledgements of the data packets received without errors in the preceding HDL+ data PDU [...]"
Fig. 1

The end of a data transfer is reached when the sending PU has transmitted HDL+ data PDUs containing all of the payload data in the delivered datagram, and the receiving PU has received these data without errors and has acknowledged their successful delivery. When the sending PU receives an HDL+ ack PDU indicating that the entire contents of the datagram have been delivered successfully, it sends one or more (up to four) HDL+ EOT PDUs (using BW6 waveform), starting at the time at which it would have otherwise transmitted the next HDL+ data header PDU, to indicate to the receiving PU that the data transfer will be terminated. This scenario is depicted in Figure 2." (quoted from NATO STANAG-4538)

Fig. 2
Continuing to read S-4538 "Because it can use the high-order signal constellations (up to 64-QAM) of the STANAG 4539 High Data Rate waveforms, the HDL+ protocol can achieve very high data throughputs [...]" it may seem that HDL+ uses the waveforms described in S-4539/188-110B (MIL 188-110B Appemdix C) but actually uses a waveform with a frame structure of 288 symbols, as can be seen in Figures 3a and 3b (in this sample a PSK-8 2400 Bd modulation).
Fig. 3a - HDL+ frame structure (view)
Fig. 3b
Fig. 3b - HDL+ frame structure (analysis)
The structure of the frame is confirmed by the analysis of the demodulated bitstream in Figure 4: indeed the period consists of 864 bits that just make 288 tribit (PSK-8) symbols.

Fig. 4 - HDL+ demodulated bitstream (864-bit frame)
A frame structure of 288 symbols does not belong to NATO STANAG-4539, or the equivalent MIL 188-110C Appendix C, since all the S-4539 waveforms  - unless the preamble (obsoleted) - have a frame structure of 287 symbols! (Figure 5)

Fig. 5 - STANAG-4539 frame structure (287 symbols)
In terms of frame structure it is more correct to say that HDL+ BW7 PDUs, unless the sync preamble which is formed using BW6,  use the same structure of MIL 188-110C App.D 3 KHz waveforms, ie 288 symbols (Figure 6).

Fig. 6 - MIL 188-110C App.D frame structure
By the way, the analyzed transmission was recorded on 11430.0 KHz/USB at 1045z (Jan, 10).


13 January 2018

(differential) FSK 75Bd/200Hz

Unid and quite rare FSK system running at 75Bd and using a 200Hz shift, heard on 4540.0 Khz (central frequency) around 1755z. The measured ACF is = 0 but I went on this transmission after its start, ie when in traffic mode, so I do not know if the initial header part has any pattern that could help in signal identification.

Fig. 1
As said, the ACF is =0 but using the differential decoding you may get a strong 385-bit period (Fig. 2).

Fig. 2
I posted my analysis in radioscanner (my nickname there is "ansanto") asking for comments:
and my friend cryptomaster in his reply suggested a "relative" FSK (DFSK2) modulation and pointed that the 385-bit period is due to the length of the scrambler generated by the polynomial x^7 + x^6 + 1. After descrambled the bistream exhibits a 398-bit period (Fig. 3), thanks to cryptomaster.

Fig. 3

11 January 2018

MFSK-11 125Bd/250Hz waveform

Unid MFSK-11 waveform spotted this morning on 7973.0 KHz on USB,  already heard on March 13, 2017 (same frequency) and March 23, 2016 (9300.0 KHz). The waveform is an 11-ary frequency shift keying (FSK) modulation with eleven orthogonal tones spaced by 250 Hz (first tone at 650 Hz), one tone (or symbol) at a time; the tones are transmitted at a rate of 125 tones (symbols) per second (Fig. 1).

Fig. 1
The 792 msec ACF value means a frame length of 99 symbols/sec, given the speed of 125 Baud. Once demodulated (Fig. 2) I converted the 0-A symbols into their quadribit rapresentation using the Hex table 0=0000, ..., A=1010 supposing that each tone represents 4 bits of data.

Fig. 2
The resulting bitstream confirms the framing of 99 quadribit symbols, ie a 396-bit length period as shown in Figure 3.

Fig. 3
It's worth noting that each 99-symbols frame consists of nine blocks, each consisting of just 11 symbols: this is an interesting relation between the number of symbols-per-block and the number of the levels (both 11)!
Presumably it's a CIS waveform, although I did not find any confirmation in other logs. Comments are welcome.

➤ 𝒖𝒑𝒅𝒂𝒕𝒆
I want to thanks my friends KarapuZ and cryptomaster who sent me some other useful informations and samples about this waveform. Particularly, a record from KarapuZ must be mentioned: in that case it's possible to observe a 6864-bit (1716 symbols) period 

Fig. 4

5 January 2018

Swedish Army 8-bit text ACP-127

Thanks to the help of some friends of mine - Guido, J.S4538 and Karapuz -  I've been studying these transmissions for several months and some of their characteristics (mainly their occurences and format) lead to think that this traffic is most likely the encrypted "8-bit text ACP-127 (SV-7)" from the Swedish Armed Forces, as indicated in one slide of their presentation of the HF2000 system at HFIA Metting 2010 [1] and reported below in Fig. 1 (at present I don't know what the term "SV-7" stands for).

Fig. 1
All the transmissions use the MIL 188-110A Serial waveform with a data-rate of 1200bps and modem running in ASYNC 8N1 mode, they are not preceded by 2G/3G ALE neither by voice calls and happen many times per day w/out an apparent sked.  The transmitted 8-bit (encrypted) text can be obtained using a 188-110A decoder that shall be configured to work in ASYNC mode and  8N1 framing, or you may get the source bitstream by configuring the output of the decoder as ASCII Bits: in the latter way you have to manually remove the start/stop bits in order to obtain the 8-bit text (I mostly used this method to study the "format" of the bitstreams).

As well as with our receivers, monitoring is performed thaks to the use of four remote KiwiSDRs located in Sweden and Finland (Fig. 2)

Fig. 2 - the used KiwiSDRs and map of main RT/x stations
So far these are the spotted frequencies thanks to Guido, J-4538 and Karapuz (all freq. are USB): 

3034, 4228, 4321, 4373, 4396, 4408, 4513, 4522, 5242 

Although in a small percentage, synchronous 188-110A transmissions (still 1200bps/Long) can be received in these channels.
A parallel monitoring of 4396 KHz (using KP20 in Finland) and 4513 KHz (using SM0KOT in the northern part of Sweden) was performed during the morning-time on 20 December 2017 and got some interesting points about these two channels. Looking at the waterfall in Fig. 3, the strengths of the received signals point out different transmitters sites; since the waterfall is related to KP20 SDR, frequency 4396 KHz - on the left in the waterfall - perhaps could be operated by the close Karlskrona Naval Base. Moreover, transmissions on 4396 and 4513 KHz occurred almost simultaneously during all the monitored time (Dec 20th, 2017) but actually it's impossible to say if they carried the same messages.
Fig. 3- KiwiSDR KP20 in Finland

However, such behavior was not observed during the first seven days of January 2017: indeed, those two frequencies seem not to be used, as well as 4321, and the trasmissions happen on 4373 KHz (Fig. 4) which was spotted by Karapuz on 2 January.

Fig. 4 -
KiwiSDR KP20 in Finland
π‘’π‘π‘‘π‘Žπ‘‘π‘’ On Jan 8th, 4.3 MHz transmissions take place only on the new 4372 KHz. I do not know the reasons for these changes.

𝟴𝐍𝟏 𝐟𝐨𝐫𝐦𝐚𝐭𝐬 
Looking at the bitstreams, it's esay to see that headers and data are arranged in different formats, although the same "8N1" framing is used (Fig. 5).

Fig. 5

"A" format (headers and data are shifted and separated) is used in 4373, 4396, 4408, and 4522;
"B" format (headers and data are contiguous) is used in 4228, 4321, 4513, and 5242;
"C" format (as in "A" but data appears as "fragmented" in separated blocks) is used in 3034.

(for what concerns the 3034 KHz I could record only very few 8N1 transmissions during long-time periods, perhaps it is related to a less used service)

Probably the different formats (and the one used in STANAG-5066 [2]) and the different Tx sites are due to the different recipients, ie: Army, Navy, Air Force and Civil Defence ...but it's only my guess.

𝐭𝐑𝐞 𝐙-𝐬𝐭𝐫𝐒𝐧𝐠𝐬 𝐒𝐧 𝟴𝐍𝟏 𝐚𝐧𝐝 𝐒-πŸ“πŸŽπŸ”πŸ” 𝐭𝐫𝐚𝐧𝐬𝐦𝐒𝐬𝐬𝐒𝐨𝐧𝐬
The most important aspect is the presence of the Z-strings in the messages' headers: these are the same as the strings already seen in the data-blocks of the  S-5066 transmissions from the Swedish Armed Forces [2]. Note also that in both the transmissions the Z-strings are contained within the same sequences  (I catched tens of transmissions, for simplicity I show in Fig. 7 only two of these but the matches are in all the recordings).

Fig. 6 (HEX view)
The 8-bit transmissions use only the Z-strings ZAPD<L> and ZXPD<L> and both are used every day with a prominence of the latter. So far, these are the heard strings:

ZAPD flwd by B,C,D,E,F (ie: ZAPDB, ZAPDC,...)
ZXPD flwd by B,C,D,E,F (ie: ZXPDB, ZXPDC,...)

I saw that the fifth letter of the Z-string does not change during the week, then in the following week it takes the next value in the alphabetical order: for example ZAPDD is used from Mon to Sun then in the following monday it changes into ZAPDE; the same happens for ZXPDD which changes into ZXPDE.
This alphabetical progression  is verified by a long-time monitoring and it's not a simple  "rotation" but rather a way to indicate the week of the year using the last two letters and the convention A=1, B=2, C=3,... so that for example DC = 43, DD = 44 and so on (Fig. 7).

Fig. 7

It is very important to note that the same mechanism has been observed in the variations of the Z-strings in S-5066 transmissions (sporadic catches, not from a monitoring):

ZRTBC and ZXPBC on 6,7 June (BC = 23th week)
ZRTBD and ZXPBD on 15,16,17 June (BD = 24th week)
ZXPBE on 23 June (BE = 25th week)
ZAPCA on 1,2 August (CA = 31th week)

as you see, the dates belong to the number of the week indicated by the last two letters of the Z-strings. Nothing (unless the timestamp header in S-5066 transmissions) seems indicate the time & date of the message, maybe it is contained within the encrypted text.

The Z-strings suffix "DI" was expected during the week 4-10 December to indicate the week #49 but curiously they skipped the letter "I" and adopted "J" to code the number 9 (Fig. 8), maybe to avoid confusion between "I" and "1" ?

Fig. 8 - "DJ" suffix to code week #49 (8x19 view)
It's interesting to note the choice of the letter "K" to code the "0" during the fiftieth week (11-17 December): indeed the suffix "EK" (more precisely the string "ZXPEK") has been found in all the messages of the monitored frequencies (3034, 4396 and 4513) during the week #50. 

As expected, the suffix "KA" (= 01) is used to code the first week of the year: the presence of the ZXPKA string has been confirmed also by the catches of my friends Guido and Karapuz (see the comments to this post). Figure 9 below shows the string ZXPKA in a message received in the firts week of 2018 (Jan 4th): note the use of MS-DMT software configured in Async 8N1 mode. 

Fig. 9 - "ZXPKA" string during the week #01(transmission decoded using MS-DMT)

That said, the Z-strings shall be considered as 3-letters:
ZNT (so fare seen only in S-5066 transmissions)
ZRT (so far seen only in S-5066 transmissions)

followed by 2-letters (encoded) week of the year, according to:
A = 1, B = 2, C = 3, ..., H = 8, J = 9, K = 0 

It's difficult to say what the initial 3-letters  stand for, maybe they could indicate the precedence of the messages: ie, ZAP for higher priority (flash) and ZXP for routine, or maybe a kind of classification. 
I tried the NATO military Z-signals defined in ACP 131 [3] but their meanings make poor sense in our context.

[1] http://www.hfindustry.com/meetings_presentations/...HF2000_HFIA_2010.pdf 
[2] https://i56578-swl.blogspot.it/2017/06/unid-stanag-5066...client.html
[3] http://www.angelfire.com/va3/navy_mars/ACP131.pdf



4 January 2018

MFSK-4 session using 250Bd/500Hz & 160Bd/320Hz

Interesting MFSK-4 transmission recorded by my friend Mike (Mike Cache-Ortiz, mco) on 17423.0 KHz/USB: during the session  the mode (speed and separation) changes from 250Bd/500Hz to 160Bd/320Hz (Figs. 1,2).

Fig. 1
Fig. 2
I asked my friend Karapuz if he knew this transmission and he directed me to a radioscanner post where he describes a similar signal: in that case the variations were (Bd/Hz) 500/1000, 400/800, 250/500 and 125/250:
It's worth nothing that Karapuz measured a 336-bit period in all those modes, as reported in the mentioned link, and I found just the same value in both the 250/500 and 160/320 modes (Figs 3,4). Probably it's the same (Russian?) system.

Fig. 3
Fig. 4

1 January 2018

2017 last logs

04158.0: ---: Unid 1035 USB Skysweep Technologies proprietary waveform, OFDM 28-tones BPSK 65.6Bd  (22Dec17) (AAI)
05215.6: FUO: French Navy Toulon, F 0810 STANAG-4285 1200bps/L encrypted pseudo-random bcast (29Nov17) (AAI)
05748.0: RD25: Algerian Military, ALG 1438 USB 188-141A call NX20 (12Dec17) (AAI)
05854.0: R26577: US Army Helo 94-26577 1426 USB 188-141A calling GRIFFIN MNBG Camp Bondsteel Kosovo (14Dec17) (AAI)
06330.8: ZHGD: Unid 1128 (cf) Baudot FSK 50Bd/100 RY + "ZHGD DE N4O4 QRK ?" (01Dec17) (AAI)
06450.0: VACCARO: Guardia di Finanza Patrol Boat Vaccaro, I 0923 USB 188-141A call AVALLONE (28Nov17) (AAI)
06690.0: 2MG: prob. Moroccan Gendarmerie, MRC 1740 USB 188-141A handshake 3VO / FED-1052 App.B (01Dec17) (AAI)
06690.0: LA3: prob. Moroccan Gendarmerie, MRC 1741 USB 188-141A call H2T (01Dec17) (AAI)
06753.0: SK01: Algerian Military, ALG 1034 USB 188-141A call XV01 (05Dec17) (AAI)
06765.0: HSW: Bangkok Radio, THA 1835 J3E/USB Musical chime / weather report, male English (13Dec17) (AAI)
06820.0: DQ01: Algerian Military, ALG 1030 USB 188-141A call BZ01 (05Dec17) (AAI)
06840.0: R26308: 90-26308 Sikorsky UH-60L Black Hawk 0923 USB 188-141A calling GRIFFIN MNBG Camp Bondsteel Kosovo / MIL 188-110A serial encrypted msgs (23Dec17) (AAI)
06873.5: XAE: Unid DHFCS node, UK 1050 USB 188-141A 2-way handshake XSS, no data following (22Dec17) (AAI)
07500.0: BW01: Algerian Military, ALG 1006 USB 188-141A calling XV01 (18Dec17) (AAI)
07512.0: 810002: Unid 0952 USB 188-141A sounding (05Dec17) (AAI)
07625.0: ---: Unid prob. Russian Gov 0956 (cf) revs + FSK 100Bd/500 data bursts, 7-bit ACF, s/off at 1000 (05Dec17) (AAI)
07645.0: Unid 1120 (cf) FSK 40.5Bd/500, revs (05Dec17) (AAI)
07651.0: A12: Israeli Air Force, ISR 1407 USB 188-141A sounding (10Dec17) (AAI)
07685.0: ZM6: Unid 1415 USB 188-141A sounding (10Dec17) (AAI)
07830.0: PG01: Algerian Military, ALG 0913 USB 188-141A call BZ01 (28Nov17) (AAI)
08022.0: TWBH6: Guardia Civil Huesca, E 0900 USB 188-141A sounding (13Dec17) (AAI)
08060.0: ---: Unid 1140 USB 3G-HF FLSU handshake / HDL+ transfer (05Dec17) (AAI)
08083.5: ---: Unid 0838 USB USB 3G-HF 2-way FLSU handshake / LDL448 transfer, sending 867-byte Citaded encrypted file (28Nov17) (AAI)
08174.0: 2163: Unid 1000 USB 188-141A handshake 2159 / voice comms in Arabic language (29Dec17) (AAI)
08247.8: HWK01: Swedish Armed Forces, S 1006 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, Circuit Mode tfc to HXK01, S5066 unid UDOP client (29Dec17) (AAI)
08306.0: ---: Unid 0807 USB STANAG-4197 ANDVT modem (28Nov17) (AAI)
08847.0: A12: Israeli Air Force, ISR 1516 USB 188-141A call CJY (12Dec17) (AAI)
09940.0: 120715: Unid 1502 USB 188-141A sounding (15Dec17) (AAI)
09974.0: VQ4: Polish Military, POL 0951 USB 188-141A call VQ3 (13Dec17) (AAI)
10115.0: 120715: Unid 1510 USB 188-141A sounding (15Dec17) (AAI)
10200.0: PAR: Unid 1312 USB 188-141A sounding, rptd after 1 hour (15Dec17) (AAI)
10386.0: 2307: Unid 1511 USB 188-141A sounding (15Dec17) (AAI)
10425.0: SDR: Unid 0933 USB 188-141A calling 18C (29Dec17) (AAI)
10425.0: SDR: Unid 0944 USB 188-141A call SWD (13Dec17) (AAI)
10500.0: 0001: Unid 1456 USB 188-141A sounding (15Dec17) (AAI)
10648.0: 165001: Turkish Emergency Net, TUR 1306 USB 188-141A calling 162001 (15Dec17) (AAI)
11059.5: C10: Ukraininan x10 Net, UKR 1417 USB 188-141A sounding (13Dec17) (AAI)

11135.0: HQ4: Unid (presumed Egyptian net) 1006 USB 188-141A handshake GANOB6 / CLOVER-2000 modem (06Dec17) (AAI)
11151.0: ---: Russian Mil/Gov, RUS 1040 USB CIS-45 HDR modem v2, OFDM 45-tone 40Bd DQPSK (06Dec17) (AAI)
11165.0: CHL: Algerian Air Force Ech Chelif, ALG 0931 USB 188-141A call CM1 Blida (29Nov17) (AAI)
11166.0: ---: Russian Mil/Intel, RUS 0906 USB CIS-3000 PSK-8 3000Bd burst modem / MFSK 32+32, 2 mins duration (13Dec17) (AAI)
11168.6: WNG767: US DoS Pristina/Kosovo 1039 USB 188-141A call KWX57 (06Dec17) (AAI)
11180.0: LBJ: Norwegian Navy HQ, NOR Unid 1305 J3E/USB working REACH-335A, METARs for ESGG Goteborg, ESDF Ronneby, ENGM Oslo (13Dec17) (AAI)
11186.0: ---: Unid 1129 USB 3G-HF FLSU Async call (09Dec17) (AAI)
11226.0: KWX57: US DoS Ankara USB 188-141A call KWR86 (note the HF-GCS frequency) (06Dec17) (AAI)
11235.0: 4665: Italian Air Force, I 1045 USB MIL 188-141A handshake CHARLY46 Italian AF 46th Air Brigade / voice comms, asking if Beirut is informed about the early arrival (15Dec17) (AAI)
11297.0: RLAP: Rostov Meteo, RUS 1455 J3E/USB volmet station, female (13Dec17) (AAI)
11345.0: BV1618: flight "Blue Panorama 1618" Milan-Havana 0920 J3E/USB utility bus-8 does not work, phone patch with tech-support in Italy via Stockholm Radio (09Dec17) (AAI)
11439.0: ---: Russian Mil/Gov, RUS 1055 USB CIS-60 HDR modem, OFDM 60-tone 35.5Bd, idling (06Dec17) (AAI)
11448.0: 1GYM8: Unid (prob. FEMA/US Govt) 1423 USB 188-141A call Y5MG8 / short STANAG-4197 ANDVT (13Dec17) (AAI)
11500.0: 2016: Turkish Red Crescent, TUR 1014 USB 188-141A sounding (12Dec17) (AAI)
13503.6: KWP95: Unid US DoS stn 1104 USB 188-141A call KWP96 (29Nov17) (AAI)
17398.3: ---: Unid 1405 USB STANAG-4285 modem, pseudo-random broadcast (14Dec17) (AAI)