18 January 2020

unid SkyOFDM 28-tone 86Hz 65.6Bd PSK2

Continuous ofdm bursts transmission picked up on 4158 KHz/USB thanks to the "ArcticSDR" in Kongsfjord Arctic Norway: a KiwiSDR managed by my friend Bjarne Mjelde

Timings of the transmission and its spectrum are shown in Fig. 1 

Fig. 1 - timing and spectrum
The analysis of the OFDM signal clearly shows 28 channels and a frequency spacing of ~86 Hz, each channel is modulated using PSK2 at the symbol rate of 65.57 Bd (Fig. 2). The same results are obtained/verified by analyzing a single channel as shown in Fig. 3 (higher channel).
Fig. 2 - OFDM analysis
Fig. 3 - anlysis of the higher channel (#28)
As you see in Fig. 2, I did a further analysis after resampling the signal at 10109 Hz. Indeed, I used the tool OCG [1] in order to calculate and sythesize an OFDM waveform having the same parameters (channels, Br, Shift, modulation, width,...) and got 10109 Hz as one of the possible "native" sampling rate. The analysis of the synthesized OFDM is visible in fig. 4: notice the similarity between the PSK2 constellation of the synthesized signal and the one of the real signal (although resampled).

Fig. 4 - analysis of the synthesized OFdM-28 signal
The seven initial tones last 30 symbol periods and are derived from the OFDM generator as shown in Fig. 5; more precisely the used tones are: 2, 5, 6, 9, 13, 16, and 19.

Fig. 5 - initial seven unmodulated tones
The autocorrelation has a value of 76.2 ms (Fig. 6) that makes a 140 symbols length frame if considering an aggregate speed of ~1836 Bd (65.57 x 28).

Fig. 6 - autocorrelation
A similar OFDM waveform but with shorter and different bursts (Fig. 7) was reported on 2016.02.05 by my friend Cryptomaster [2] just on the same frequency of 4158 KHz/USB. In that case the modulation used was a form of PSK4, anyway number of tones, shift, Br, and ACF are the same; thus, that signal is on-air since several years.

Fig. 7
As regards the signal source, several TDoA tries always indicated an area north to Helsinki as probable Tx site (Fig. 8) although qrg.globaltuners.com reports exactly the same waveform/spectrum (and frequency too) indicating it as a signal sourced by the Spanish Navy [3].  In my opinion that's quite odd since the signal is fairly well received in the northern European countries such as Sweden, Norway, and Finland, while it is rather weak or inaudible at all in south Europe... I don't think of such a long skip.

Fig. 8 - TDoA reults

In my opinion it's an evolution of the original Skysweep Technologies proprietary waveform named "SkyOFDM", probably used by Finnish MFA (thanks to Roland Proesch for the hint). Indeed, the mentioned recording by my friend Cryptomaster just matches the features of the "original" SkyOFDM waveform (Fig. 9).

Fig. 9 - Skysweep Technologies OFDM-28

It's worth noting that SkySweeper Pro 5.13 software does not recognize the "new" OFDM-28 PSK2 that is analyzed  in this post.
(to be continued)


[1] OCG is a program for calculating and synthesizing OFDM signals, it can be downloaded from here
[2] http://www.radioscanner.ru/files/unknown/file19060/
[3] http://qrg.globaltuners.com/details.php?id=17420

13 January 2020

COMSEC transmissions using a S4285 variant (2)

Secured burst transmission using a modified S4285 waveform [1] spotted around midnight on 4015 KHz/usb, the S4285 mode is 600bps and short interleaver. 

Fig. 1
After demodulation, the COMSEC preamble resembles 188-220D std and consists of 3 parts (my guess):
1) 60-bit Frame Sync (110000100000111000101111001011011101101001001011111010101100)
2) 5 x 128-bit strings, encoded Message Indicator (five times repeated)
3) 64-bit idling sequence (time to load the key?)

Preamble is followed by the encrypted data block which ends with "01" sequences.
Fig. 2 - demodulated stream of bursts

