19 September 2018

PSK-8 bursts at inconsistent 12800bps data rate, a deepen look at S4539 preamble

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)
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.
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 and Fig. 3) 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). This means that the carrier would be π shifted,
or
- the modulating phasor rotates in a clockwise direction.

In both cases, the "2,2,6" setting (the expected 3200bps) becomes "6,6,2" (the inconsistent 12800bps)!  
Maybe we should add a constant 180° shift to the 1800Hz carrier so that the demodulating phasor - which is not aware of that shift - does not get the symbols "6,6,2" but the actual "2,2,6" (ie the more reassuring 3200bps speed); but it's only a my guess.

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

Fig. 8 - demodulated streams of the 7.8 MHz cluster
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.

Fig. 9 - result of TDoA
[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 

15 September 2018

"Winnie pooh" HF test transmissions


odd wideband signals spotted recently on 9110 KHz (center frequency) and likely related to Russian tests or exercises. Transmissions (Figure 1) consist of a 3xFSK 250bd/500 waveform which occurs as stand-alone transmission or as preceding a wideband PSK waveform, the latter also heard as stand-alone. The FSK signals are 1500 Hz spaced, carry encrypted streams and occupy a 4KHz bandwidth. PSK signals exhibit a clear component in the fourth power (Figure 2) that leads to think to a QAM waveform either 5000Bd/5KHz bandwidth and 10000Bd/10KHz bandwidth. Further analysis of the IQ samples, or just further recordings, are needed to shed some light on the modulation.

Fig. 1
Fig. 2
Besides the two (new?) waveforms, the most surprising thing was hearing a short track of the Russian version of "Winnie Pooh" cartoon transmitted in DSB mode in between FSK and PSK (Figure 3): strange but true, check by yourself
- Russian cartoon track https://t.co/il9bFkhOyQ  
(at first I had mistaken its waterfall pattern as a sort of vocoder, my friend KarapuZ immediately identified it as a Winnie Pooh cartoon track).

Fig. 3
A topic was opened by KarapuZ on radioscanner ("ansanto" is my nickname there):


13 September 2018

Unid FSK 100Bd/500, T-207 encryption

Yet another (unid) FSK 100Bd/500 signal spotted on 9075.0 CF around 0810z (11 Sep) with good SNR. User is likely from Kaliningrad Oblast, contents are encrypted with T-207 system.





https://yadi.sk/d/Y29ujJhDt-EG9g
https://yadi.sk/d/xYkIjgOZXOYErQ


10 September 2018

LINK-11 SLEW, properties of the acquisition preamble sequence

(thanks to Christoph for his Octave hints and collaboration) 

Since some weeks I'm studying the symbols sequence which is used to form the Link-11 SLEW acquisition preamble, the reason is that - quoting STANAG-5511 - "the acquisition preamble [...] consists of a 192 tri-bit known sequence generated from a pseudo random code": well, from waht I can see I don't think so. In my opinion the preamble sequence has been accurately studied and designed and in this post I try to argue the reasons.
The preamble sequence (used to define the start of a transmission, AGC, signal detection, synchronization, doppler requirements and equalization) is reported in S5515 as:

7 0 3 4 1 1 1 0 2 6 1 5 1 7 0 3 5 4 2 2 6 1 2 2 0 4 5 4 1 2 2 6
7 0 7 0 1 1 5 4 2 6 5 1 1 7 4 7 5 4 6 6 6 1 6 6 0 4 1 0 1 2 6 2
7 4 7 4 1 5 5 0 2 2 5 5 1 3 4 3 5 0 6 2 6 5 6 2 0 0 1 4 1 6 6 6
7 0 3 4 5 5 5 4 2 6 1 5 5 3 4 7 5 4 2 2 2 5 6 6 0 4 5 4 5 6 6 2
7 4 3 0 1 5 1 4 2 2 1 1 1 3 0 7 5 0 2 6 6 5 2 6 0 0 5 0 1 6 2 2
7 4 3 0 5 1 5 0 2 2 1 1 5 7 4 3 5 0 2 6 2 1 6 2 0 0 5 0 5 2 6 6

and according to #10.1.1.1 "these symbols are not scrambled and are applied directly to the 8 PSK modulator".


A first oddity - see Figure 1a - is that after the mapping of the complex symbols onto a PSK-8 constellation we don't get all the possible PSK-8 transitions as it happens for example by mapping the preamble sequence symbols of STANAG-4539 or a random sequence of PSK-8 symbols. A second puculiarity is that the preamble has a clear period of 96 bits (ie 32 tribit symbols) , which may be detected by BEE editor (see Figure 1b) and emphasized by plotting the matrix of complex symbols versus the columns (the two diagrams at the bottom of Figure 1a). 

Fig. 1a
Fig. 1-b

As a characteristic of PSK-n signals [1], the process of squaring a PSK-8 transforms the signal into a QPSK modulation (at twice the frequency); my friend Christoph pointed out to me that after the squaring of the preamble we get 6 repeating QPSK patterns, each 32 symbols long (1):

6 0 6 0 2 2 2 0 4 4 2 2 2 6 0 6 2 0 4 4 4 2 4 4 0 0 2 0 2 4 4 4
6 0 6 0 2 2 2 0 4 4 2 2 2 6 0 6 2 0 4 4 4 2 4 4 0 0 2 0 2 4 4 4
6 0 6 0 2 2 2 0 4 4 2 2 2 6 0 6 2 0 4 4 4 2 4 4 0 0 2 0 2 4 4 4
6 0 6 0 2 2 2 0 4 4 2 2 2 6 0 6 2 0 4 4 4 2 4 4 0 0 2 0 2 4 4 4
6 0 6 0 2 2 2 0 4 4 2 2 2 6 0 6 2 0 4 4 4 2 4 4 0 0 2 0 2 4 4 4
6 0 6 0 2 2 2 0 4 4 2 2 2 6 0 6 2 0 4 4 4 2 4 4 0 0 2 0 2 4 4 4


That's another oddity, or - better - another property of Link-11 SLEW preamble.

Christoph also noticed some other features of Link-11 preamble, but just the squared sequence is interesting for its "analogy" with the preamble used in STANAG-4285 (both consist of periodic sequences). 
Indeed, the periodic sequence of the squared preamble symbols can be assumed as a reference and - as it happens in S4285 - may be used to perform Doppler effetcs estimation by continuous correlation of the squared received sequence with the reference (S4285 adopts this method using the 31-symbol PSK-2 preamble sequence as reference for Doppler and sync acquisition [2]). Figure 2 shows the two reference sequences: notice the QPSK constellation of the squared L11 preamble. In my guess this is another point in favor of a designed preamble sequence.

Fig. 2
I wanted to look for evidences and confirmations from the analysis of a sample of a Link-11 SLEW signal [3], identifying and demodulating a preamble sequences (Figure 3).

Fig. 3

received preamble symbols:
5 6 0 6 3 4 2 7 1 6 3 1 5 1 7 0 4 0 3 2 6 1 2 2 0 4 5 4 1 2 2 6
7 0 7 0 1 1 5 4 2 6 5 1 1 7 4 7 5 4 6 6 6 1 6 6 0 4 1 0 1 2 6 2
7 4 7 4 1 6 5 0 2 2 6 5 1 3 5 3 5 1 6 2 6 5 6 2 0 0 1 4 1 6 6 6
7 0 3 4 5 5 6 4 2 6 1 5 5 3 4 7 5 4 2 2 2 5 6 6 0 4 5 4 5 6 6 2
7 4 3 0 1 5 1 4 2 2 1 1 1 3 0 7 5 0 2 6 6 5 2 5 0 0 5 0 1 6 2 2
7 4 3 0 5 1 5 0 2 2 1 1 5 7 4 3 5 0 2 6 2 1 6 2 0 0 5 0 5 2 6 6

after its squaring:

2 4 0 4 6 0 4 6 2 4 6 2 2 2 6 0 0 0 6 4 4 2 4 4 0 0 2 0 2 4 4 4
6 0 6 0 2 2 2 0 4 4 2 2 2 6 0 6 2 0 4 4 4 2 4 4 0 0 2 0 2 4 4 4
6 0 6 0 2 4 2 0 4 4 4 2 2 6 2 6 2 2 4 4 4 2 4 4 0 0 2 0 2 4 4 4
6 0 6 0 2 2 4 0 4 4 2 2 2 6 0 6 2 0 4 4 4 2 4 4 0 0 2 0 2 4 4 4
6 0 6 0 2 2 2 0 4 4 2 2 2 6 0 6 2 0 4 4 4 2 4 2 0 0 2 0 2 4 4 4
6 0 6 0 2 2 2 0 4 4 2 2 2 6 0 6 2 0 4 4 4 2 4 4 0 0 2 0 2 4 4 4


The difference between the reference and the received sequences are shown in Figure 4, notice that only the sequences #2 and #6 are received w/out errors.

Fig. 4
Figure 5 shows the results of the cross-correlations of the reference with the received sequences: the upper side concerns the tribit symbols while the lower side concerns PSK-8 symbols. I have to say that in this example the received PSK-8 symbols are not the actual ones since they are re-mapped at demodulation time; the tribit symbols instead are the actual ones.
Fig. 5
I am quite positive that the results would have been more complete and meaningful if I had extracted all the preamble sequences from the Link-11 transmission or if I had used only I/Q values. By the way, Christoph emailed me saying that he worked a link11 SLEW sample and the cross-correlations shows the expected results so that the doppler and frequency offset can be estimated: he's a skilled guy so hope to read soon such a post in his blog.

In conclusion, from what seen above, I do not think that Link-11 SLEW preamble is a sequence which is "generated from a pseudo random code" - by the way, so far I have not yet found a polynomial generator - but rather it seems a designed sequence or source algorithm (e.g. S4285 and S4539 do not talk of preamble sequences in such terms).


(1)
if "z" is a complex symbol and "s" is a tribit symbol, then:
z^2 corresponds to mod(2*s, 8)


3 September 2018

LINK-11 SLEW, transmission format


The SLEW waveform transmission format consists of an acquisition preamble followed by two or more fields, each field followed by a reinsertion probe. 
The first field immediately following the preamble is the header field and contains information that is used by the Combat Data System (CDS) and the encryption device. If a network PU (Partecipating Unit) has data to transmit, successive data fields follow the reinsertion probe of the preceding fields. These data fields consist of track data and other user data. The last field to be transmitted is the end-of-message (EOM) field. The transmission ends with a reinsertion probe.

Fig. 1

Data are accommodated using 3 different types of fields: header field, CDS data field and EOM field. The acquisition preamble, a very interesting topic, will be discussed in a next post.

The structure of the header field  consists of 33 data bits appended with 12 error detection bits (CRC). This 45 bit sequence is encoded with a 1/2 rate error correction code resulting in a 90 bit field. The header field contains information to define (Figure 2): 
the transmission type T (1 bit),
the Picket address ADDR (6 bits), 
the KG-40 Message Indicator MI (24 bits), 
the NCS/Picket designation N (1 bit),
a spare field SP (1 Bit).
Fig. 2 - Link-11 SLEW header field
The transmission type (T) indicates the format of the transmission to follow: is set to 0 to indicate an NCS Interrogation Message (IM) and is set to 1 to indicate a NCS Interrogation with Message (IWM) or a Picket reply transmission (the term picket indicates a PU on the network that is not the NCS).
The KG-40 Message Indicator subfield contains the sequence generated by the KG-40 crypto device. Cryptographic synchronization is achieved when the receiver acquires the correct MI. Since 24 bits is the length used by the Golay code, I tried to verify if the KG-40 MI was really coded using the extended Golay (24,12) ...but without success. For an NCS interrogation transmission (tramission type subfield = 0), this subfield will contain all zeros since no message is carried.
The address subfield  ADDR contains either the address of the next Picket to be interrogated or the address of the Picket that initiated the current transmission: note that only Pickets addresses are exposed.
The NCS/Picket designation (N)  identifies whether the current transmission originates from the NCS or from a Picket: 0 indicates an NCS transmission, 1 indicates a Picket transmission.

The structure of the CDC data field consists of 48 data bits (two standard 24 bit CDS frames seen in CLEW waveform) appended with 12 error detection bits that are encoded with 2/3 rate error correction code resulting in a 90 bit data field. 
The EOM field is used to indicate the end of the transmission and consists of a sequence of 90 bits. No error detection or correction bits are applied to this field. The sequence depends on the unit that is transmitting:
An EOM from the NCS is a 90 bit sequence of all “0”
An EOM from a Picket is a 90 bit sequence of all “1”
Below an example where all the SLEW fields are visible:

100101000110111110001110000011111 000001111100
100010100010001011000001101110010000101011110011 011001011010
111000010110000011110010111001001000000001110000 111100101001
011000001000110111001101100000001100011010110011 001111011101
111001010110100001101001111101011000101011010100 001110110011
111111111111111111111111111111111111111111111111

100101010001100001001000111101001 001101011111
111111010001010101000001001101001111111111101001 001110110000
000111000100111011000110010010001001111110011110 100010111111
001100111011011100100100010000110000001100101110 011101010010
111001100100110100111100010001100010100100011101 100100001111
000000000000000000000000000000000000000000000000

100101001110110010000010101000011 001111010111
100101110000001100001111011000110111011101110111 001111001101
110011011001010000111110011001100101100111110000 011111110010
000111101110101111010000101001011010010100010010 010100001110
100011010110110101111100001110111000011011111010 100010011011
111111111111111111111111111111111111111111111111 


It's interesting to analyze the headers related to the SLEW transmissions shown in Figure 3 

Fig. 3 - SLEW transmissions headers
In all the headers the transmission type subfields (T) are set to 1 to indicate that the following data sub-fields are NCS transmissions or Picket reply transmissions.
In the first header the NCS/Picket designation subfield (N) is et to 0 to indicate an NCS transmission: in this case the 6-bit subfield address identifies the address of the Picket to be interrogated (010100). In the second header the NCS/Picket designation is set to 1 to idicate the Picket reply transmission: in this case the 6-bit address identifies the address of the Picket which initiated the transmission (010100). You may check that
the other headers are interpretable in the same way. So, the headers indicate a series of IWMs and replies between the NCS and the Picket station addressed by 010100. 

2 September 2018

DHFCS 1536-bit TDM protocol (2)

In the previous post I associated the 1536-bit TDM protocol to the DHFCS network, and that's correct, but I wrongly ascribed this protocol to Rockwell Collins. Indeed, looking carefully at the two slides below you can see that they refer to the products GA-123 (HF modem) and GA-205 (TDM multiplexer), both are produced by DRS Technology, a Leonardo (formerly Finmeccanica) company.

Fig. 1
Reading the GA-205 datasheet [1] we can shed a bit of light on the 1536-bit protocol: GA-205 is a 12-channel Time Division Multiplexer (TDM) that provides full-duplex and half-duplex transmission and reception of data at selectable user port rates of 75 x 2n up to 9,600 bps. The system accommodates user data that do not share common timing sources and provides for isochronous, bit stuff, synchronous and asynchronous operation.

Fig. 2 - the GA-205 multiplexer

In Time Division Multiplexing (TDM) the communication resource is shared by assigning input channels the full spectral occupancy of the system for a fixed duration of time called time slots.
Synchronous TDM works by the muliplexer giving exactly the same time slot to each device connected to it even if one or more devices have nothing to transmit. The data rates of different input devices control the number of the slots: a device may have one slot, other may have two or three according to their data rate. 
Asynchronous TDM, or statistical TDM, is a more flexible method of TDM since slots are assigned dynamically as needed, ie slots are not assigned to devices that have nothing to transmit. Variable-Length Time Slots Asynchronous TDM can accommodate traffic of varying data rates by varying the length of the time slots. Stations transmitting at a faster data rate can be given a longer slot.

Since GA-205 multiplexer can handle up to 12 channels, the four ports you see in Figure 1 can be misleading: it is possible that the "preset" shown in the screenshot (identified as TDM1 in the upper right), refers to a particular configuration used to manage only 4 input channels of the 12 available. Maybe a default? who knows, the slide dates back to 2006. Notice that in the shown preset the input channels exhibit different baud rates: 600, 300, and 75. In that condition, bit stuffig or variable length slots can be used.
 

Given the above considerations:
1) at most, the DHFCS 1536-bit format carries up to 12 channels (by the way, 1536 bits = 1024+512, ie 1.5 Kb);
2) managing TDM requires that some control bits (sync, device tagging, ...) be appended to the beginning of each slot and this overhead is clearly part of the raw bitstream that we get after S4285 removal;
3) since we do not manage the control bits, when the the GA-205 is used in async mode we can't say the number of the channels currently transmitted; as well as we do not know the number of "traffic" channels when GA-205 is used in sync mode.

