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 recordings discussed here. The most important thing is that the signal, with very a good reliability, comes from the RNAS (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

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



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)

14 August 2018

LINK-11 SLEW, Systematic CRC check matrix

In Link-11 SLEW the error detection encoding is applied to all 48-bit data words within each type of field with the exception of the EOM field. The encoding scheme uses Cyclic Redundancy Check (CRC) which is generated using a 12-bit Shift Register defined by the polynomial x12 + x10 + x8 + x5 + x4 + x3 + 1, and producing the Link-11 SLEW 60-bit (48+12) encoded frames.
Quoting STANAG-5511 Annex-B §11.1.1.1 "The data is shifted serially into the Shift Register starting with the most significant bit (MSB) until the least significant bit (LSB) has been applied to the input stage of the Shift Register. This accomplishes a division of the data by the polynomial that defines the Shift Register. The remainder of the division is represented by the values in each stage of the Shift Register: these 12 values are appended to the data bits as parity, creating a systematic code".
Systematic codes have the advantage that the parity data can simply be appended to the source block, and receivers do not need to recover the original source data if received correctly since they are located in the leftmost bits of the received data (this explains because systematic code is also called “Separable”). The standard CRC encoder is different from the Systematic CRC encoder in the way the encoded word is calculated, therefore the data bits cannot be separated from encoded word before decoding takes place. 

In my opinion, actually STANAG-5511 seems to describe the "systematic CRC decoder" rather than the "systematic CRC encoder": indeed, the decoder just works by getting the input encoded word, which might contain errors, and dividing it by the generator polynomial to get the remainder (i.e. calculating E(x) mod G(x) and getting R(x)). If remainder of division is zero then the encoded word has no errors, otherwise error is detected with a non-zero remainder [1]. 
That said, the systematic generator matrix is obtained by selecting as rows the codewords associated with the 12-bit fields 100000000000, 010000000000, ..., and 000000000001. Well, my friend cryptomaster worked on the 4095-bit maximum-length sequence produced by the generator polynomial x12 + x10 + x8 + x5 + x4 + x3 + 1 obtaining the 12-row 60-column matrix that is shown below as composed of the Link-11 "check" and "identity" sub-matrices:

check matrix                                                           identity  
111100110100011000110111111001001001110101100010 100000000000
011110011010001100011011111100100100111010110001 010000000000
110011111001011110111010000111011011101000111010 001000000000
111001111100101111011101000011101101110100011101 000100000000
100000001010001111011001011000111111001111101100 000010000000
110000000101000111101100101100011111100111110110 000001000000
011000000010100011110110010110001111110011111011 000000100000
010000110101001001001100110010001110001100011111 000000010000
110100101110111100010001100000001110110011101101 000000001000
100110100011000110111111001001001110101100010100 000000000100
110011010001100011011111100100100111010110001010 000000000010
111001101000110001101111110010010011101011000101 000000000001

If an error is detected with a non-zero remainder, the error can be corrected just using the check matrix. 
Code verification is carried out by comparing each line of encoded data in turn with all rows of the check sub-matrix: the vertical correspondences of the "ones" locations in the encode line and in the row #n of the check sub-matrix are counted. If the matches are even then the CRC bit #n will be "0", otherwhise (ie matches are a odd number) the CRC bit #n will be "1".

Let's try a verification for the first 60-bit encoded in Fig.1

Fig. 1

48-bit data                                                                    12-bit CRC
111011100101011011110011001001101010001000010100 011000011001
111100110100011000110111111001001001110101100010 check sub-matrix row #1
14 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
011110011010001100011011111100100100111010110001 row #2
11 matches (odd), CRC bit value:  1

111011100101011011110011001001101010001000010100 011000011001
110011111001011110111010000111011011101000111010 row #3
17 matches (odd), CRC bit value:  1

111011100101011011110011001001101010001000010100 011000011001
111001111100101111011101000011101101110100011101 row #4
16 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
111001111100101111011101000011101101110100011101 row #5
16 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
100000001010001111011001011000111111001111101100 row #6
12 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
011000000010100011110110010110001111110011111011 row #7
10 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
010000110101001001001100110010001110001100011111 row #8
11 matches (odd), CRC bit value:  1

111011100101011011110011001001101010001000010100 011000011001
110100101110111100010001100000001110110011101101 row #9
11 matches (odd), CRC bit value:  1

111011100101011011110011001001101010001000010100 011000011001
100110100011000110111111001001001110101100010100 row #10
16 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
110011010001100011011111100100100111010110001010 row #11
12 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
111001101000110001101111110010010011101011000101 row #12
13 matches (odd), CRC bit value:  1

as expected, the 12-bit CRC added to the first 48-bit frame is:
011000011001.