Fig. 3 - COMSEC preamble (my guess)

https://yadi.sk/d/nY-DTuTz-ZWG8g  (2020-01-10T005300Z, 4.015 MHz, USB.wav)
https://yadi.sk/d/oIHVEWbUO0_few   (2020-01-10T010336Z, 4.015 MHz, USB.bin)

[1] The same modified S4285 waveform was met here on 6931 KHz/usb:

Speed distortion in an FSK signal

Most likely modem instability is the cause of the distortion in the manipulation speed (~42 bps), as it's evident in SA raster.


2 December 2019

Unid FSK 400 (401)Bd/800 bursts
(i56578, cryptomaster, KarapuZ)

Unid FSK 400Bd (401)/800 bursts spotted on 13224.0 Khz (cf + 1700), slight distorsion in the speed. ACF=0, no other results if demodulated using differential mode. Transmissions are not frequent and most often consist of a single burst, sometimes two (maybe two stations).

Fig. 1
Quoting my friend KarapuZ "Despite the good recording quality and SNR ratio, in my opinion, the transmitter modulator malfunctions in the frequency discriminator. As a result, we have a bitstream with many errors at the output".

Fig. 2
Comments by my friend cryptomaster follow.
The signal structure of the first burst is shown in Fig. 3, the transfer is considered without translating it into a relative form:
1. A meander with a frequency of 150 Hz (300bps);
2. The preamble is 31 bits (300bps) of the form 0101110001101000010010001010101;
3. Information transfer with a speed of 401.3 bps;
The preamble is marked in yellow:
Fig. 3

Other than the frequency discriminator, the signal is distorted by the imposition of a stray frequency of 800 Hz, the intensity increases by the end of the transmission (Fig. 4), perhaps this frequency (800 Hz) is somehow connected with the formation of the separation of the frequencies of manipulation.

Fig. 4
On a bitmap, it looks like the pattern in Fig. 5:

Fig. 5


19 November 2019

Indian Navy STANAG-4285 naval broadcasts (tentative)

Follwing a tip from my friend KarapuZ and his recent tweet, I started to monitor 16941.0 KHz to study the STANAG-4285 naval broadcasts from the Indian Navy [1]. They use the quite rare 2400bps/Long sub-mode and decoding produces a lot of errors just due to the high data rate and the huge QSB that sometimes affects the signals. By the way, I used the KiwiSDRs VU Hams located in Kottarakkara Kerala and colombo4s7vk located in Colombo Sri Lanka, the latter is a bit less recommendable.

Fig. 1 - one of the S4285 2400/L heard broadcasts
For what I could see, daily broadcasts starting around 1100 or 1200 Z are transmitted on that frequency. Broadcasts consist of clear-text weather bulletins and 4FG messages to VWGZ (VWGZ is the collective callsign for any/all the Indian Navy ships): indeed, they typically use a four FIG (off-line) encryption system. Either the bulletins and 4FG messages, are sent using the async ITA2 8N1 framing (Figs. 2, 3). 

Fig. 2- 8N1 bitstream after decoding
Fig. 3 - off-line decoding using Harris RF-5710A modem
It is interesting to take a look at some bulletin/message typical contents.

VND 677/16
-P- 160732
GR 158
6469 5315 6155 6433 5098 8353 7507 5237 5375 4271

8394 6708 1257 6554 6238 5987 3600 6023 9076 1083
4574 3021 1116 0342 6063 4300 2248 0008ALFA

GR 158




collective callsign for any/all Indian Navy ships

VND 677/16 
indicates the daily serial number of the message in that broadcast, i.e. message #677 of day 16 (indeed 16 november, date of my reception). Don't know what VND stands for.

most likely the daily encrypted callsigns for specific ships

precedence indicator of the message
-R- Routine
-P- Priority
-O- Immediate (Operational Immediate)
-Z- Flash

date time of origination, no time zone indicator (!)

GR 158
the number of 4FG in the message (158 in this case)

separation (break), as the usual Morse Code abbreviation 