My guess is that the 1536-bit period could be the frame length (the slots gathered in a complete cycle), no matter if GA-205 works in sync or async mode. 
Channels are encrypted individually before being applied to the multiplexer, they probably use BID-950 or KIV-7 (KIV-7 may work as KW-46).

DHFCS STANAG-4285 stations logged and DF'ed so far:
05553.2 Cyprus Is.
07937.0 Crimond 
11015.0 Crimond 
14390.0 Ascension Is. 
14548.2 Cyprus Is. 
15812.1 Cyprus Is.
16106.3 St. Eval 
16287.0 Ascension Is. 
16398.2 Cyprus Is.







[1] http://www.drs-ds.com/media/1414/ga205.pdf

25 August 2018

a Rockwell Collins/DHFCS 1536-bit TDM protocol (1)

This afternoon I spotted a STANAG-4285 1200bps/L transmission on 7937.0 KHz/usb carrying the 1536-bit TDM data protocol already seen in some previous records here and here. The most important thing is that the signal, with very a good reliability, comes from the RNAS Rattray (Royal Naval Air Station) near Crimond, Aberdeenshire (UK) and I remembered that a transmission that had the same characteristics (STANAG-4285 1200bps/L, 1536-bit protocol) was identified as coming from Cyprus Island (Figure 1).

