3 August 2022

unid 150-300Bd/509 FSK


Since some days me and my friend Cryptomaster are discussing an FSK signal detected on 6511.50 Khz (CF). Transmissions starts (and ends) with a long reversals sending at 150 baud speed, messages are repeated and are sent at 300 baud; since the measurement of the shift varies slightly from 507 Hz in traffic mode to 513 Hz in idle (figure 1) we decided to fix it in 509 Hz.

Fig. 1 - FSK main parameters

The bitstream shows a 24-bit lenght period, one of which is the phasing bit (the last column of "0s"); data are preceeded by a 240-bit sequence generated by the polynomial x^12+x^10+x^9+x^3+1.

Fig. 2 - the resulting bitstream after demodulation

Again, the question arises of whether or not to use Differential FSK mode: infact, as already cited in some previous posts [1][2], as result of the differential decoding, we get a uniform parity check, except for the first combination of bits (figure 3). We think that the differential mode probably does not apply, and that's a kind of "trick". 

Fig. 3 - parity checked stream obtained after differential decoding

Speaking with some of his friends, Cryptomaster was able to use their particular program capable of detecting the presence of any CRC sequences in bitstreams: as a result, after inverting the 9th column of the stream, a clear H(24,16) coding was found, ie 16-bit data followed by 8-bit CRC. We then found and verified the relative (8,24) check matrix

1 0 1 1 0 0 1 0 1 1 1 1 1 0 0 0   1 0 0 0 0 0 0 0
0 1 0 1 1 0 0 1 0 1 1 1 1 1 0 0   0 1 0 0 0 0 0 0
0 0 1 0 1 1 0 0 1 0 1 1 1 1 1 0   0 0 1 0 0 0 0 0
0 0 0 1 0 1 1 0 0 1 0 1 1 1 1 1   0 0 0 1 0 0 0 0
0 0 1 1 1 0 0 1 1 1 0 1 0 1 1 1   0 0 0 0 1 0 0 0
1 0 1 0 1 1 1 0 0 0 0 1 0 0 1 1   0 0 0 0 0 1 0 0
0 1 1 0 0 1 0 1 1 1 1 1 0 0 0 1   0 0 0 0 0 0 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 1

Fig. 4 - bitstream (left) and CRC (right) computed using the (16,8) check sub-matrix: the two CRC sections coincide

The program that generated the matrix, during the flow check, "fixed the error" in the 9th column of the bitstream, the correction consists of the reversal of the ninth column, perhaps this is done during signal formation. Something similar has been observed in some CIS signals and in Finnish NOKIA. We also found that the check matrix is generated with the polynomial x^7+x^3+x^2+x+1 (figure 5).

Fig. 5

The message data is therefore made up of 202 bytes, organized in a 16 x 101 bit matrix; statistical analysis does not seem to indicate the use of cryptography (figure 6)

Fig. 6


For the sake of completeness, I add that in the first instance we tried to de-interlace the stream thinking that it was previously undergoing a block interleaver: then we get a stream arranged as a (24,101) bit matrix. As a result, a (101,84) check matrix was obtained which really encodes the information. But we were puzzled by the fact that only 101-84 = 17 bits of information remain in each codeword (51 bytes of data transferred) with a Hamming distance of 48: quite irrealistic in our opinion.

Fig. 7

3rd August update

The signal reappeared, but with less amplitude, on the frequency of 8084.0 KHz (cf). Attempts at Direction Finding (TDoA algorithm) indicate the Kaliningrad oblast as a possible site of the Tx, see figure 8. Further confirmations are however necessary.

KiwiSDR receivers used for monitoring: (Smøla, Norway)
http://julussdalen.proxy.kiwisdr.com:8073 (Julussdalen, Elverum-Norway)

Fig. 8 - TDoA results (tentative)


[1] https://i56578-swl.blogspot.com/2021/12/chinese-psk2-2400bd-serial-waveform.html
[2] https://i56578-swl.blogspot.com/2022/06/akula-almost-always-holds-surprises.html

29 July 2022

Notes on Russian-Ukrainian Datalink (by Nicola)

I received from my friend Nicola, and gladly publish it, his work on Russian-Ukrainian Datalink.

When reading these notes, one should be aware that they have been pieced together from numerous sources and then consolidated. Carefully controlled machine translation from Russian and Ukrainian has been used. It should also be taken into consideration that the workings of the protocols and the nature of the application data they transport as well as the composition of the automated, military systems they serve may not have been fully understood. Markings in yellow indicate that translation is not available or that the given translation is tentative or poorly understood. Russian and Ukrainian designations have mostly been transliterated into Latin characters.Summing up: this is a work in progress. 

1. Introduction and history

Russian-UkrainianDatalink (RUSUKRDL) is a fictive designationwhich for the sake of simplicity is used in these notes to designate a collection of data link and application layer protocols used in air defense, fire controland automated battle field data networks of the armed forces of the Russian Federation,Ukraine and probably also of other former Soviet republics.