The 4FG block is always preceeded by a 9 chars string, i.e.: 


I noted that this string is used to "signal" the last two 4FG in the block, respectively the last and the second-to-last:
2299 4827 3953 0701 6748 2577 4084 8109 5655 4999
5904 4854 4358 8628 9964 9687 9032 0282 4140 7567
5029 5582 1302 9724 1992ALFA
6469 5315 6155 6433 5098 8353 7507 5237 5375 4271
8394 6708 1257 6554 6238 5987 3600 6023 9076 1083
4574 3021 1116 0342 6063 4300 2248 0008ALFA
0822 9678 3021 3357 0524 0160 9645 0013 4927 1959
5457 3192 3301 5013 5856 9799 0272 2857 8727 9046
1854 5256 7000 0659 0399ALFA

The 4FG blocks usually end with the separation char (BT) folowed by the repetition of the number of encrypted groups in the message (GR nnn), the usual RTTY end-of-message (NNNN) and the strings: 



at present I do not know their scope/meaning, maybe test chars, but it makes some sense if they are read respectively as couples [0;1][M;V]:

FIN (=finish ?)

and [A;J][1;0]:


It's worth noting that  in each transmission the most recent message is sent as first (a kind of LIFO). Moreover, some of the messages that were sent in the previous broadcast are re-inserted in the current one, i.e. the broadcast of 1304 Z contains the last message (#679) and the twos (#678 and #677) sent in the previous broadcast of 1255 Z

[2019-11-16 1152Z]
VND 677/16
VND 676/16
VND 675/16
VND 674/16

[2019-11-16 1255Z]
VND 678/16
VND 677/16
VND 676/16

[2019-11-16 1304Z]
VND 679/16
VND 678/16
VND 677/16

Probably this method is used to improve the reliability of the system but it is not clear to me how the number of messages to be repeated is determined (precedence? duration?).
Sometimes it's possible to see short messages as:

VND 675/16
ZBQ 0805

VTH is listed as the callsign of Indian Navy Mumbai.
Note the Z codes ZFA (Following message has been received) and ZBQ (Message was received at).

Weather bulletins report Weather, Surface Wind, Visibility, Sea State, Swell, and Warnings for specific areas and period of validity (12 hours). The bulletins header indicates the originator of the message just after the precedence indicator: 

-P-  150320

-R-  141004Z

-P-  160900


FOCINC EAST: Flag Officer Commanding-in-Chief Eastern Naval Command. The Indian Navy operates three operational Commands, each headed by a Flag Officer Commanding-in-Chief (FOCINC): FOCINC East (Visakhapatnam HQ), FOCINC West (Mumbai HQ), FOCINC South (Kochi HQ).

NAVAREA VIII CO-ORDINATOR: the Chief Hydrographer to the Government of India.

CINCAN: Commander-in-Chief of the Andaman & Nicobar Command. The Andaman and Nicobar Command is the first and only Tri-service (army, navy, air force) theater command of the Indian Armed Forces.

Since some of the weather bulletins also report detailed "LOCAL WEATHER FORECAST FOR VISAKHAPATNAM", probably the broadcasts are transmitted from a COMCEN belonging to the Eastern Naval Command (ENC) HQ in Visakhapatnam [2]. In this respect it's noted that some logs in old WUN/UTNL newletters report "VTP Visakhapatnam" as Indian Navy station operating in CW and RTTY 50Bd/850, but not on 16941 KHz. Actually, I didn't find any "official" allocation for 16941.0 KHz but only a clue related to one of the frequecies that are used for HF communications in the Indian activities in Antarctica (IAP, Indian Antarctic Programme) [3].
Given the period of validity (12 hours, except for the forecast for Visakhapatnam which have 24 hours validity) it makes sense to expect similar broadcasts around 0000Z, likely on a lower HF band.
(to be continued)

[1] https://en.wikipedia.org/wiki/Indian_Navy
[2] https://www.indiannavy.nic.in/node/1399#
[3] inpre07e.doc 