Fig. 1
Well, both the stations belong to the Defence High Frequency Communications Service (DHFCS),  a British military beyond line-of-sight communication system operated by the Ministry of Defence (MOD) and used predominately by the Royal Air Force, Royal Navy and British Army, as well as other authorised users (Fig. 2).
Fig. 2 
This being said, it's likely to assume that the 1536-bit TDMA format is a proprietary protocol of used by DHFCS, maybe developed by Rockwell Collins who deployed the system? Some interesting information about DHFCS can be read from some presentations held in HFIA meetings. In particular, in the slides of Rockwell Collins - albeit a little dated - some screenshots related to the modem preset are shown where it is possible to see the setup of the waveform 4285 at 1200 bps/Long interleaver in async mode as well as the the GA-205 TDM multiplexer preset (Figs. 3,4). 

Fig. 3
Fig. 4
It is noteworthy that these slides date back to 2006.


27 August 2018 update
as expected, 14390.0 and 16287.0 transmissions (S4285 1200bps/L & 1536-bit TDM protocol) are from Ascension Island, overseas DHFCS stations:

Fig.5
Fig.6
Ffrequencies logged and DF'ed so far:

05553.2
07937.0 (1)
11015.0 (1)
14390.0 (3)
14403.2
14548.2 (2)
16106.3
16287.0 (3)