The description below will concentrate on the Akkord family of protocols. Akkord seems to be a fairly old family of data transmission protocols.In 1953, the Scientific Research Institute of Electrical Devices (NII ETU) separated from the Krasnaya Zarya plant, the main activity of which was the creation of technical means of data transmission and photo-telegraph equipment. The customers were the Air Defense Forces, the Navy, and the Space Forces. The data transmission protocols and equipment created by the Research Institute of ETU, "Araks", "Aragva", "Pogoda", "Akkord-SS-PD", "Akkord-SS-PS" and a number of others are still in operation in the ministry of defense of the Russian Federation.

The operation of early Akkordprotocols are described in detail in a textbook from 1975. Akkord-50 was one of the first protocols and used ITA-2 with blocks of 12x5 data bits + 2 repetition flag bits + 13 checksum bits in fixed data block mode transmitting at 50 or 100 Baud.



Exchange of traffic works like this: Sending station (PD) sends signal “start of data” (SSSS) and the receiving station acknowledges with ‘I’. Then the sending station sends ‘I’ and data block 1 with the two flag bits set to ‘00’. If the sending station does not receive a receipt (‘I’) within 1.5 s after having transmitted a data block, it retransmits the unacknowledged block, now with the flag bits sets to ‘01’.

Akkord-1200 is a protocol designed to be used for data transmission at 600 or 1200 Baud. 


In the figure above, the upper diagram shows the structure of a block at 600 Baud, while the lower diagram shows the structure of a 1200 Baud block. The former has 4 block number bits + 112 data bits + 16 check bits (= 132 bits), while the latter utilizes 4 + 240 + 16 bits (= 260 bits). The generator polynomial is x16+x12+x5+1, CCITT-16, the same as used in laterAkkordprotocols described below. It should be obvious from the above illustration, that the structure of Akkord-1200 is very similar to Akkord-SS-PD.

A special phasing block initiates the transmission of data: 

The block consists of 4 flag bits + 60 bits with an optimal number of bit transitions + 16 bits of a special phasing sequence, totaling 80 bits.


As is obvious from the illustration above, Akkord-1200 transmits a data block adding an ‘A’ to the first block, which is acknowledged by the receiving station. Block B(2) arrives in error, and a request for retransmission is issued. Block C (3) is transmitted. When the sending station receives the request, it retransmits blocks B and C.[1]

2. Protocol stack

The protocols discussed in this document are datalink layer protocols and the data they transport. The physical level network, transport and application layers is consequently not part of this discussion, but most of the intercepted radio links have been characterized by a telegraph speed of 1200 bps FSK with a shift of 800 Hz in the frequency range 5-7 MHz, which suggests short to medium range distances. Sources also mention the use of PSK, both absolute and differential.








2.1 Datalink layer protocols


Protocol name

Block length [(n, k] bits]


Used with


Akkord-SS-PD (“Akkord-165”)

(165, 144), (117, 96), (69, 48)

1200, 2400, 4800, 9600 bps

AI-010, 55Ts6, R-050



(69, 48)

2400 bps




(117, 96), (69, 48)[1]





(126, 110)

1200 bps







Details unknown





Details unknown



50 Baud

KSA 5D72, 88E8



(20, 15)



ITA-2 (MTK-2)


(32, 28)



2 channels


15 … 26 characters



ITA-2 without check bits





Details unknown


(40, 36)

234, 468



 2.1.2 Akkord-SS-PD

This protocol appears to be the main protocol used. The packet structure of this protocol is as follows:


The 4 m-bits are so called service bits which are used to signal various modes of operation at link level. The C-bit – also a service bit - indicates the address mode used, and the CRC is the cyclic redundancy check protecting the preceding bits. The protocol is transparent and may transport various types of information. m-bits

These bits indicate the various operation modes of the protocol.


Service bits

Service bit values

Type of packet




1st Bit

2nd Bit

3rd Bit

4th Bit



















Note - "X" is the arbitrary value of this bit (0 or 1)

[1] In Russian „Circular“

[2] In Russian ”Silence”

m1 = Flag for erasure mode operation (in Russian DRS, see below)

m2= Flag for feedback (ARQ) operation (in Russian DRO, see below)

Only for duplex operation:

m3 = Receipt for received data block

m4 = Communication channel status indicator





Observed with (165, 144)and (117, 96) payload packets


Observed with (69, 48) payload packets


Observed with (117, 96) scrambled idle (‘silence’) packets, and (69, 48)scrambled packets[1]


Bit sync packets

Other sources indicate this for Akkord-165:



Codagram types





Phasing combination (F1 or F2)[1]



Idle combination (х – arbitrary value)



Information block, where the value of zzz determine the retransmission delay code

m - service digits  
C - decisive feedback flag Data bits

Data transmission is carried out in blocks of 48, 96 or 144 data bits structured in a number of – 2, 4, or 6 - 24-bit data words. The data field contains the data payload. C-bit

The C-bit indicates whether the data block isunaddressed (‘0’) or addressed (‘1’) to a single recipient or is a broadcast. The address range is 1 to 15. Checksum

