25 November 2018

8-ary constellation bursts at 12800bps data rate (2)

Some other observations and updates about the S4539 12800bps 8-ary constellation already discussed here: this post was possible thanks to the collaboration of my friends AngazU, Christoph, Martin G8JNJ, and Sergio.

As shown in Figure 1, the polarity of mini-probes matches the 12800Ubps (6,6,2) setting so no doubt about the proper operation of the used decoders, primarily the Harris RF-5710A model.

Fig. 1a) 287 symbols preamble and sync sequence (red);
Fig. 1b) the actual "6,6,2" setting read from the preamble;
Fig. 1c) the theoretic "6,6,2" setting

Now look at the on-air symbols shown in Fig. 2: S4285 symbols (Fig. 2a) are exactly mapped to a PSK-8 constellation but the S4539 symbols being analyzed occupy different points (Figs. 2b,2c). It looks like a subset of the QAM-64 symbols is used for data  while the 4 "circled" points are the QPSK symbols of the mini-probes. Thus, since no interleaving and no coding are used in 6,6,2 mode (12800bps), the source data must be prepared such that after the scrambling the resulting 6-bit numbers will be mapped only to a 8-point subset of the QAM-64 outer ring. This makes sense and clarify the 12800bps speed, though we do not figure out why this is done.
Fig. 2
Figure 3 shows the plots of one frame obtained by Christoph: 256 data symbols + 31 mini-probe symbols: the 31 mini-probe symbols were descrambled and are at I=1,Q=0. As you can see the other points fit perfectly the 8 out-of-20 points of the QAM-64 outer ring [7 3 24 56 35 39 60 28].

Fig. 3 - 256 data symbols + 31 mini-probe symbols
These eight symbols have interesting structure: the 3,7,24,28 symbols are the same of  35,39,56,60 unless the left-most bit and they are at the same distance (32)

 3 000011
 7 000111
24 011000
28 011100

35 100011
39 100111
56 111000
60 111100

According to Christoph, the 6 bits are ABBCDD where ABC identify the point and D+B=1 mod 2. The ABC bits stream exhibit a 480-bit leghth period (Fig. 4).

Fig. 4
Back to the transmissions, our monitoring revealed that the entire sequence lasts about 36 seconds and consists of 6 "clusters", or "sets", each consisting of three channels with same spacing and arrangement:

Lately, our friend Martin G8JNJ noticed in the lower cluster A1 A2 A3 one weaker set (TDoA 100% St Eval) every 30 seconds (approx) and one set of stronger ones every three to five  minutes (approx) which he wasn't able to TDoA. "So that I think I'm hearing more than one transmitter site. It's proving to be very difficult to TDoA the second one, as they transmit much less frequently, but there is a big difference in RX signal strength between the transmissions", Martin says.
A friend of AngazU suggested that they could be developing some kind of turbo equalizer or similar. These emissions would be tests of a  training sequence and they would be measuring errors, convergence time and other parameters under different conditions. Just a guess, if they  succeed, we will see the  full constellation.

By the way, subjecting for example the F1 channel to the k500 decoder it prints out only 1536 decoded bits although it correctly recognizes the 12800U setting. As shown in Figure 5, each burst is made up of 13 frames for a total of 256x13=3328 QAM-64 data symbols that make 3328x6=19968 bits of data! (no interleaving neither coding is used in 12800U mode). Thus it seems that only one data frame (256 x 6) is processed by k500 (possibly the first one?): maybe it's a decoder limitation due the short burst duration? Note that it does not happen when I use the RF-5710A modem.

Fig. 5
(to be continued)

23 November 2018

WINB Red Lion to test DRM Single Channel Simulcast (SCS)

Shortwave station WINB has recently started conducting test in DRM directed to Europe on 15670 kHz Monday - Friday from 11:00 -17:00 UTC using a new DRM 18 Kw transmitter, an ASI CE-50000WS, and Rhombic antenna at 062 degrees, according to WINB’s own website. The signal can be received by several KiwiSDR receivers in Europe, as well as by the N4LGH KiwiSDR located in Florida which has the signal from the back of the beam (Fig. 1).
My friend F4MP "Zyg" emailed me kindly asking to take a look at those "combo" test signals, given that DRM  is only located in the upper 5 KHz sideband of the channel.

Fig.1 - my reception of WINB DRM tests from N4LGH KiwiSDR

Datacast rather than simulcast? 
As from ETSI TS-102-509 V1.1.1, strictly the term simulcast can be taken to describe a transmission allowing the simultaneous transmission of analogue and digital versions of the same audio programme in one frequency channel (Single Channel Simulcast, SCS). A simulcast signal signal consists of a sinusoidal carrier and two additional signal parts in the upper and lower sideband. The digital part in the upper sideband corresponds to a DRM signal, therefore a standard DRM consumer receiver will be able to extract and decode the included digital data. An analogue audio AM receiver applying envelope demodulation on the overall received signal will provide an audio signal to the listener comparable to standard AM transmission. [1] [2]
Clearly, that's not the case of WINB. Moreover, due to the fact that multipath propagation via the ionosphere is a typical characteristic of radio channels in HF broadcasting, the use of SCS is recommended only for LF and MF bands with mainly ground wave propagation.