(1) Crimond
(2) Cyprus Is.
(3) Ascension Is.

(continued here)

24 August 2018

recent logs

05089.0: ---: Swiss AF, SUI 0610 VFT-TMS430 2x100Bd/170 (channels cf at -500, +500Hz) (10Jul18) (AAI)
05689.0: HWK01: Swedish Mil, S 1006 USB 3G-HF 1-way FLSU flwd by 188-110A Serial, Circuit Mode tfc to VJL, S5066 unid UDOP client (10Jul18) (AAI) 
06690.0: ---: Unid 0627 USB two stations in simplex exchanging KG-84 encrypted msg using 188-110A and S4539 (10Jul18) (AAI)
06931.0: ---: Unid (prob. from Croatia) 0620 USB STANAG-4285 variant 600bps/S, 2 stations in simplex exchanging 128-bit MI encrypted msgs (26Jun18) (AAI)
06955.0: TWBH6: Guardia Civil, Huesca E USB 188-141A, sounding (29Jun18) (AAI)
06992.0: ---: Unid 0550 USB 3G-HF 2-way FLSU / circuit mode service 188-110A Serial (29Jun18) (AAI)
07602.0: TWBH6: Guardia Civil Huesca, E 0559 USB 188-141A, sounding (22Jun18) (AAI)
07665.0: 811001: Unid presumed Kyrgyzstan Net, KGZ 0651 USB 188-141A, sounding (10Jul18) (AAI)
07676.0: ---: Russian Ny, RUS 0618 (CF) FSK 500Bd/1000 "Akula" (10Jul18) (AAI)
08086.5: IGLS: Italian Ny Coast Guard patrol boat CP857, I 0735 J3E/USB voice comms with COMPAMARE Roma-Fiumicino (27Jul18) (AAI)
08150.0: 2016: Unid 0553 USB 188-141A handshake 4017, short op-chat (22Jun18) (AAI)
08150.0: 4015: Unid 0555 USB 188-141A sounding (22Jun18) (AAI)
08196.5: IGQX: Italian Ny Coast Guard patrol boat CP826, I 0940 J3E/USB voice comms with ICI09 Venice shore station (17Jul18) (AAI)
08207.0: 0A: Maltese Navy, MLT 1012 J3E/USB voice comms between callsigns 0A (= ALE "ABA") and SA (14Jul18) (AAI)
08218.0: ---: Unid 0603 USB 3G-HF 2-way FLSU handshake / HDL+ transfer (22Jun18) (AAI)
08532.5: XNA: DHFCS, UK 1255 USB 188-141A 2-way handshake XSS flwd by 188-110A Serial (10Jul18) (AAI)
09123.0: CENTR2: Rou-MAECT Centrala2 Bucharest, ROU 0751 USB USB 188-141A handshake ZMF (Geneva embassy) / 188-110A, STANAG 5066 mail tfc using Harris RF-67x0 GW (06Aug18) (AAI)
09187.0: ZJ1: Swiss Army, CH 0757 USB 188-141A 'linking protection' handshake ZA1 flwd by 188-110A/FED-1052, FED-1052 App.B to deliver "IDEA" encrypted email file (20Aug18) (AAI)
09309.0: MIR: Roumenian Police Miercurea, ROU USB 188-141A, calling 1PY (20Aug18) (AAI)
10170.0: ---: Russian Mil/Gov, RUS 0634 CIS-VFT/3x100/1440, T-207 encryption (10Jul18) (AAI)
10211.2: ---: Polish Intel, POL 1000 (cf) FSK 400Bd/800, rptd at 1005 (19Jul18) (AAI)
10498.0: CDG01D: French Ny Carrier "Charles de Gaulle", F 0805 USB 188-141A handshake FUO01D Toulon flwd by STANAG-4285 300bps/S, KG-84 encrypted traffic (17Jul18) (AAI)
10648.0: 134: (short for 134001) Turkish Emergency Net, TUR 0743 USB 188-141A calling 106 (short for 106001, Ankara) (29Jun18) (AAI)
10914.0: GWPWBL: Brasilian Navy Training Ship U-27,B 0758 USB 188-141A, sounding (16Aug18)(AAI)
10914.0: GWPWBL: Brasilian Navy Training Ship U-27,B 0801 USB 188-141A, calling GWPWB33 Naval Base of Rio de Janeiro (16Aug18)(AAI)
11050.0: AK01: Algerian Mil, ALG 0945 USB 188-141A, calling XV01 (17Aug18) (AAI)
11082.0: TM4CEE: Unid 0744 USB 188-141A calling TM2CEE (22Jun18) (AAI)
11245.0: ---: Unid Chinese net, C 1509 LSB Chinese 4+4 p/4 DQPSK 75Bd modem (17Aug18) (AAI)
11413.0: AQB: Iraqi Emergency Response Forces, IRQ 1502 USB 188-141A, sounding  (17Aug18) (AAI)
11413.0: MFQ: Iraqi Emergency Response Forces, IRQ 1500 USB 188-141A, sounding  (17Aug18) (AAI)
11430.0: ---: Unid 0708 USB 3G-HF 2-way FLSU handshake / HDL+ transfer (24Aug18) (AAI)
12431.0: URSO: Guardia di Finanza Patrol Boat Urso G121, I 0858 USB 188-141A, calling BARI (15Jul18) (AAI)
12773.0: ---: Unid 0729 USB 3G-HF/S-4538 FLSU Async call (16Aug18)(AAI)
13490.0: ---: Unid 0905 USB 188-141A Linking protection mode flwd by 188-110A 75bpsL (Moroccan Civil Defence freq.) (17Jul18) (AAI)
13531.0: ---: Unid 0725 USB 3G-HF FLSU Async call (19Jul18) (AAI)
15888.0: ZJ1: Swiss Army, CH 0734 USB 188-141A 'linking protection' handshake ZA1 flwd by 188-110A, FED-1052 App.B to deliver "IDEA" encrypted email file (30Jul18) (AAI)
16175.0: ---: Russian Mil/Gov, RUS 0720 USB CIS-VFT 3x100/1440, T-207 encryption (26Jul18) (AAI)