If you want try by yourself, the last 60-bit sequence consisting of all "ones" could be a segment of the picket EOM and no error detection or correction bits are applied to this field! (Link-11 fileds will be treated in a next post).
Notice that Link-11 SLEW uses also 1/2 rate and 2/3 rate convolutional encoders to improve the reliability of the system, while CLEW does not use convolutional encoders and employs Hamming (30,24) encoding with the overall parity bit:
https://i56578-swl.blogspot.com/2018/08/link-11-clew-hamming-check-matrix.html 

That said, and if me and cryptomaster are right, STANAG-5511 is not so clear in the pages related to CRC Data Encoding.

https://yadi.sk/d/C-GO-nbl3aBYKr
https://yadi.sk/d/l_2IQJrP3aBYbV

[1] http://www.ecs.umass.edu/.../SystematicCRChelp.html

10 August 2018

LINK-11 CLEW, doubts about the generator polynomial x^5+x+1

I have some doubts about the description at page 19 of MIL 188-203-1A (Tadil-A/Link-11) [1]: the document states that the Start Code and the Address Code frames " [...] are equivalent to 60-bit portions of the maximum-length shift register sequence with generator polynomial G(x) =  x5+x+1" ...but such a fifth grade polinomyal has a maximum length sequence (MLS) of 31 bits (25-1). Indeed, I found the generator polymonial x6+x+1, whose MLS is 63, for both start and address frames:
 
111100101000110000100000111111
101100110111011010010011100010
100001000001111110101011001101
110100100111000101111001010001

Using a GNU Octave script [2] I also checked the three fundamental properties of LFSR maximum length sequences: Balance Property, Runlength Property, and Autocorrelation Property [3]: verification fails for x5+x+1

  • The Code does NOT satisfy Balance Property: number of 1s and 0s are 17 14
  • The code does NOT satisfy RUN LENGTH property: the run length is 10    2    1    1    2
  • The Code does NOT satisfy the Autocorrelation Property

  while verification is ok for x6+x+1 
  • The Code satisfies Balance Property: number of 1s and 0s are 32 31
  • The code satisfies RUN LENGTH property: the run length is 16    8    4    2    1    1
  • The Code satisfies the Autocorrelation Property


So I do not know if I'm wrong or if there's a typo in 188-203-1A, comments are welcome.

4 August 2018

LINK-11 CLEW, Hamming check matrix

The check of a Link-11 CLEW stream discussed in the end part of this post, can be speed up by using the Hamming check matrix for the H(30,24) coding, ie a 30-bit code word consisting of 24 bits for data + 6 bits for Hamming parity bits (termed EDAC in Link-11 literature). The check matrix is constructed as shown in MIL 188-203-1A #5.2.4.1 and here.

Code verification is carried out by comparing each line of code in turn with all rows of the check matrix, except the extra parity line (the overall parity bit): the vertical correspondences of the "1" locations in the code line and in the row #n of the check sub matrix are counted. If the matches are even then the correspondent location #n in the EDAC bits will be "1", otherwhise (ie matches are a odd number) will be "0" (odd parity).
 
  EDAC           data
110100 000001110101110001100010
010011 111001110010010001111011
110100 111100101110010110011111
100100 010111010000110110000110
010010 011010000000010100100111
110001 010001110110000010010000

     check sub-matrix           identity sub-matrix
111111111111100000000000 010000
111111000000011111110000 001000
110000111100011110001110 000100
001100110011011001101101 000010
101010101010110101011011 000001
111111111111111111111111 111111
Test the first line of code 000001110101110001100010

000001110101110001100010
111111111111100000000000 check matrix line #0
6 matches, EDAC bit #0 shall be 1

000001110101110001100010
111111000000011111110000 check matrix line #1
4 matches, EDAC bit #1 shall be 1

000001110101110001100010
110000111100011110001110 check matrix line #2
5 matches, EDAC bit #2 shall be 0

000001110101110001100010
001100110011011001101101 check matrix line #3
6 matches, EDAC bit #3 shall be 1

000001110101110001100010
101010101010110101011011 check matrix line #4   
5 matches, EDAC bit #4 shall be 0
EDAC bits 0-4: 11010

Test the second line of code 111001110010010001111011

111001110010010001111011
111111111111100000000000 check matrix line #0
7 matches, EDAC bit #0 shall be 0

111001110010010001111011
111111000000011111110000 check matrix line #1
8 matches, EDAC bit #1 shall be 1

111001110010010001111011
110000111100011110001110 check matrix line #2
7 matches, EDAC bit #2 shall be 0

111001110010010001111011
001100110011011001101101 check matrix line #3
9 matches, EDAC bit #3 shall be 0

111001110010010001111011
101010101010110101011011 check matrix line #4   
10 matches, EDAC bit #4 shall be 1

EDAC bits 0-4: 01001
The verification of the remaining combinations confirms the use of the same method of checking (if you want, you can check it yourself).

If only one error is detected, it is corrected and sent to the computer. The computer is also advised that the word contained an error and that it is corrected. If two errors are detected the Hamming decoding can only determine that errors exist but cannot determine which bits are in error.