The m-bits, the data bits and the c-bit are protected by a 16-bit cyclic redundancy check with a generator polynomial G(x) = x16+x12+x5+1, which is the standard CCITT CRC-16. This will detect six errors and correct three. Protocol operation

The protocol is able to operate in three connection modes: Simplex, full duplex and half duplex. In duplex two sub-modes are available: Data erasure mode, where packets received in error are dropped, and feedback mode, where packets received in error are requested to be retransmitted by the opposite party by transmitting block repetition requests(RQ). If ‘erasure mode’ is disabled, packets in error are forwarded to the recipient (DTE) accompanied with an error indication to warn the end consumer. In simplex and half-duplex modes only erasure operation is available.


Format: Full Akkord format

Initial sync: 2 x block length reversals + sync seq (normal)

Cyclic sync: Each 21th block is sync seq (normal)

No traffic: Idle sequence



Format: Full Akkord format

Initial sync: 2 x block length reversals + sync seq (normal)

Cyclic sync: Each 96th block is sync seq (normal)

No traffic: Idle sequence


Format: All bits except the 16-bit CRC are used for data.

Initial sync: 2x block length reversals + sync seq (normal) + sync seq (inverted)

Cyclic sync: Each 96th and 97th block is sync seq (normal) + sync seq (inverted)

No traffic: Idle sequence

OK ODK-2-1

Like ODK 2, but connection is closed down, when no traffic is received from the DTE.

HALF DUPLEX (HDX) (Alternate Duplex mode)


Format: Full Akkord format

Initial sync: 2 x block length reversals + sync seq (normal)

Cyclic sync: Each 21th block is sync seq (normal)

No traffic: Connection closed down

Other sources use the terms Simplex-1, Duplex-1, Duplex-2 and Duplex-3:


Sync seq every 95th block.


Resync is only initiated if a certain number of Block Repeat Requests[1] is received. Resync is attempted until sync is achieved, i.e. when the exchange of sync seqs with F1 and F2 flags takes place. This happens when the opposite party responds with F2 when sync seqs with F1 are received[2].


Sync every 20th block. After initial sync synchronization is only resumed if a Phase Request[1] signal is received from the opposite party. If sync is not achieved after 96 blocks, then sync seqs are sent every 20th block. Synchronization

A special 69-bit synchronization sequence is generated by the polynomial F(x) = x8+x6+x5+x4+1. The start byte of the sequence is 01010000 (0x50) and the final byte is 00000011 (0x03).This 69-bit sync sequence is extended for other block formats so as to cover an entire block, i.e. for (117, 69) 48 bits are added,… 0010 0100 1101 1100 1000 0010 1011 0110 1011 1101 1100 0011, and for (165, 144) another 48 bits are added, … 1110 1101 1110 1011 1010 0010 0001 1011 1111 0011 1001 1000.

Initial synchronization is achieved by transmitting a string of bit reversals. A polarity violation signals that the following string of reversal is the last before an initial sync sequence is transmitted. After this sequence has ended and synchronization achieved, data transmission starts. Depending on the transmission mode, sync sequences are inserted in the data stream at regular intervals (see preceding paragraph).

When the initial phasing codeword 0x50 has been found, the phasing analyzer module of the DCE proceeds to search for the ending codeword 0x03. It the proceeds the sync process, and being synchronized is defined as at least 21matches have been found within 29 bits in any interval of the phasing sequence. At least 21 matches of the corresponding bits must have been detected[1]. Idle

The idle packet for the (69, 48) and (165, 144) formats is structured like this:

m = 1101 (4 bits)

data = ‘01’ (reversals) (48 | 144 bits)

c-bit (1 bit)

crc (16 bits)

In the idle state the (117, 96) format seems to transmit packets with their contents set to the bits of a pseudo-random bit stream. Request for repetition

In duplex mode and with feedback mode selected, the transmitting party stores the already transmitted data blocks and waits for acknowledgement from the opposite party. If an acknowledgement is not received within the time of four data blocks, then the stored data block is retransmitted. This procedure continues until acknowledgement is received.

 3. Application protocols

In this document, the term application protocol is used to describe the data transported by the underlying protocol(s).

 It seems that the family of Akkord protocols are used for a number of purposes including transmission of defense radio monitoring data and maybe most importantly in automated air defense systems deploying radar stations and altimeters, computation centers, fire control for surface to air missiles (SAM) and control and command for interceptors.

3.1. (69,48)

3.1.2. Irtysh (T-235-1L)

The transfer of information from a radar station via the AI-011 DCE is made automatically using three types of messages with the following priorities:

1. Coordinates of the radar station and information about its operating modes.

2. Target coordinates and bearings for AShP setters.

3. Target coordinates and signs and a flagfor the radar image acquisition channel (automatic or PAS).


Messages of the first priority are sent three times passing the DNA radar direction relative to North.

Messages of the second priority about bearings for AShP setters issued only through the automatic pickup channel.

Messages of the third priority are target information packages sent as they are created.