a curious 8N1 async 188-110A transmission (MoD RK)

Interesting recording of a Kazakh-Mil transmission sent to me by my friend cryptomaster. The transmission was heard on 10213.0 KHz / USB at 0656 UTC and dates back to March 2021: not as recent but still interesting given the nature of the sent message and the used HF waveform: ie, MIL 188-110.

 

the message
After decoding, the bit stream has a clear 10-bit period due to use of the 8N1 asynchronous frame: eight data bits, no parity, and one stop bit (figure 1)

Fig. 1

Two annotations can be made after removing the start and stop bit columns:

1) The data block is preceded and closed by a repetitive pattern which is part of the binary sequence generated by the polynomial x^9+x^8+x+1, probably for synchronization purposes (figure 2)

Fig. 2

2) The data consists of a compressed file, more precisely of a "zipped" file, as understood by the presence of the characteristic ZIP header 50 4B 03 04 (0x04034b50 stored in little-endian byte order):

Fig. 3

The quality of the signal is quite good and therefore it allows to go back to the source file by saving the 8-bit file with the extension .zip and then proceed to its decompression using the common unzip app. A decoding tool shall also be needed for recovering "scrambled" text into Cyrillic alphabet, google translate will do the rest (basically, it's a sample of the communications status report).

the used HF waveform
As said, the transfer is performed by a 188-110A Serial modem running at 150 bps. One might wonder why a CIS member country uses a NATO/US standard such as MIL-STD 188-110 for domestic communications. Well, some considerations need to be made.
In May 1994, Kazakhstan joined NATO's Partnership for Peace program, which entailed political consultations and joint military operations, and agreed an Individual Partnership Action Plans - IPAP (1) with NATO. Other than take part in NATO's REGEX exercises, since 2006 Kazakhstan has hosted the Steppe Eagle international tactical military exercise annually in cooperation with NATO and regional partner, the exercise was last held in June 2019 (2). Therefore, from what has been said their communications are likely to be based on these standards. And just not waveforms.
I extracted a frame (at time 3:37) from a youtube video, published by the Military Engineering Institute of Radio Electronics and Communications of the Ministry of Defense of the RK [1], where the use of a "Western-made" HF transceiver is clearly visible (figure 4):
 

Fig. 4

Well, I did some image search and found that the used device is the Tadiran HF-6000 produced by the Israeli Elbit System (figure 5):

Fig. 5

Further research confirms Kazakhstan's interest in military radio equipment manufactured by Elbit [2].

A final consideration must be made regarding the way used for the transfer of the message, or at least for this message. In addition to the 8N1 framing, it's to notice the lack of a datalink protocol, ie the message is sent "as is" and not as an attachment to an email message (for example). This "direct" way of transferring files is easier to encounter in less sophisticated waveforms such as FSK.

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

(1) Individual Partnership Action Plans (IPAP) are plans developed between NATO and different countries which outline the objectives and the communication framework for dialogue and cooperation between both parties.

(2) Steppe Eagle exercises have been canceled for political reasons or due to unease on the part of Kazakhstan regarding the United States.Of course, there’s a more obvious reason that the Steppe Eagle exercises have not been held since the summer of 2019: the COVID-19 pandemic.
https://thediplomat.com/2022/02/.../steppe-eagle-exercise-will-no-longer-fly/

[1] https://www.alem-edu.kz/en/university/voenno-inzhenernyj-institut-radioele/
[2] https://en.tengrinews.kz/military/kazakhstan-bought-israeli-technologies-for-producing-7718/

1016-protocol & DatronLINK suite to exchange HF email (R.O.C. Navy)

Yet another interesting catch of an email-over-HF session, this time recorded on 14360.0 KHz/LSB at 1608z [1]. The usual procedure is used: logical link setup by 2G-ALE 188-141A 3-way handshake (SADLW caller node, SJJES called node) followed by half-duplex data transmission by means of 188-110A modem (figure 1). The data transfer mode uses ARQ acknowledgements to achieve reliable data transmission; each 188-110 segment lasts 15 seconds, delay of the correspondent ACK acknowledgements is 1500 ms, round-trip time is about 19.8 seconds. 

Fig. 1

During the link setup procedure, special AMD messages are sometimes used to trigger 188-110A data transfer (FAXDATA CK) or chat (AMDCHAT16), as for example:

[16:29:39][TO][SFHWF][CMD AMD][FAXDATA CK][CMD LQA NO RESPONSE MP=(7) SINAD=(31) BER=(5)][TIS][SEQDI]
[18:54:50][TO][SFDAN][CMD AMD][AMDCHAT16][CMD LQA NO RESPONSE MP=(7) SINAD=(31) BER=(15)][TIS][SWHPY]

However, other type of files are sent w/out those preceeding commands. Other than the ordinary ALE calls and soundings, stations quite frequently exchange AMD  strings: maybe it deals with a type of dictionary-based chat but it's only a my guess (figure 2).

Fig. 2

1. protocol analysis 
The terms defined below are used to refer to specific types of data objects in defining the protocol:

datagram: an ordered sequence of data bytes incoming from an user application such as an email client
data segment: an ordered sequence of data bytes that occur consecutively within a datagram
packet: a data segment with datalink protocol incapsulation, also known as Potocol Data Unit (PDU)
tx_frame: a sequence of packets (PDUs) to be delivered to the HF modem
segment: an HF modem transmission (ie, an on-air tx_frame)

The datalink protocol emerging after 188-110A overhead removal has a characteristic packet length of 127 bytes or 1016 bits (figure 3) and probably that is reason because it is reported as a not-well specified "Period-1016" protocol, sometimes also referred to as "Brazil-1016". However, as evidenced by the analysis' results, it's actually a proprietary datalink protocol developed by Datron as part of the company HF email software application named "DatronLINK" (1).
The data stream consists of two different type of packets; notice the 1:2 ratio existing between the number of packets of first two tx_frames and the 4th (the 3rd is a "special" tx_frame) although they have same symbols rate and same duration: the reason is that while the first two tx_frames are modulated at 300 bps the following ones have a double rate modulation (600 bps) and then allow eight packet positions.

Fig. 3

The analysis of the bitstreams allows to do some "reverse engineering" of the datalink protocol so to understand its format and contents. Let's start with the firts two tx_frames (figure 4)

Fig .4

byte 1: This field has always the value 0x01, perhaps it indicates the Type of the packet (data or ARQ)

byte 2: Src/Dst Address field. The different signal strengths and fade patterns in figure 5 indicate that while the segment 1 is sent by the caller, the segment 2 is sent by the called node, therefore the alternation of the field' contents is due to the switch between the destination and source address. Anyway, I do not know if the field is the "source" address or the "destination" one. Since its length, up to 255 nodes can be addressed, and that number is the "limit" of a such a network.

Fig. 5

 

byte 3: don't know the meaning of this field, I can only see that the four rightmost bits indicated as dtg have the value 1,2,3 respectively in segments 1,2,3 & 4 so it could refert to the number of the datagram coming from the upper layer application. Perhaps the four leftmost bits indentify the type of the data segments, but it's just a speculation.

bytes 4,5: the Sequence Number field is a 16-bit field that refers to the position occupied by the data segment whithin the datagram coming from the upper layer application, the value is expressed in ascending order.

byte 6: the Packet Number (or Packet Index) field is the ordinal position of the packet within the tx_frame, is expressed in descending order such that packet number = 0 indicates that the packet occupies the last position in the tx_frame. I think that by numbering the packets in descending order, the receive node will be aware of how many packets the current tx_frame is made up of.

bytes 7-121: Data Segment field. If the data segment has a length less than 115 bytes (because it includes the last data bytes of the datagram), a sequence of null data bytes (of value zero) is appended to the data segment so as to extend its length to 115.

bytes 122-125: 32-bit Cyclic Redundancy Check (CRC)

byte 126: this field has always the value 0x80, as the first field but in reverse order

byte 127: (seecond) Src/Dst Address field. As said above, this field assumes alternate values in segments 1,2 where traffic flows in two directions. Obviously, if one of the two fields is the source address the other is the destination one (and vice versa).

Fig .6

Given that only 2 packets are to be sent (sequence numbers 0,1) the transmitter fills the (otherwise unused) remaining packet positions with repetitions of packets already residing in the current tx_frame, the receive node will inspect the sequence number of each packet received without errors, and use the sequence numbers to identify and discard duplicate packets. 

Fig. 7

 

Given their double data rate (600 bps), segments 3,4 allow 8 packet positions per tx_frame, with the exception of the 3rd tx_frame which consists of only two packets. However it must be noted that the data rate changes (from 300 bps to 600 bps) just in segment 3, thus it's probable that the transmitter uses a "special" 2-packet tx_frame just to test the feasibility of the new mode. This also implies that the datalink application controls the 188-110 modem.

Contrary to what happens in tx_frames 1,2 the contents of the second field (Src/Dst Address) do not change because these tx_frames are sent by the same node (the caller). The "Sequence Number" and "Packet Number" fields do not need further comments, their functionality is even clearer in tx_frames 3,4.

Fig. 8

As above, the transmitter adds duplicate packets to fill all the packet positions allowed by the tx_frame (ie 8 available position in 600 bps segments). 

 

Fig. 9

 

That said, the format and contents of the datalink protocol should be the following:

 

Fig. 10

 

2. ARQ analysis 
Beyond the "local" reception, I think it's interesting to see how that transmission was actually received at the recipient' sites: that can be done by analyzing the ARQ packets (figure 11) used to transfer acknowledgements bewteen the receiving and the sending node.
ARQ packets have a structure of 45 bytes in length which corresponds to 360 bits or 120 PSK-8 tribit symbols, thus each ARQ packet needs a transmission time of 50 msec when modulated at a symbol rate of 2400 Baud (on-air packet duration is 1700 msec).

Fig. 11

The Format and content of the ARQ packets can be deduced by joining the four demodulated streams and, although I do not know the structure, some fields can still be identified and described:

Type: probably the "protocol field" that identifies this PDU as an ACK PDU

Src/Dst Address: tow fields each consisting of 8-bit address of the sending and receiving node

dtg: indentifies the datagram that is being acknowledged;

Selective Acknowledgements: in the form of an ACK bit-mask that contains one ack bit for each of the packets that can be received in a tx_frame (32 bit = 32 tx_frames sent in a single 188-110 segment at 2400 bps).  Each bit indicates whether the corresponding packet of the "dtg" datagram (ie the corresponding data segment) was received without errors; 1 = ACK (was received successfully); 0 = NAK (not received successfully). Indeed, the number of 1's in the four selective acknowledgements fields match the number of the packets sent in the correspondent four tx_frames (ie: 4,4,2,8).

CRC: 32-bit Cyclic Redundancy Check

Fig. 12

The relationships existing among the fields Src/Dst Address, dtg, and ACK bit-mask are shown in figure below:

 

Fig. 13

3. message analysis

Working on the bitstreams in order to find something that makes sense, I found that data segments must be read in reverse order: that way, ZLIB header 0x78DA (level 9 compression, the best one, as per RFC 1950) and filenames automagically emerge (figure 14).

Fig. 14

The compressed data segments in tx_frames 1,2 consist of the files SADLW59957835.TXS and SJJES122502203.TXS: the filenames contain the ALE callsigns of the nodes involved in the transfer followed by a 8/9 digits number, that number, as well as the extensions ".TXS", is unknown to me. After "inflating" (ie decompressing ZLIB data), the files have the contents F 59678430.MSG\size(?) and C 59678430.MSG\0 

Fig. 15

According with what I saw so far, the first two tx_frames of a data transfer always follow the same paradigm, my guess is that it's a kind of simple negotiation such as "ready to send message_ID" followed by "ready to receive message_ID" so that the receive node is aware about "what" will be sent in the tx_frames that will follow (figure 16).

Fig. 16

The reassembled data segments sent within tx_frames 3,4 - as expected - consist of the ZLIB compressed file 59678430.MSG. Once inflated, headers and body of the message offer interesting insights and information (figure 17). 

Fig. 17

Message-ID header <001001d85407$ffb3b020$0100007f@s0v7n0> reports the host domain/name s0v7n0: this is the host where the being observed message was created

From and To headers "DatronLINK - SADLW" <SADLW@radio.mail> and "DatronLINK - SJJES" <SJJES@radio.mail>  indicates that DatronLINK is the HF email application used: a powerful application developed by Datron and designed to automate message and file transfers over radio links (1), most likely the email domain radio.mail is the default name provided by the application. That domain is clearly not suitable for outbound messaging therefore the gateway function must therefore be provided by the application. 

The References header <1E084D883DFC47E2A5AA8429E352B4D7@RT7000PC1> indicates that the message is a reply to a previous one (or a forwarded one), as also indicated by the presence of the "--- Original Message ---" string. Notice the host domain/name RT7000PC1 that indicates a generic PC1 host which is almost surely wired to a Datron RT-7000 transceiver

The Subject: header =?big5?B?UmU6ILGhuOogwuC1b8SlvtSrSKTl?=  is particularly interesting: according to RFC 2047 MIME the string must be parsed as:  =? <charset> ? <encoding> ? <coded text> ?=
where:
charset = big5,
encoding = B (BASE64),
and coded text = UmU6ILGhuOogwuC1b8SlvtSrSKTl
big5, also indicated in the charset attibute, is a Chinese character encoding method used in Taiwan, Hong Kong, and Macau for traditional Chinese characters (2), BASE64 is a 6-bit encoding (3). Thus I processed the coded text "UmU6ILGhuOogwuC1b8SlvtSrSKTl"  in simple steps using CyberChef tool [3] and google translator (figure 18):

1. convert from Base64 [2]
UmU6ILGhuOogwuC1b8SlvtSrSKTl  → Re: ±¡¸ê ÂàµoÄ¥¾Ô«H¤å
 
2. decode to big5
Re: ±¡¸ê ÂàµoÄ¥¾Ô«H¤å → Re: 情資 轉發艦戰信文
 
3. translate from Chinese to English:
Re: 情資 轉發艦戰信文 → Re: Intelligence forwarding naval warfare letters (as expected!)

Fig. 18

X-Mailer header reveals that users run Windows-based PCs and Microsoft Outlook Express with a build version 6.00.2800.1106 (discontinued, now superseded by Windows Mail)

 

date: and sent: headers Wed, 20 Apr 2022 00:10:33 +0800  and Tuesday, April 19, 2022 11:53 PM say that the message transfer occurred around local midnight, even if sender and receive PC have probably different settings. UTC offset +0800 and character set Big5 are a great help in narrowing down the user detection area

 
subject: header and body of the "Original Message" contain (apparently) incomprehensible ASCII characters which, as specified by the big5 charset, must be encoded in Chinese characters (figure 19):

Fig. 19

As above, the Chinese strings:
 
情資 轉發艦戰信文
收悉請回覆級職姓名及 QSL
FM 532 值機員 電信士官長 李春賢
 
are then translated into English by using  some on-line  tools:

Google:
Intelligence information Forwarding the warship letter
Upon receipt, please reply to the title and QSL
FM 532 Check-in Operator Telecommunications Master Chief Li Chunxian

Yandex:
Intelligence forwarding naval warfare letters
Please reply to the rank name and QSL when you receive it
FM 532 check-in crew Telecommunications Non-commissioned Officer Li Chunxian

Baidu:
intelligence information forwarding ship war letter
Received, please reply the name of the rank and QSL
FM 532 check-in attendant telecommunications Sergeant Li Chunxian

Bing:
Intelligence Forward the ship battle letter
Please reply to the grade name and QSL
FM 532 Check-in Non-Commissioned Officer Li Chunxian

DeepL:
Information Forwarding Letter from Warships
Received, please reply with name and QSL of rank
FM 532 Flight Attendant Telecommunications Chief Petty Officer Lee Chun Yin

The translated texts , although they slightly differ, lead one to think of a "Navy" email traffic (since the term "warship"); FM 532, which appears in the signature of the parent message, could be the Pennant Number of the warship, while Li Chunxian is the name of the sender.

4. users
I did just a bit of OSINT activity aimed at the finding the relationships between the collected information (Datron, RT-7000, time zone, Big5, FM 532, Li Chunxian, ...) and ended up with the Republic of China Navy, also known as Taiwanese Navy, as the source (also confirmed by frequency/5-LTRS callsigns). To support the finding, I have added two documents from the "Taiwan Department of Defense" and "Taiwan Naval Technical School" confirming the use of the Datron RT-7000 systems by Taiwanese Navy. Figures 20 (procurement of RT-7000 data communication system maintenance) and 21 (courses of Taiwan Naval Technical School) exhibit some relevant extracts. In figure 9, one should know that years 111-113 refer to the Taiwanese time reckoning (Minguo calendar) and correspond to 2022-2024 in the  Christian calendar.

Fig. 20

Fig. 21

No particular information about Mr. Li Chunxian except his "role" aboard, as can be deduced from the email signature. Same for the term FM 532 since it could be the "operator code" or, as said, the Pennant Number of a warship: in the latter case it could refer to the Taiwan Navy's "Panshi AOE 532" Fast Combat Support Ship (figure 22), but it's just my speculation!

Fig. 22 - "Panshi AOE 532" Fast Combat Support Ship, Taiwanese Navy

Then I wondered why the nickname "Brazil-1016" was chosen to identify the DatronLINK protocol and found a document which literally states "[...] the acquisition of HF equipment from DATRON World COMMUNICATIONS,INC. it is due to the existence of software owned by this manufacturer that performs management of all existing HF Gateway network in the Brazilian Navy" (figure 23).

Fig. 23

The document comes from the "Brazilian Navy - Navy Internal Control Center, Department of Public Management and Process Monitoring" and it's related to the direct hiring of DATRON World COMMUNICATIONS, INC. for the acquisition of seven HF/SSB - RT 7000 transceiver devices, to meet the needs of patrol ships "Grajau", "Guaiba", "Grauna",  "Goiana", and the tugboat "Triunfo".
So, most likely some UTE listener, not knowing the real name of the application (that is "DatronLINK"), thought of giving the name "Brazil-1016" to that 1016-bit datalink protocol because largely used by the Brazilian Navy. Just as we do when - for example - we call "CIS-60"  the Russian OFDM 60-tone waveform... just because we do not know its real name.
The above document dates back to 2013 but other more recent ones (dated 2018 and 2020) show that the Brazilian Navy could still use the same devices: 

Fig. 24 - MINISTRY OF DEFENSE BRAZILIAN ARMY (2020)

 

Fig. 25 - BRAZILIAN NAVY DIRECTORATE OF NAVY EDUCATION (2018)

5. conclusions
ROC Navy uses Datron devices (RT-7000 transceivers) and software application (DatronLINK suite) for their informal HF email exchange. The military standards 188-110A and 188-141A are used respectively as HF waveform and for 2G link-setup procedure. Email messages are forwarded using a Datron proprietary ARQ datalink protocol based on 127-byte length packets and ZLIB compression, user data bytes are sent in backwards order (byte-back). The assets use 5-letter callsigns, sometimes shortened to 3, all starting with the same letter. The used email application is compatible with Outlook Express and run on Windows-based PCs.

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

(1) DatronLINK (32-bit Windows-based application) can be used with Microsoft Outlook, Outlook Express and other POP/SMTP email clients ad run on appropriate laptop or desktop computers with Datron’s E110A MIL-STD-188-110A/B HF modem and 7000-series radios. DatronLINK fully manages the attached radio sub-system including core radio and ALE functions providing automatic station linking with selection of best channel using MIL-STD-188-141A compatible FED-STD-1045A ALE (7000ALE). The system uses ARQ and FEC protocols to ensure error-free data communications up to 9600 bps with the E110A modem while simultaneously optimizing the data rate to existing HF channel conditions. Datron World Communications was acquired by Titan in September 2001. Titan is now part of the L-3 Communications group of companies. As of 2007, L-3 calls itslef as "L-3 Communications Titan Group". 

 

(2) The People's Republic of China (PRC), which uses Simplified Chinese characters, uses the GB 18030 character set instead. Big5 gets its name from the consortium of five companies in Taiwan that developed it.

(3) BASE64 encoding is represented by six bits (2^6 = 64): during encoding each group of 24 bits (3 bytes) is represented by four 6-bit Base64 digits. During decoding, it is symply set back to eight bits (refer in Table 1 of RFC 2045).

[1] KiwiSDR receiver at OZ1AEF Skanderborg, Denmark
[2] https://www.base64decode.org/
[3] https://gchq.github.io/CyberChef/

Akula: a quite unusual session

Quite unusual session of Rus-Ny "Akula" 500Bd/1000 FSK characterized by the continuous transmission of only the lowest tone before and after the messages (see figure 1), just like some Rus-Ny 50Bd/200 or even FAB broadcasts from PBB Dutch-Ny.

Fig. 1

 Notice in figure 2 the usual structure of the Akula messages:
- reversals
- "sync" group (which never varies and contains 6 code words arranged as 4 x 100101 + 3 x 110001 followed by a separator)
- "preamble" group (7 code words with two different, but varying values arranged as 4 x 1st code word + 3 x 2nd code word)
- data block
- End-Of-Message group + EOT group (which never varies and consists of the five code words 010000 011101 011101 010000 100001)

Fig. 2 - structure of Akula messages

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

 

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