4 November 2019

Baudot FSK 100Bd/500 (unid Rus Gov/Mil)

Interesting async ITA2 5N1.5 FSK 100Bd/500 tuned on 11019.0 Khz some days ago. Once demodulated, the content consists of (off-line) encrypted 5LGs groups. Note also the slight deviation of the speed.

The transmission ends with the FSK-MORSE op-chat "CFM QRQ 100 QBN K": almost surely Russian Gov/Mil users.

Same 5LGs format and 5N1.5 framing was found in the reception reported in this post, with the difference that the latter has a speed of 50 Baud.

17 October 2019

async FLSU call followed by STANAG-4197 (3G-HF "circuit mode")

This transmission was logged and recorded by my friend DK8OK Nils on 11228.0 KHz/USB, and refers to op-comms between  "INY" Trapani-Birgi airport and "DHN66" Neuteveren/Geilenkirchen NATO air base (INY provides technical-operational and logistical support to the AWACS of the E-3A Component, based in Geilenkirchen). Nils kindly sent me the file for its analysis.
The sample is an example of a STANAG-4538 3G-HF FLSU (Fast Link Setup) asynchronous call followed by traffic in "circuit mode" (data continuous, not packed); short voice comm is in the middle. Although synchronous calls are the preferred mode in 3G networks, async calls might be used if the called (or the caller) station may not have achieved net synchronisation. 
The BW5 burst waveform used by FLSU is recognizable in the initial PSK-8 segment from its duration and from the conveyed tribit symbols (2432), as it results from the cross correlation function and the demodulated stream (Fig. 1).

Fig. 1 - CCF/ACF and demodulated stream
According to Annex C to STANAG-4538, the async call of FLSU protocol begins with the LBT (listen before transmit) for at least one dwell period, followed by the transmission of 1.35N (nearest integer value) Async Request PDUs on the requested link frequency, where N is the number of channels in the scan list, and 1.35 is the duration of each dwell period in seconds. The async call procedure ends with a single LFSU Request PDU (Fig. 2).

Fig. 2 - async FLSU PDUs
Looking at the 50-bit payloads in Fig. 2, type 3 (011) PDUs are sent 10 times and are followed by a single type 0 (000) PDU: since PDUs type 3 indicate the Async_FLSU_Req PDU, and type 0 indicates the FLSU_Request PDU, the sample exactly matches the async call procedure as above. By the way, it's worth noting that since up to 10 Async_FLSU_Request PDUs are used, 7 are the allocated channels for this network.

001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 000 111111 010010 01001101

The STANAG-4197 waveform following the call is most likely used in a ANDVT modem in order to achieve secured voice transmission.  
Notice the apparent lack of the fourth doppler tone at 2812.5 KHz: indeed, it's seems just barely visible in the bottom sonagram of Fig.3: probably a defect/malfunction of the HF modem. 

Fig. 3 - STANAG-4197 segment

4 October 2019

NILE/Link-22 168-bit packets (STANAG-4539 TDMA WF2 waveform)

For background it might be helpful to read the posts:
TDMA waveforms, Annex D to STANAG4539 
NILE/Link-22 traffic waveform #2 

In the sample being analyzed, the 270 symbols of the Media Code Frames are transmitted at the modulation rate of 2400 baud and follow the QPSK waveform #2 structure that consists of 8 sections with 18 symbols DATA blocks and 15/16 symbols Mini Probes (MP). 

Fig. 1
Table 1 - Modulation Type and Contents for WF2 (Annex D to STANAG-4539 Edition 1)
The number of Media Code Frames to be transmitted per TDMA slot (i.e. a burst) is specified to the modem by the Link-22 System Network Controller (SNC) based on the Data Link Processor (DLP) supplied parameters and hence the size of the number of network packets that shall be used to accomodate the incoming messages.
In this sample each slot is composed of 9 frames each consisting of 168 bits, as specified in Annex D to S4539 (WF2, RS(36,21) in Table 2) and in a Link-22 publication [1] about the minimun size of a network packet (Table 3). Both the Tables refer to HF Fixed Frequency operations (HF FF).

