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).

https://yadi.sk/d/Kwcn2xvC3RqPLm

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)

It's worth noting that 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).

https://yadi.sk/d/A_kkMKYl3RnEZP 

(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:
http://www.radioscanner.ru/forum/topic39959-120.html#msg1354462 
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

 https://yadi.sk/d/jn4U05aC3RNssi

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

 
 

https://yadi.sk/d/Tzs7f3uv3RMpsb 

Swedish Defence 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:
ZAP
ZNT (so fare seen only in S-5066 transmissions)
ZRT (so far seen only in S-5066 transmissions)
ZXP

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

 

https://youtu.be/lWNljuCQw_0