These transmissions consist of spread band "cluster bursts" which are sent in sequential order on several frequencies, ie the clusters are not sent simultaneously (Figure 1). Each cluster lasts about 5200ms and is composed of three 1600ms bursts separated by 200ms and spaced by 6000Hz (b1-b2) and 9000Hz (b2-b3), eg:
5.7 MHz cluster: 5742.2 (b1), 5748.2 (b2), 5757.2 (b3)
7.8 MHz cluster: 7807.2 (b1), 7813.2 (b2), 7822.2 (b3)
7.8 MHz cluster: 7807.2 (b1), 7813.2 (b2), 7822.2 (b3)
My friend KarapuZ spotted other clusters on 3.3 (only two bursts here), 4.0, and 4.7 MHz and published a youtube clip that shows a complete cycle [1], therefore it seems that "five" is the number of the used clusters, for a total of 2+(3x4) = 14 "burst channels". Probably they use staring SDRs.
 |
| Fig. 1 - 5.7 and 7.8 MHz clusters |
The bursts use the STANAG-4539 2400Bd PSK-8 waveform with a data-rate of 12800bps uncoded (!?!), a similar waveform (S-4539 12800bps/U bursts) was heard on 14 June on 7807.2 KHz/usb [2]: just the same frequency of burst b1 of the 7.8 MHz cluster!
Now look at figure 2: the data rate of 12800bps detected by my Harris RF-5710A (as well as other software decoders) is clearly unlikely. PSK-8 modulation at a symbol rate of 2400Bd makes a gross bit transfer of 2400x3 = 7200 bit/sec, which in turn allows max data rates of 3200bps and 4800bps (if uncoded). So, 12800bps seems an inconsistent data rate.
 |
| Fig. 2 - incosistent data rates |
The frame structure of the bursts matches the one specified in S4539 #4.3. An initial
preamble is followed by data frames of alternating data and known symbols. Each data frame consists of a data block (256 data symbols), followed by a mini-probe (31 symbols of known data). It's worth noting that each burst (consisting of 12 data blocks) curiously ends up with a half (½) data block.
preamble is followed by data frames of alternating data and known symbols. Each data frame consists of a data block (256 data symbols), followed by a mini-probe (31 symbols of known data). It's worth noting that each burst (consisting of 12 data blocks) curiously ends up with a half (½) data block.
Since the waveforms match, I wonder if they use an alternative/reserved coding that somehow deceives the RF-5710A modem. The only way to shed light on the wrong data rate is look at the received preamble.
Data rate and interleaver settings are explicitly transmitted as a part of the waveform in the second 103 symbols of the initial preamble and are coded as described in S4539 #4.3.1.1 "Synchronisation preamble" page B-11
The tribit symbols D0, D1, and D2 take one of 30 possible sets of values to indicate the data rate and interleaver settings:
The Modulo operations are meant to signify that the data rate and interleaver coded values (D0,D1,D2) are used to shift the phase of the Barker code 0,4,0,4,0,0,4,4,0,0,0,0,0. The symbols for 12800bps setting appears as in Figure 3: two same 13-symbol sequences plus a third one
 |
| Fig. 3 - coding of 12800bps setting |
Now look at Figure 4, the phase diagram related to the received preamble: the sequences related to the data rate setting are clearly visible (by the way, Figure 4 clarifies the presences of PSK-2 nuances in the received constellation). As you may see, the data rate setting consists of two equal sequences plus a third one: such a symbols pattern can be originated only by the values "0,0,4", "6,6,2", and "2,2,6" of the Table 4.3.1.1-1 above reported.
 |
| Fig. 4 - phase variations of the received preamble |
I'm less than a novice GNU-Octave coder so I asked my friend Christoph to write a little script to extract the symbols from the received preambles, results are surprising: quoting his email "the first few symbols of the preamble are not transmitted but the rest fits perfectly D0,D1,D2 = 6,6,2" (Figs 5,6) ie the 12800bps speed is correctly coded into the received preambles! I replicated his test on other received S4539 bursts samples of mine and the results match.
 |
| Fig. 5 - preamble of a received burst |
 |
| Fig. 6 - zoom of the data rate setting part of a received burst |
The shortened preamble and the ending ½ data block make me think of a slightly modified version of the S4539 waveform. But why the 12800bps coded into the waveform?
Try to find an explanation. Let's look at the setting symbols pattern shown as red-circled in the lower side of Figure 4: ie, two equal sequences plus a third one. Well, as said above, a such pattern can be obtained by using the "0,0,4", "6,6,2", and "2,2,6" settings (Table 4.3.1.1-1): my guess is that it can happen that:
- a constant phase shift causes a rotated constellation at the receive modem (phase recovery is carried out for each burst independently of the others)
or
- the modulating phasor rotates in clockwise direction.
In both cases, the "2,2,6" setting (the expected 3200bps) becomes "6,6,2" (the inconsistent 12800bps)! if my guess is right the receive modem shall be aware of this fact.
Try to find an explanation. Let's look at the setting symbols pattern shown as red-circled in the lower side of Figure 4: ie, two equal sequences plus a third one. Well, as said above, a such pattern can be obtained by using the "0,0,4", "6,6,2", and "2,2,6" settings (Table 4.3.1.1-1): my guess is that it can happen that:
- a constant phase shift causes a rotated constellation at the receive modem (phase recovery is carried out for each burst independently of the others)
or
- the modulating phasor rotates in clockwise direction.
In both cases, the "2,2,6" setting (the expected 3200bps) becomes "6,6,2" (the inconsistent 12800bps)! if my guess is right the receive modem shall be aware of this fact.
 |
| Fig. 7 |
But oddities do not end there.
Assuming that - in some ways - the demodulation is correct, what you get is that each single burst carries 1536 bits of data and by aggregating the bursts of a single channel you will end up to see a 1536-bit protocol which looks like the DHFCS multiplexed stream (Figure 8).
Notice that each burst carries different contents: my guess is that at Tx side the source contents are spread on the five clusters (ie on the 14 burst channels).
My resources end up here, comments and ideas are welcome. I could add that since the TDoA runs point to St.Eval area in UK - as shown in Figure 9 - I wonder if Babcock/DHFCS are testing/using a (proprietary?) burst based system that will replace the S4285 based system.
[1] https://youtu.be/iZCq4DnlNxo
[2] http://i56578-swl.blogspot.com/2018/06/stanag-4539-unexpected-data-rate-of.html
https://yadi.sk/d/EhPc_M8G7jC-mg
Assuming that - in some ways - the demodulation is correct, what you get is that each single burst carries 1536 bits of data and by aggregating the bursts of a single channel you will end up to see a 1536-bit protocol which looks like the DHFCS multiplexed stream (Figure 8).
 |
| Fig. 8 - demodulated streams of the 7.8 MHz cluster |
My resources end up here, comments and ideas are welcome. I could add that since the TDoA runs point to St.Eval area in UK - as shown in Figure 9 - I wonder if Babcock/DHFCS are testing/using a (proprietary?) burst based system that will replace the S4285 based system.
 |
| Fig. 9 - result of TDoA |
[2] http://i56578-swl.blogspot.com/2018/06/stanag-4539-unexpected-data-rate-of.html
https://yadi.sk/d/EhPc_M8G7jC-mg