Rus Datalink: a parsing approach

Just a few unpretending notes as a result of web searches regarding the datalink signal, we have currently been monitoring, in particular about the format (69,48), where 48 bits are data, that for example can be heard on 6123.5 kHz, USB during daytime. The information below refers mostly to the AI-011 (АИ-011) device [1]: a DCE (Data Communication Equipment) for mobile systems designed to protect and transmit telecode data (the generic Russian term for radar data) over standard channels of wired, cable, radio relay, tropospheric and HF communication lines. The data transfer rate is 600 or 1200 bits/s FSK. 

Please note that translating from Russian is never easy, I relied on Yandex Translate tool and the acronyms highlighted in orange are just their English translation.

AI-011 (S23) provides operation in duplex, half-duplex and simplex modes. In duplex mode, data blocks are transmitted and received simultaneously also using ARQ. In half-duplex mode the correspondents take turns in transmitting and receiving. In simplex mode the device provides either transmission or reception of data blocks. When exchanging radar information with external subscribers, it ensures the implementation of the exchange protocols:

* AKKORD-SS-PD (АККОРД-СС-ПД) in blocks of length (165, 144) and (69, 48) bits - equipment 55Ts6; in blocks of length (165, 144), (117, 96) and (69, 48) bits - equipment R-050 ;

* IRTYSH (ИРТЫШ) in blocks of length (69, 48) bits - equipment T-235-1L.

When data transmission is carried out in blocks with a length of 69 (or 117) bits, 5 of them are service bits (m, C), 16 (I) are used for error detection and correction and the remaining 48 (96) bits (K) are used for data:

Fig. 1 - 69 (117) bit format

 

If bit C = 1, the four m bits indicate the address of the correspondent in binary code: when receiving a data block, the receiving device compares the address of the data block with its own address and if they do not match, the data block is ignored. In addressed mode up to 16 subscribers may be accommodated on the same communication channel. When working without an address, i.e. when   C = 0, the first and second bit m1, m2 define sub-modes: the first element indicates the DRS sub-mode (FEC mode?), the second the DRO sub-mode (ARQ mode?). The third and fourth service bits m3, m4 are used only in duplex mode: m3 is used to transmit an acknowledgement of a received data block, m4 is used to signal the channel status.

The 53-bit strings (m1,m2,m3,m4 + 48-bit data + C) are fed into the FEC encoder which performs a cyclic division by the polynomial x^16+x^12+x^5+1. The 16-bit remainders (CRC bits) are then appended to the source messages. Because the transmission is synchronous, phasing (synchronization) is carried out with the help of a special pattern which differs in structure from the structure of the payload data messages and consists of a recurring sequence of 69 bits, generated by the polynomial x^8+x^6+x^5+x^4+1. While analyzing the phasing pattern, the error protection decoder circuit will generate an error signal, since the phase combination is formed on the basis of a different polynomial.

The information is transmitted to the communication channel by three types of messages with the following priority:
1. Coordinates of the radar station and information about its operating modes.
2. The coordinates of the targets and bearings on the directors of the ASP.
3. Coordinates and signs of goals (flags related to targets?) and a sign of the ROLE removal channel (automatic or PASS).
Messages of the first priority are issued three times.
I only found the format of the of the third priority message (figure 2), and according to a web source [2] it should be the T-235-1L equipment and thus the IRTYSH (69,48) algorithm... but it could be wrong or misleading.

Fig. 2 - structure of the 3rd priority message (69,48)

In addition to radar information, AI-011 sends information about the position of the radar station, which is derived from the navigation and orientation system or from a topographic map. At the same time, X and Y coordinate values in a rectangular coordinate system are entered with signs, and the value of the height coordinate H, and also the magnitude of the angle of direction (likely referred to the target)..

Well, honestly the information I have does not allow for further progress as:

- we do not know which equipment is used and therefore which protocol is used to transfer the data, i.e. if we have to deal with the AKKORD-SS-PD (most likely yes) or the IRTYSH protocols as both provide the same data format (69,48);
- we do not know the way the three types of messages are signaled (if any) and therefore we do not know which 48-bit structure we are analyzing, i.e.  it may be that the data fields of messages we observe have a different format and consequently a different interpretation than the one shown in figure 2.

 

However, a couple of remarks seem to be in place:

a. The value of the 4 m bits (0101 or 1010) is the same in all messages that have been demodulated, so it's reasonable to assume that the system works w/out address: if so, the right value of bit(s) C should be "0"  and the DRS sub-mode set (unless all messages are addressed to a single subscriber).

 

