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). My friend KarapuZ spotted other clusters on 3.3, 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 3x5 = 15 "burst channels".
Fig. 1 - 5.7 and 7.8 MHz clusters |
Probably they
use staring SDRs, and in my opinion it could be an implementation of STANAG-4539 Annex H "Technical specifications to ensure interoperability of application communication systems using multiple discrete HF channels serial waveform", also provided in 110C Appendix F.
The bursts use the STANAG-4539 2400Bd and a 8-ary like constellation 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!
The bursts use the STANAG-4539 2400Bd and a 8-ary like constellation 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!
12800bps, also detected by my Harris
RF-5710A, is clearly unlikely since 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 or PSK-8 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.
Now
look at the phase diagram of the received preamble (Fig. 3): 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. 3 - 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", therefore the 12800bps setting seems to be coded into the received preambles. I edit his script to improve the display of the 39 symbols related to the setting and replicated the tests: results are shown in Figure 4.
Fig. 4 - a) 287 symbols preamble and its sync (red); b) the actual "6,6,2" setting read from the preamble; c) the theoretic "6,6,2" setting |
Since the 12800bps settings is correct, the used 8-ary constellation can't be a PSK-8 modulation!
But oddities do not end there.
Assuming that - in some ways - the decoding 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 5).
Notice that each burst carries different contents: maybe the source contents are spread on the five clusters (ie on the 15 burst channels)?
I just add that all TDoA runs point to Cornwall, maybe St.Eval? if so, I wonder if Babcock/DHFCS are testing/using a S4539 burst system in addition to the S4285 based system.
(to be continued here)
[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 decoding 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 5).
Fig. 5 - demodulated streams of the 7.8 MHz cluster |
I just add that all TDoA runs point to Cornwall, maybe St.Eval? if so, I wonder if Babcock/DHFCS are testing/using a S4539 burst system in addition to the S4285 based system.
Fig. 9 - result of TDoA |
(to be continued here)
[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
Greetings from Malaga Spain. This is the sequence of this system:
ReplyDeleteTime sequence Freq. Schedule
1 2082,2 night
2 2088,2 night
3 2097,2 night
4 3312,2 night
5 3318,2 night
6 3327,2 night
7 4022,2 night
8 4028,2 night
9 4037,2 night
10 4782,2 night
11 4788,2 night
12 4797,2 night
1 5742,2 day
2 5748,2 day
3 5757,2 day
4 7807,2 day
5 7813,2 day
6 7822,2 day
thanks for the comment! I'm just working on a updated post about this topic.
Delete73's
Antonio