Table 2 - Waveform Summary (Annex D to STANAG-4539 Edition 1)
Table 3 - Link-22 transmission media types (Understanding voice and data link networking [1])
My friend YING coded a sofware to demodulate and decode Link-22 WF2 samples, he kindly sent me a decoded bitstream and gave me some interesting insights: "I also found that (1) most of waveforms meet the RS(36,21), and seems only a little meets the RS(36,30). (2) all the RS decode bits have the byte 0x0B, which is strange" YING says. Indeed, the bitstream has a very interesting pattern (Fig. 2):

Fig. 2- Link-22 decoded stream (168 bits window)
Even more interesting is the hex representation of a single TDMA slot (9 frames) which exhibits features that are not immediately visible at glance in the bitwise representation:

48-bit fields A and A' has the same contents

4-bit fields marked with "*" differ by 0x8
4-bit fields B and B' has the same contents
4-bit fields C and C' has the same contents

- fixed position of the byte 0x0B (as noted by YING)

         A          B             C          A'         B'   C'
 ----------------- *-             -  ----------------- *-    -
 29 FB 1F A9 44 20 A9 C4 9F 96 C4 1F 29 FB 1F A9 44 20 29 0B 1E
 5F CA E1 95 32 11 57 F8 E9 A7 3A 23 5F CA E1 95 32 11 D7 0B 22
 DB A6 9E 99 B6 7D 28 F4 6D CB 45 2F DB A6 9E 99 B6 7D A8 0B 2E
 8C F5 65 E3 E1 2E D3 8E 3A 98 BE 55 8C F5 65 E3 E1 2E 53 0B 54
 22 D4 3F A6 4F 0F 89 CB 94 B9 E4 10 22 D4 3F A6 4F 0F 09 0B 10
 3E CB AC CD 53 10 1A A0 88 A6 77 7B 3E CB AC CD 53 10 9A 0B 7A
 7A A0 B0 DD 17 7B 06 B0 CC CD 6B 6B 7A A0 B0 DD 17 7B 86 0B 6A
 FE F5 04 CE 93 2E B2 A3 48 98 DF 78 FE F5 04 CE 93 2E 32 0B 78
 3C B6 D0 A7 51 6D 66 CA 8A DB 0B 11 3C B6 D0 A7 51 6D E6 0B 10

(each 168-bit row is a 112.5ms Media Code Frame)

Quoting STANAG-5522 TACTICAL MESSAGE CONSTRUCTION: "Link-22 tactical messages are functionally oriented, variable length strings of an integer number of up to eight 72-bit words (Tactical Message Words).  These 72 bits words are formatted into network packets by the System Network Controller.  Parity bits for Forward Error Correction are applied at the Network Packet level". This means that what we see are network packets and not solely Link-22 messages.
If it's easy to verify that the number of Media Code Frames carried by a burst is 9, it is however difficult to establish the number of 72-bit words and hence the possible format of the message (from 72 up to 576 bits long). Help in this direction comes from the hex stream. Link-22 traffic is usually encrypted by KIV-21/LLC, a stand-alone in-line network crypto device: the stream, however, does not seem encrypted. Looking at the Link-22 Functional Diagram in Fig. 3, the NETSEC FUNCTION block provides akso an unencrypted interface for the transfer of control and status information (C&S):

Fig. 3 - Link-22 Functional Diagram (STANAG-5522 Edition 1)
Thus, an easy conclusion could be that each 112.5ms frame transports two unencrypted Link-22 words (144 bits) plus 24 bits low-level overhead (Error Detection And Correction (EDAC) bits, flags, spare, etc.?). Table 4 confirms my guess:

Table 4 - Waveforms, RS code rate, and Link-22 words
("Technical handbook for radio monitoring HF", Roland Proesch)
Table 5 is the result of a my comparison between Tables 2 and 4: it turns out that a fixed length of 24 bits is always appended. Curiously, this length is 1/3 (24 bits) of the length of a Link-22 word (unfortunately Table 5 is limited to the waveforms WF1-3 since the new annexes to STANAG-4539 are not at my disposal).