b. In this regard (the value we must attribute to the bits C) the most relevant point is this allows us to assume the correct polarity of the received bitstreams. Long periods of absence of traffic are characterized  by the sending at regular intervals (about 5.4 sec) of the sequence:

010100001001111111100001011110001101000000010001110001001011100000011

or in opposite polarity:
101011110110000000011110100001110010111111101110001110110100011111100

Fig. 3 - the 69-bit phasing sequence

Well, that sequence is just the one used for phasing (as mentioned above) since, according to the slide #24 [2]: "The phasing sequence is a segment of a recurring 69-bit long sequence formed by the polynomial G(Z)=Z8 + Z6 + Z5 + Z4 + 1 The phasing sequence starts with the codeword 01010000 and ends with the codeword 00000011". Indeed,  testing for this generator polynomialwe get:

01010000  10011111111000010111100011010000000100011100010010111  00000011

Fig. 4

 

Thus, as supposed, the system works in "circuit" mode (bit C = 0). The 69-bit phasing sequence is also inserted within the messages streams (figures 5,6); also note in figure 5 the sequence of "01"s that is used to maintain the sync between messages or in absence of messages to be sent.

 

Fig. 5 - 69-bit phasing sequence and "01"s before messages

 

Fig. 6 - 69-bit phasing in the "scrambled" (69,48) waveform

Checking some bistreams, it turns out that when there is no data to send (idle) the phasing sequence is sent after 94 "idle" frames, or each 95 frames considering the one containing the phasing sequence itself: by the way, some web source just refer to 95 "code sequences" [2].

 

Fig. 7 - 69-bit phasing inserted within the idle frames

Obviously, the phasing sequence is also sent just after the initial reversals in the (117,96) waveform: this argues in favor of the AKKORD-SS-PD protocol since IRTYSH protocol does not provide the (117,96) format. Regarding this format, there is no precise reference to the structure of its fields in the documentation I could find in the web. From the illustrations it can be understood that the service bits are the same as those of the 96-bit format and that therefore the difference is in a double length of the data field "K".

 

The lack of such indications suggests that the 117-bit format sends a double number of data : the pattern sent in the second 48-bit part of the message in the bitstream of figure 8 can support this assumption. By the way, that pattern may be generated by the polynomial x^9+x^8+x+1.

 

Fig. 8 - 69-bit phasing in the "scrambled" (117,96) waveform

 

c. Assuming that the bitstreams are structured according to figure 2 (format of the third priority message), you may notice that the first byte of the messages (fields: a, b, c, d, e) alternately always assumes the same values and that suggests that the same "type" (priority) of message is being transmitted:
 

m      a     b c  d  e T              H                X                      Y

1010 110 0 0 11 1 01100001 00010101 0 11001000000 1 10001111000 0
1010 000 0 1 01 0 01100001 10100000 0 00001100001 0 00100100101 0
1010 110 0 0 01 1 00000101 00010100 0 11101010100 0 10011110011 0
1010 000 0 1 01 0 00000101 00010000 0 00001100011 0 10000000110 0
1010 110 0 0 11 1 01100000 00010100 0 11101011000 0 10011110011 0
1010 000 0 1 01 0 01100000 10100000 0 00001100011 0 10000000101 0

 

Likewise, the values of the T (time of location) field are repeated either individually or in groups:

 

m      a     b c  d  e T              H                X                      Y
1010 110 0 0 11 1 01100001 00010101 0 11001000000 1 10001111000 0
1010 000 0 1 01 0 01100001 10100000 0 00001100001 0 00100100101 0
1010 110 0 0 01 1 00000101 00010100 0 11101010100 0 10011110011 0
1010 000 0 1 01 0 00000101 00010000 0 00001100011 0 10000000110 0
1010 110 0 0 11 1 01100000 00010100 0 11101011000 0 10011110011 0
1010 000 0 1 01 0 01100000 10100000 0 00001100011 0 10000000101 0

Sometimes blank messages are sent, probably to hide the radar's position or other sensitive information from "prying" eyes:

 

 m      a     b c  d  e T              H                X                      Y