23 August 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
By the way, another unknown to me 5 KHz DRM station can be tuned on 4770 KHz: just another (incomplete) simulcast?
 
Fig. 5
 

22 August 2018

the unid Kongsfjord OFDM (2)

As said in the previous post, these signals could also belong to a Narrowband (Under 500 kHz) Power Line Communications (NB-PLC) system. Just to investigate this second hypothesis, my friend Bjarne conducted a series of interesting measurements directly on the site since he's the owner of the Kongsfjord KiwiSDR. Below in Fig. 1 the map with time and locations of the measurements (blue squares) and the power grid layout (Kongsfjord transformation station is indicated with the red square).

Fig.1 - Power Grid layout and location of measurements
Quoting the eamil sent me by Bjarne "Last weekend I did some noise measurements on different locations nearby my QTH: one very close to the transformation station in Kongsfjord, and one furthest away 25 km by road. Receiver was RSP1A at 1536 kHz sampling, connected to a Microsoft Surface Pro3 running on battery. The antenna was a Wellbrook loop, powered from an external battery. So everything was off-grid. I did note some interesting variations below 500 kHz as I rotated the loop. The wav file 20180818_110154Z shows a recording taken 100 meters from the transformation station: first, pointing at the station, then rotated for maximum null.".
RF wav files were recorded in HDSDR, so I used that program for playback as well. Figure 2 is related to the playback of the file recorded close to the transformation station (20180818_110154Z) and shows the moment of the antenna rotation:

Fig. 2 - 20180818_110154Z recording
Figure 3 shows the same test performed at the second location (20180818_104203Z):

Fig. 3 - 20180818_104203Z recording
We are beginning to think that the signal may be associated with power lines after all? I think we'll end up asking for a clarification from the power company, that's the better choice.

By the way, while in July we could see up to four signals, since 16 August we see only twos (#3 and #4 consisting of single tones)

Fig- 4
 (to be continued)