Just as a test I tried a quite raw suddivision in which the fields that have the same values occupy the same positions within two Link-22 words:

 71                      00           71                       00
 --------------------------            --------------------------   
 29 FB 1F A9 44 20 A9 C4 9F  96 C4 1F  29 FB 1F A9 44 20 29 0B 1E
 5F CA E1 95 32 11 57 F8 E9  A7 3A 23  5F CA E1 95 32 11 D7 0B 22
 DB A6 9E 99 B6 7D 28 F4 6D  CB 45 2F  DB A6 9E 99 B6 7D A8 0B 2E
 8C F5 65 E3 E1 2E D3 8E 3A  98 BE 55  8C F5 65 E3 E1 2E 53 0B 54
 22 D4 3F A6 4F 0F 89 CB 94  B9 E4 10  22 D4 3F A6 4F 0F 09 0B 10
 3E CB AC CD 53 10 1A A0 88  A6 77 7B  3E CB AC CD 53 10 9A 0B 7A
 7A A0 B0 DD 17 7B 06 B0 CC  CD 6B 6B  7A A0 B0 DD 17 7B 86 0B 6A
 FE F5 04 CE 93 2E B2 A3 48  98 DF 78  FE F5 04 CE 93 2E 32 0B 78
 3C B6 D0 A7 51 6D 66 CA 8A  DB 0B 11  3C B6 D0 A7 51 6D E6 0B 10

However, the byte-oriented view is misleading and actually makes a poor sense since the words and overheads are structured in bits rather than in bytes. (1)
Moreover, it should be noted that we do not have to deal with clean and reassembled packets but just with decoded on-air symbols. I mean that Link-22 network packets may undergo a fragmentation and probably that is what we are facing: indeed, the autocorrelation of the bitstream exhibits a strong value of 96 bits i.e. just one 72-bit word plus 24-bit overhead (Fig. 4). 

Fig. 4 - TDMA slot autocorrelation
Based on the above, we think that the analyzed sample consists of unencrypted Link-22 F-series C&S messages, although it could also be 70-bit Link-16 messages which are encapsulated in Link-22 structure. At least for waveforms WF1-3, the network controller always adds 24 bits overheads to the incoming Link-22 messages: we need more time to study this block and find the CRC sequence (if any).

24-bit overheads update (October, 4)
The packets after WF2 RS(36,21) decoding consist of 144 bits which are needed to convey two words, plus 24 bits of overhead. Referring to Figure 3, these packets are somewhere inside the Signal Processing Controller block which performs modulation and demodulation, as well as error detection and correction (EDAC). Well, I think the 24 bits overhead partly consist of CRC bits (I do not think a CRC-24 is used).
As STANAG-5522 seems to suggest, Link-22 applies the CRC to the whole of words of each packet (i.e. not to each word). Although actually I do not know neither the length of the CRC neither its positioning inside a packet, most likely Link-22 uses a CRC-16 parity check. The remaining 8 bits could be used to accomodate the needed bits for the packet header and maybe one or more additional spare bits so to match the numbers of the k-bytes used for Reed Solomon encodings.
Indeed, as you can see in table 5, the value of k in RS(n,k) codings is 3 bytes longer than the room needed to convey the words. According to the waveform being used, SPC will package words, header, and CRC bits into a packet of the appropriate number of bits for modulation and transmission. 
(to be continued)

The data fields used are of 3 types: binary, logical, and numeric. Binary data fields are one bit fields containing a 0 or 1. The meaning of the value of each field is described in the applicable message definition. Logical data fields are multibit fields whose bit configurations represent logical values as described in the applicable message definition. Numeric data fields are multibit fields whose bit configurations represent actual numeric values. Spare fields are included in some messages. When transmitted, these spare fields will be encoded as zero and shall not be processed upon receipt.