1010 000 0 1 01 0 01011100 01010000 0 00001100001 1 00100001100 0
1010 110 0 0 10 1 01010101 00100000 1 10110001111 0 10110011110 0
1010 000 0 1 01 0 01010101 01010000 0 00001100001 1 10000000010 0
1010 000 1 0 01 0 01010011 00000011 0 00000000000 0 00000000000 0
1010 000 1 0 01 0 01010100 00000011 0 00000000000 0 00000000000 0
1010 000 1 0 01 0 01010101 00000011 0 00000000000 0 00000000000 0
1010 000 1 0 01 0 01001101 00000011 0 00000000000 0 00000000000 0
1010 000 1 0 01 0 01011000 00000011 0 00000000000 0 00000000000 0
1010 000 1 0 01 0 01011010 00000011 0 00000000000 0 00000000000 0
1010 000 1 0 01 0 01011100 00000011 0 00000000000 0 00000000000 0
1010 000 1 0 01 0 00000111 00000011 0 00000000000 0 00000000000 0
1010 000 1 0 01 0 00001001 00000011 0 00000000000 0 00000000000 0
1010 000 1 0 01 0 00001100 00000011 0 00000000000 0 00000000000 0
1010 000 1 0 01 0 00010110 00000011 0 00000000000 0 00000000000 0
1010 000 1 0 01 0 00011101 00000011 0 00000000000 0 00000000000 0
1010 000 1 0 01 0 00100000 00000011 0 00000000000 0 00000000000 0
1010 110 0 0 10 1 00100010 00100000 1 10111011010 0 00111111100 0
1010 000 0 1 01 0 00100010 01010000 0 00001000010 0 11100010101 0
1010 110 0 0 10 1 00100010 00100000 1 10111011000 0 00111111010 0
1010 000 0 1 01 0 00100010 01010000 0 00001000010 0 11100010101 0

 

However, it should be noted that 8 bits are definitely too few to represent a significant time marker. Maybe the actual "time" field is formed by the join of two or more fields - or even frames - since at least 5 HEX are required to store the HH:MM:SS value in seconds (0x0 - 0x1517F,  ie the time of day w/out fractions of second). Furthermore, it is not clear whether they refer to UTC time, local time. Moscow time, or some reference (epoch) of the measurement system. Unfortunately there is no reference to this topic in the info I could find. 

The possibility that a "message" is actually formed by joining two frames can be confirmed by the fact that the (69,48) frames are transmitted grouped in even numbers (excluded the interseped "phasing/sync" frames), this would also explain the use of the format (117,96). Furthermore, after removal idle frames, service bits and CRC, the data stream exhibits a strong period of 96-bit length.

Fig. 9 - 96-bit period of data stream

 

It would be noted in figure 9 that most of the data is repeated in regular groups. Without information about the actual meanings and lengths of the message fields and the used endianness, a large field of hypotheses opens up: several solutions can be tried by processing the bitstreams with a spreadsheet to (re)organize, filter, sort and join the data fields [3].

[1] https://vunivere.ru/work3160/page51
[2] https://disk.yandex.com/i/foPNyfiDpCHGPw
[3] https://disk.yandex.com/d/dTCHkBScBu_WMA
[4] https://studizba.com/files/show/doc/209357-4-1.html AKKORD-SS-PD (AKKORD-165)
[5] https://studbooks.net/1194685/bzhd/razrabotka_funktsionalnoy_shemy_peredayuschey_chasti 

1200Bd/800 Russian tactical datalink (2)

 (revised with some fixes)

My friend @pir34 (from UDXF group) and I are monitoring different frequencies which are supposedly changed on a per day/night basis, but not just that. We have noticed that the transmissions take place from at least two different sites (which I prefer not to indicate) and - more importantly - with two different data formats, even if they have the same transmission mode (1200Bd/800), same bit length (69) and same type of contents (radar tracks). In particular, the transmissions that take place on 6123.5 KHz/usb and 6232.5 KHz/usb (figures 2,3):

Fig. 1 - 6232.5 KHz transmission: spectrogram and modulation

Fig. 2 - 6232.5 KHz transmission: 69-bit period stream

According to COMIN Consulting (thanks to @pir34 for the report), this signal is known as "PIRS PEARCE" [1]: I met such signal some years ago, as annoted here in the blog, on about 20 MHz: as you see in figure, the bitstream is very similar although its length is 165 bits:

Fig. 3 - 165-bit frame length datalink

 

An anymous reader commented the post talking about the 165-bit "Akkord SS-PD" frame format, that he expected to see in the bitstream, and about the other more frequent frames of 69 & 117 bit lengths... just as the ones discussed in the previous post.