So, what is carried by the lower sideband of the signal?
Nobody knows with certainty, at least at present when I'm writing this post. Interesting discussions on WINB DRM test transmissions can be read in the DRM Forum as well as in w4uvh site:
Oddly, on DRM Forum nobody associated with WINB has commented on the simul/datacasting although they have made several posts regarding the DRM broadcast.
Looking at FCC license for these tests we note the 10K00G9W emissions designator for the CE-50000WS transmitter beamed to north Europe (Fig. 2):

Fig. 2 - FCC license
10K00G9W designator means that WINB may transmit:
10 k = 10 kHz signal bandwidth
G = phase modulation
9 = Analog and digital channels
W = any combination of telegraphy, fax, data, telephony or video

so the license offers the chance to transmit digital signals or ordinary AM signals.
Analyzing the lower sideband of the signal I may count up to 78 unmodulated tones that could be MFSK as well as constructed using OFDM tecnology, in this case the tones have rotated phases. Likely it's a test/experimental transmission w/out data carried.
Fig. 3
Fig. 4
31 October update
I have a little but important update: some days ago I heard WINB DRM signal at my QTH on 13690 KHz, surely due to good propagation conditions. I twitted a little post and WINB answered asking a report about that reception. The most important fact is that they confirmed data transmission o the lower 5 KHz channel.

23 November update
First time, at least at my side, that I hear their emissions on 9265.0 KHz in the morning: a bit unusual band (30mt) since the time (0930 UTC). Maybe they are testing the "service" in different bands?

21 November 2018

two interesting MFSK catches

1) MFSK-66 (33+33) 40Bd/40 (presumed)
Transmission heard on 9122.0 KHz/usb on 20 November, 0832z. It looks like they use 2-tones x symbol and a manipulation speed of 40 Bd (Fig. 1). Dividing the spectrum into two equal parts gives a grid of 33 tones, 40Hz spaced, with the expected symbol rate of 40Bd (Fig. 2): this is why I defined the signal as MFSK 33+33 40Bd/40Hz, but I could be wrong. Likely Russian users.

Fig. 1
Fig. 2
Fig. 3

2) 19KHz wide MFSK-17 33.3Bd/1200Hz
Transmission heard on 13386.0 KHz/usb (centered on ~ 13397 KHz) on 20 November, 1156z. Never meet a such wide band MFSK waveform.

Fig. 4
Fig. 5


16 November 2018

email over hf using FED-1052 DLP and "IDEA" encryption (2)

Yet another interesting catch of an email-over-hf session using FED-1052 Datalink Protocol (DLP, Appendix B) and IDEA encryption. The transmission was recorded on 09187.0 KHz/usb 1357z: encrypted MIL 188-141A 2G-ALE to set up links and switch to MIL 188-110A serial tone waveform for emal traffic via FED-1052 App.B DLP (Data Link Protocol); ASCII-7 data are encrypetd using CFB64 "IDEA" algorithm. Headers are unencoded so you can read both the sender and recipient, in this sample:
sender: ZJ1, root@bfzj1f1.is.bf.intra2.admin.ch
recipient: ZA1, statist@bf.intra2.admin.ch
email ID: "stat-ZJ1-20181113135501" (2018.11.13, time: 135501)
The FQDN (Fully Qualified Domain Name) "intra2.admin.ch" indicated in the e-mail addresses suggests an intranet of the central administration of the Swiss Federation: likely this is the Swiss Army or the Diplo Service.
A more detailed post about such transmissions can be read here.

Fig. 1 - on air signals, MIL 188-110A Serial Tone waveform
Fig. 2 - FED-1052 App.B stream

12 November 2018

a mix of waveforms and modes (FSK, MFSK, OFDM)

Just another example of a mix of waveforms and modes (FSK, MFSK, OFDM) supposedly used by Russian Intel and spotted on 9122.0 KHz/USB.


7 November 2018

IP over HF via STANAG-5066 RCOP, MIL 188-110A as HF waveform

Interesting transmissions spotted on 9105.0 KHz/usb at 1240z, user/locations are unid, maybe form US-Mil stations? The transfer concerns IP-over-HF (IPoHF) via STANAG-5066 RCOP protocol [1]: 1380 bytes IP packets are exchanged in directions -> and -> , ESP (IPSec) secure protocol is used.  MIL-STD 188-110A Serial is used as the HF waveform. STANAG-5066 Addresses ( belong to US-DoD. Similar transmissions was heard on 8th October on 13378.0 KHz/usb using 188-110A and S4539 QAM-64 as HF bearers (discussed here) maybe the user is the same.
The sequence of the figures illustrates the various steps that have been performed in the analysis of the signal.

Fig. 1 - 188-110A on-air symbols
Fig. 2 - STANAG-5066 bitstream after the removal of 188-110A overhead
Fig. 3 - hex-dump after the removal of STANAG-5066

The hex-dump file resulting after the removal of STANAG-5066 PDUs encapsulations has been processed using "wireshark" software: IPv4 addresses and headers as well as IPSec encapsulation are clearly visible.

Fig. 4 -


[1] https://www.isode.com/whitepapers/ip-over-stanag-5066.html