I did some research on the web about the Akkord format/algorithm but getting very few results: the most interesting referts to 165-bit length frames (called "Akkord-165") of which a description of the framing is also provided [2]:

4-bit (Start Of Message) + 6 x 24-bit words + 1 sep + 16-bit CRC

That described framing corresponds to those used in the formats of 69 and 117 bits reported in the previous post: in those cases the messages shall consist of two and four 24-bit words respectively (ie 48 and 96 bit length messages). The only difference is the polynomial used for the formation of the 16-bit cyclic code (thus, not used as a scrambler polynomial): in the Akkord-165 format it results to be x^16+x^12+x^5+1.

A second interesting source seems to indicate a device operating with two sub-set, each consisting of an "Akkord SS-PD" data transmission equipment plus a "similar" one and also provides the block diagram reported below in figure 4 [3]:

Fig. 4

(the label "C2" in figure 4 stands for the junction circuits between DTE and DCE)

 

That said, we think that the datalink transmission sites use two data formats both sent with the same 1200Bd/800 waveform, although the exchanged data are perfectly "understood" and parsed by the receive nodes. It's not clear if the two formats are provided by the data transmission unit shown in figure 4 .

 

https://disk.yandex.com/d/uECZVVGQjkZlKA 

 

[1] https://www.comintconsulting.com/post/sigint-comint-solutions...

[2] https://motherhouse.ru/en/mortgage/kompleks-sredstv-avtomatizacii-ksa-sbora-obrabotki-i-vydachi/

[3] http://vniira-ovd.com/index.php/en/products/communication/interface-equipment/bapd

1200Bd/800 Russian tactical datalink

Interesting 1200Bd/800 "FSK" (apparently) transmissions spotted and monitored on 7980.0 KHz/usb from monday  feb. 28th until march 2nd when it disappeared. The heard  signal is a Russian "tactical data link" waveform which is used for HF comms in the Russian «БАРНАУЛ-Т» ("Barnaul-T") C2 system [1], a tactical air defense control subsystem set. The main tasks solved by "Barnaul-T" are reconnaissance of air targets, receiving and displaying information about the air situation, target distribution and issuing target designations for hitting air targets: basically, something very similar to NATO Link-11.

Fig. 1 - Russian «БАРНАУЛ-Т» set

Looking at the signal, the measured shift is = 0.67 Br so the used modulation could be GMSK or CPFSK (indeed, trajectories resolve in a circle): the phase plane and harmonics at 3rd power seems to confirm the assumption, although these "semi-modes" are hard to exactly determine (figs 2,3).

Fig. 2

Fig. 3

According to the demodulated bitstreams, two distinct framings are used:
_a) 69-bit length period (ACF = 57.5 ms), recording of 2022-03-01 at 1021 utc (figure 4)
_b) 117-bit length period (ACF = 97.5 ms), recordings of 2022-03-01 at 1757 utc and 2022-03-02 at 1112 utc (figure 5)
Actually the two framings differ only in the length of the data block and consist of:
2 start bits + 48/96 data bits + 1 bit separator + 16 bits for error detection and correction + 2 stop bits
ie, the _b frames allow to room a double space for data.

Fig. 4 - 69-bit length framing (48-bit length data block)

Fig. 5 - 117-bit length framing (96-bit length data block)

I had the chance to record some complete sessions of the _b framing. The preamble preceeding the data block consists of initial reversals followed by a same 112-bit sync sequence (just 96+16) which can be successfully descrambled with the polynomial x^21+x^11+1 (figure 6). The 117-bit data block follows and consists of single messages (approximately every 8 seconds) separated by what I think be pseudo-random traffic.

Fig. 6 - initial 112-bit sync sequence

Other 117-bit framing recordings do not show single inserts/messages within their stream but rather a continuous flow, in my opinion just pseudo-random traffic to keep the channel alive as STANAG-4285 does in the absence of messages to send (figure 7).

Fig. 7 - 117-bit framing "continuous" stream

After removing the 4 start/stop bits and the separator bit from both _a and _b frames, I obtained two codewords of 64-bit and 112-bit length respectively, coded as (64,48) as (112,96). My tests confirm that the rightmost position of the 16 EDAC bits (P15) stores an overall parity-bit (aka "extra parity bit"): that's a good clue in favor of the use of a Hamming-like coding and related parity-check matrix (figure 8).

Fig. 8 - the overall check parity bit in the two data blocks (48 and 96 bits length)

I then analyzed the two data parts (length 48/96 bits) and found that both are scrambled with the polynomial x^13+x^9+x^7+1. After removing the scrambler, the result is a stream consisting of 35/83 bits of zeros followed by 13 bits of data (figure 9): this is interesting because although the two frames have a different lengths, both transport a payload of the same length (13 bits): it could be that the choice of the framing to use depends on the channel conditions, but that's only a guess.

Fig. 9 - results after the removal of the x^13+x^9+x^7+1 scrambler

I cut off the zeros columns e found some other info about the remaining 13-bit payloads:
* the one of the 48-bit descrambled stream (_a framing) has a period of 389 bits
* the one of the 96-bit descrambled stream (_b framing) has - curiously - a parity bit (figure 10)

Fig. 10

Direction Finding results (TDoA algorithm), although they are not exactly coincident, indicate an area in North East Ukraine (figure 11): that makes sense given the current situation in that country and the purposes of the БАРНАУЛ-Т system. As said above, the signal disappeared on March 2nd morning: last signals I heard were short MS-5 (CIS-12/AT-3004D) transmission and a voice call around 1400Z ("Pervyy pervyy ya vtoroy, priyom"). Coincidently, the press service of the Ukrainian Ministry of Defense on March 3rd morning reports that "A unit of the Main Intelligence Directorate of the Ministry of Defense has seized the Russian module of intelligence and control 9C932-1 (Barnaul-T)" [2].

 

Fig. 11 - some direction finding (TDoA algo) results

 https://disk.yandex.com/d/hTc5YhtPUg_1ow

[1] https://vpk.name/library/f/barnaul-t.html
[2] https://suspilne.media/213350-pid-kievom-zahopili-rosijskij-modul-barnaul-t-so-protidiav-ukrainskij-aviacii/

Fig. 11 - some direction finding (TDoA algo) results

Ital-Mil 1200Bd/800 FSK

Short Ital-Mil 1200Bd/800 FSK used before STANAG-4285/HDLC QUEDRE [1]. The bitstream after demodulation exhibits a 232-bit period length and a bit more strutured patterns after differential decoding (figure 1).

Figure 1 - demodulated bitstream before (upper) and after differential decoding

Reshaping the differential decoded stream it's interesting notice the 8-bit framing in figure 2 with one bit always set to "1" (or "0" according the polarity). The same 8-bit framing can be seen in a 46.6 ms window of the SA raster: 46.6ms @1200Bd -> 56 bit -> 7 x 8-bit frames (figure 3). As a guess, the 232-bit period could correspond to a 29-byte protocol data unit carryng almost the same contents.

Figure 2 - 8-bit framing

 

Figure 3 (notice the change of polarity each 8 bit)

https://disk.yandex.com/d/xj5xo3vrZB00Jg

[1] https://i56578-swl.blogspot.com/search/label/QUEDRE

Ital-Mil FSK, FSK 1200Bd/800

FSK-2 1200Bd/800Hz waveform, approximately 1500 Hz bandwidth, used by Italian Military; in this record it's used by Italian Navy HQ (IDR Rome) on 12200.6 KHz/USB as unusual intro before STANAG-4285 1200bps/L transmission, receive peer had the tactical callsign AZWL.

fig. 1 ~1500 Hz bandwidth

fig. 2 - baudrate line

fig. 3 - involution module and shift between carriers

 

The main features of this signal are what seems a polarity change that occurs each 8 bits (fig. 4), as reported by radioscanner.ru and confirmed in this analysis, and, at least in this sample, its quite pronounced 232-bit period shown in figure 5.

fig. 4 - polarity change

fig. 5 - 232-bit period (fisrt part looks like a sort of preamble)

Unid MSK 1200Bd 800Hz

Yesterday (10 June) morning I spotted this weird signal on 20877.0 KHz/USB at 0725 UTC, unfortunatelly some statics due to a thunder storm ruin the reception.
The signal has a 1200 Hz bandwidth and is characterized by a strong tone at ~1400 Hz (1394) and two simmetical tones at +600 and -600 Hz which are transmitted at lower level than the central one. A sort of "marks" are transmitted each 137.5 ms (pic. 1)

pic. 1

FSK bursts are inserted in a seemingly random way, they have a shift of about 800Hz and manipulation speed of 1200Bd: curiously it's the same value of the bandwidth (pic. 2)

pic. 2

The 137.5ms marks make the period of the signal = 165 bits.

pic. 3