MEROD FSK 100Bd/600 (Indian BSF)

FSK 100Bd/600 signal (thanks to KarapuZ)

A few days ago my friend KarapuZ posted an interesting recording of a 100Bd/600 FSK signal which turned out to be a message structured according to MEROD-IND (Message Entry Read Out Device, Indian variant) message-handling principles, probably the MEROD MA4450 device [1]. MEROD  is the commercial name for the Racal manufactured equipment that uses the RACAL-ARQ mode.

Fig. 1 - main FSK parameters

MEROD-IND provided a simplified framework for organizing message elements such as originator, routing, and date-time group, supporting clarity and orderly handling under operational conditions.
While MEROD-IND is primarily associated with voice procedure mnemonics, its application in this context functioned as a content-structuring aid, with the actual transmission conducted as HF data. From a doctrinal perspective, such a transmission aligns functionally with ACP-125/ACP-131 data communication concepts, though it would normally be described using formal ACP message formats rather than the MEROD-IND designation.
The demodulated bitstream is shown in Figure 2.

Fig. 2 - demodulated bitstream

It's interesting to note that the first two 64-bit sequences are identical except for one bit, perhaps a reception error. This suggests a deliberately repeated sequence:
6D C5 F7 E0 B2 89 88 17
6D C5 F7 E0 F2 89 88 17
A confirmation comes from reading the characteristics of the MEROD MA4450 device [1], literally " [...] preamble of 64 bits used for detection and synchronization. Two sequences can be recognised on receive: one for secure messages and the other for clear messages. Sufficient redundancy is incorporated to achieve 98% probability of recognition of either sequence".

The message sent is in clear text and can be decoded by BEE, so the above 64-bit sequence refers to unencrypted messages.

OK TKS NR
DE NB SIG SRL NO 210004
RRR ZEQ APA
RRR DTO 211600
FROM FTR HQ BSF NB
TO CT WING N DELHI/SDGHE/W)/HZB/IND/TKP/ALL FTR
GR 20 BT
RESTD NO C/7101
FOR COMN. FOR AND FROM ADSO/CCT OPR.
HF COMMERCIAL REPORT UPTO 211600 HRS. FOR INFO PSE // BT
THI
CFN NO C/7101
SD B KR

It's clearly a plain-language military signal, just formatted in classic signal style, administrative/communications report. Indian origin (IND, Delhi, BSF strongly point to this). Indeed, the Border Security Force (BSF) is a central armed police force in India, under the Ministry of Home Affairs. It is responsible for guarding India's borders with Pakistan and Bangladesh. 

Line-by-line decode:

Header / routing
OK TKS NR
DE NB SIG SRL NO 210004
OK TKS – acknowledgment / thanks (common signal shorthand)
NR – Number
DE – “From”
NB SIG – NB Signals unit
SRL NO 210004 – Serial number of the message

Acknowledgments
RRR ZEQ APA
RRR DTO 211600
RRR – “Received, received, received” (strong confirmation)
ZEQ / APA – internal routing or reference codes
DTO 211600 – Date-Time Of message (21st at 1600 hrs)

Sender / recipient
FROM FTR HQ BSF NB
TO CT WING N DELHI/SDGHE/W)/HZB/IND/TKP/ALL FTR
FROM:
Frontier Headquarters, BSF NB
(BSF = Border Security Force)
TO:
Central Wing, New Delhi
SDGHE (signals directorate / HQ element)
HZB / IND / TKP (likely unit or regional designators)
ALL FTR – all frontiers
This is a broadcast-style admin signal.

Body
GR 20 BT
RESTD NO C/7101
GR 20 – Group count (20 word groups)
BT – Break (end of header, start of message)
RESTD – Restricted
NO C/7101 – Reference number

Actual message content
FOR COMN. FOR AND FROM ADSO/CCT OPR.
HF COMMERCIAL REPORT UPTO 211600 HRS.
FOR INFO PSE // BT
Plain English:
For information regarding communications for and from ADSO / CCT operations.
HF commercial report up to 211600 hours.
For information please.

End / authentication
THI
CFN NO C/7101
SD B KR
THI – End of text (Indian signals usage)
CFN – Confirmation
SD – Signed
B KR – Initials of the duty signal officer

So what does it mean? In normal language: “Frontier HQ BSF is informing all formations and central HQ about the status of HF commercial communications up to 1600 hours on the 21st, for operational coordination. This is a restricted administrative signal.”

Below a quite complete abbreviation map about the Indian Signals (CAPF doctrine) (1)

PROCEDURAL SIGNALS (PROSIGs)
OK:
Meaning: Message understood / acknowledged
Type: Informal procedural
Usage: Common in Indian HF nets
TKS
Meaning: Thanks
Type: Informal procedural
RRR
Meaning: Received, Received, Received
Doctrine: ITU / military standard
Usage: Strong confirmation of receipt
BT
Meaning: Break
Doctrine: ITU prosign
Usage: Separates header from text / clauses
DE
Meaning: From
Doctrine: ITU prosign

MESSAGE IDENTIFIERS
NR
Meaning: Number
Usage: Message or signal number
SRL NO
Meaning: Serial Number
Doctrine: Indian Signals standard
GR
Meaning: Group count
Usage: Number of word groups in body

DATE / TIME
DTO
Meaning: Date Time Origin
Doctrine: Military standard (Indian & NATO usage)
Format: DDHHMM (local or Z as context dictates)
HRS
Meaning: Hours
Usage: Indian military style (vs “hrs” in NATO)

SECURITY / CLASSIFICATION
RESTD
Meaning: Restricted
Doctrine: Indian security classification
Levels (India):
Top Secret
Secret
Confidential
Restricted

ORGANIZATIONS / FORMATIONS
BSF
Meaning: Border Security Force
Type: CAPF under MHA
FTR
Meaning: Frontier
Usage: BSF regional command (equivalent to Army Corps-area)
HQ
Meaning: Headquarters
SIG
Meaning: Signals
Context: Signals unit / communications staff
NB
Meaning: Likely North Bengal
Usage: BSF Frontier designation

ADDRESS / ROUTING TERMS
TO
Meaning: Addressee
CT WING
Meaning: Central Wing
Context: BSF / CAPF HQ directorate
DELHI
Meaning: New Delhi (HQ location)
ALL FTR
Meaning: All Frontiers
Usage: Broadcast instruction

OPERATIONS / STAFF FUNCTIONS
COMN
Meaning: Communications
Doctrine: Indian spelling (COMN vs COMM)
OPR
Meaning: Operations
ADSO
Meaning: Assistant Director (Signals / Special Operations)
Context: CAPF / HQ staff appointment
CCT
Meaning: Command & Control Team
(sometimes “Counter-Communication Team” depending on unit)

REFERENCES / FILE NUMBERS
NO C/7101
Meaning: File / reference number
Doctrine: Indian HQ filing style
CFN
Meaning: Confirmation
Usage: Cross-reference to original file number

REPORTING / CONTENT
HF
Meaning: High Frequency
Usage: 3–30 MHz band
HF COMMERCIAL
Meaning: Civil / leased HF services
Context: Backup or contingency comms
REPORT UPTO
Meaning: Status report valid until stated time
FOR INFO PSE
Meaning: For information please
Usage: Indian service English

TERMINATION / AUTHENTICATION
THI
Meaning: This is the end of message
Doctrine: India-specific signal terminator
Equivalent: NATO “AR”
SD
Meaning: Signed
Usage: Precedes sender authentication
B KR
Meaning: Initials / callsign of duty signal officer
Doctrine: Indian Signals authentication practice

UNKNOWN / CONTEXTUAL CODES
ZEQ / APA
Meaning: Internal routing or acknowledgment codes
Usage: Network-specific, not globally standardized
Common in: Indian HF fixed networks
SDGHE / HZB / IND / TKP
Meaning: Likely:
Directorate codes
Geographic or functional routing
Network node identifiers
Status: Internal BSF / Signals net designators

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

[1] https://www.cryptomuseum.com/crypto/racal/ma4450/files/merod_ma4450.pdf

(1) CAPF = Central Armed Police Forces, under India’s Ministry of Home. How India’s military communication systems and Central Armed Police Forces are supposed to operate, communicate, and coordinate according to official principles.

UDP datagrams sent via STANAG-5066 (2)

For background read the previous post

I ended the previous post hoping to recover new transmissions to understand more about the used application-layer protocol, and somehow this happened: my friend Kosmod indeed kindly sent me several transmissions he recorded on 20779.5 KHz/USB. The recordings date back to the end of 2024 (November) and this allowed me to understand how - actually - there has been a sort of evolution/improvement of the application-layer protocol that sits above UDP and which is therefore responsible for the UDP payloads. 

2024 transmissions follow the same schema: initial MS-141A link setup between ALE address 101 (caller) and 102 (called), then MS-110A running at 300bps/L to trasnfer data in async 8N1 mode (Figure 1). 

Fig. 1 - async 8N1 MS-110A

After removing the start/stop bits, the resulting bistreams consist of Data Transfer Protocol Data Units (D_PDUs) of the STANAG-5066 protocol, as parsed by the S-5066 dissector (as for example in Figure 2). The results are as expected, namely:

* D_PDU (Data Transfer Protocol Data Units) type 7, NON-ARQ DATA (Non-ARQ data transfer)
* the last 3 digits of the STANAG-5066 Addresses correspond to the respective MS-141A ALE addresses used during link setup
* IP-type Client/Application, ie IP over HF ("Source and Destination Service Access Point" is 9)

Fig. 2 - analysis of a  STANAG-5066 frames

The same conclusions (ie expected results) can be drawn by examining IP packets with "wireshark" tool (an example is shown in Figure 3):

* source/destination (LAN) IP addresseses are 192.168.101.15 and 192.168.102.15 (note the digits 101 and 102)
* the IP packet transports User Datagram Protocol (UDP) messages which are addressed to the destination port 2753, the "de-spot" port

Practically, just as in the recordings analyzed in the previous post... but there is a very important difference compared to the 2025 recordings: here the length of the UDP payload is 32 bytes instead of 16! (double length).

Fig. 3 - analysis of an IP packet

Below I report the 32-byte payloads related to 10 consecutive transmissions: as you can easily see, these are repeated transmissions, probably due to missed or incorrect receptions:

0020010200035b88c0a8650f0000059f67487bb400010000c0a8660f000002b1

0020010200033eaac0a8650f000005a067487caa00010000c0a8660f000002b4
0020010200033eaac0a8650f000005a067487caa00010000c0a8660f000002b4

00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6

(2025 payload: 00100003060072c6c0a8650f00000cc3)

By isolating unique payloads you get:

0020010200035b88c0a8650f0000059f67487bb400010000c0a8660f000002b1
0020010200033eaac0a8650f000005a067487caa00010000c0a8660f000002b4
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6

Then I tried a parsing of the first payload, results are interesting.

00 20 → 0x0020 = 32 (matches payload length!)
01 02 → likely protocol version or message type
00 03 → subtype / command / channel ID
5b 88 → 0x5B88 = 23432 (this value changes every payload, likely a sequence number, transaction ID, or session counter)
c0 a8 65 0f → 192.168.101.15 (source IP address!)
00 00 05 9f → 1439 (changes per payload: 1439, 1440, 1445)
67 48 7b b4 → 0x67487BB4 = 1732924340 that decodes cleanly as a Unix epoch timestamp! (seconds), other packets: 67487caa, 6748871e
00 01 → flag or command = 1, constant in all payloads
00 00 → Likely reserved or alignment padding
c0 a8 66 0f → 192.168.102.15 (destination IP address!)
00 00 02 b1 → 689 (changes slightly per payload: 689, 692, 694)

Given the fixed 32-byte control packet, embedded source/destination IPs, timestamps, repeated sends with identical content, in my opinion UDP port 2753 is here used as a rendezvous/control/signaling port. Moreover, I thinked of missed or incorrect receptions: this is suggested, other than by repeated transmissions, also by some text-mode op-chats also reported by Kosmod in his comment to the previous post; chats are in Italian language and, according to some UDXF logs, this is  likely a military attaché (1):

"MESSO IN CODA 5 EMAIL.....SPERO CHE TI ARRIVI ALMENO UNA AH AH AH" (I QUEUED 5 EMAILS.....I HOPE YOU GET AT LEAST ONE AH AH AH)
"RICEVUTO QUALCHE EMAIL? DUE SU 15... MI LASCIA PERPLESSO" (RECEIVED ANY EMAILS? TWO OUT OF 15... IT LEAVES ME PERPLEXED)

Well, let's work now on the “timestamp” field, bytes 16–19:

67 48 7b b4
67 48 7c aa
67 48 87 1e

Interpreted as big-endian:

0x67487BB4 Decimal: 1732803508 UTC time: 2024-11-28 14:18:28
0x67487CAA Decimal: 1732803754 UTC time: 2024-11-28 14:22:34
0x6748871E Decimal: 1732806430 UTC time: 2024-11-28 15:07:10 

Since the same timestamp is repeated across multiple transmissions, it doesn't reflect the sending time, but rather the message creation time. It's important to note that the timestamps correspond to the recording dates, except for the time (hours:minutes:seconds):

There is something wrong though, because the timestamp in the payloads CANNOT be later than the time of their reception! Since the Unix timestamp is timezone-agnostic, perhaps they parse dates in local time by default and then convert to timestamps (without making UTC explicit) or treat local datetime as if it were UTC then convert it to a Unix timestamp: this way you’ll get a timestamp that is shifted by your local offset. It would be a bug, but this way the hour differences would make sense. If my guess is correct, the transmitting station's country should be located in the UTC+2 time zone.

For the sake of completeness, I repeat below the analysis of the payloads recorded in December 2025 followed by a little comparison.

00 10 → Possibly a message type or some identifier (2 bytes). Hex 0x0010 = 16 decimal (the length of the message!)
00 03 → Another 2-byte field, could be message type or command. Hex 0x0003 = 3 decimal.
06 00 → Could represent a flags field, version, or sub-type. Hex 0x0600 = 1536 decimal.
72 C6 → Often a transaction ID, session ID, or another 2-byte value. Hex 0x72C6 = 29318 decimal.
C0 A8 65 0F → This looks exactly like an IPv4 address in hex: C0 A8 65 0F → 192.168.101.15 (source IP address!)
00 00 → Possibly padding, reserved, or a 2-byte zero field.
0C C3 → Could be a port, checksum, or some other 2-byte value. Hex 0x0CC3 = 3267 decimal.

Both payloads share the same core structure:
[ Header | Opcode | Flags | TxID | IP #1 | Value ]
that strongly suggests same protocol or same base message format. Note that the 2024 payloads had an extended basic message with  timestamp, status/flag fields, the destination IP address and an additional numeric value.

Other UDP payloads appear to carry DCE/RPC (Distributed Computing Environment/Remote Procedure Calls) protocol: these will likely be explored in a next post.

November 2024 recordings (thanks to Kosmod) were very important because, as I said, they highlighted an improvement/adaptation of the application-layer protocol; equally important will be new recordings of these transmissions made (hopefully) in the next days. 

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

(1) an armed forces officer assigned by governments to diplomatic missions abroad as a technical advisor on matters of military relevance.

UDP datagrams sent via STANAG-5066 over async MS-110A (IP over HF)

This is a casual catch while I was exploring the 14 MHz band (14963.5 KHz/USB to be precise): the data transmission occurred after the usual MS-141A 3-way handshake between the ALE nodes 101 (caller) and 102 (called). Recording thanks to linkz KiwiSDR [1]. The used HF waveform is MS-110A in 300bps/Long mode (Figure 1).

Fig. 1 - MS-110A 300bps/L waveform

The resulting bitstream after MS-110A decoding uses 8N1 asynchronous framing (1 start bit, 1 stop bit) as shown in Figure 2.

Fig. 2 - 8N1 framing in demodulated bitstream

Examining the 8-bit bitstream after removing the start/stop bits, it must be noted the presence of the 16-bit Maury-Styles synchronization sequence 0xEB90 (LSB transmitted first) which identifies the STANAG-5066 Data Transfer Protocol Data Units (D_PDUs) frames (1). 

Fig. 3 - STANAG-5066 sync sequences

 

I then decided to process the 8-bit bitstream using the STANAG-5066 dissector tool [2] obtaining interesting results which I comment below. The STANAG-5066 transfer consists of two frames which are basically a repetition (2): Figure 4 shows the first D_UDP frame.

 

Fig. 4 - first frame of the STANAG-5066 transfer

a) The D_PDU is type: 7 NON-ARQ DATA, ie Non-ARQ data transfer. Indeed, as Figure 1 shows, the data transmission is not followed by feedback ACK bursts. The "Delivery confirmation = none" flag is an additional confirmation of the NON-ARQ data transfer mode.

b) STANAG-5066 Addresses are
Source node address: 011.020.100.101
Destination node address: 011.020.100.102
Note that the last 3 digits of the addresses (101 and 102) correspond to the respective MS-141A ALE addresses used during link management.
If 11.20.y.z are actual STANAG-5066 addresses, ie not fake or dummy addresses (!), the nodes belong to an Armenian political or organizational network (STANAG-5066 Table N-9 — Middle East National Addressing Schema). Also note that in STANAG 5066, addresses are logical identifiers that reflect political or organizational belonging, not physical location.

 

c) The used "Source and Destination Service Access Point" is 9 (1001 binary): this identifies an IP-type Client/Application, according to STANAG-5066 #F.1.2 Standardized Assignment of Service Access Point Identifiers. Thus, this is a real-world example of IP over HF.

d) The "Client Application ID" field serves to identify the application (i.e., higher-level protocol) using the connection.

For further analysis of the IP packet we need to extract and edit a "reassembled" C_PDU, provided by the dissector tool, and then save it as an HEX dump file. We have to remove the first 6 bytes, ie the headers of C (Channel Access Sublayer) and S (Subnetwork Interface Sublayer) Protocol Data Units:
00 00 99 40 6D 9F
where:
00 C_PDU type (0 = data)
00 S_PDU type (0 = data)
99 S_PDU source & destination SAP IDs (1001 & 1001)
40 6D 9F S_PDU control and TDD fields
After removing these first 6 bytes you can copy and paste the hexadecimal data and save it to a .txt file, as for example "hex_dump.txt" (Figure 5).

 

Fig. 5

The HEX dump file can be now analyzed by using the well-known "wireshark" tool [3]: first click "File" -> "Import from Hex Dump", select the file to be imported, set offsets to "none" and Encapsulation Type to "Raw IP" then click Import. The result of the IP packet analysis is shown in Figure 6.

 

Fig. 6 - IP packet analysis

a) The first interesting thing to note are the values of the source/destination IP addresseses: 192.168.101.15 and 192.168.102.15, here too we see a repetition of the "digits" 101 and 102. Sumarizing:
ALE address: 101 - STANAG-5066 address: 011.020.100.101 - LAN IP address: 192.168.101.15
ALE address: 102 - STANAG-5066 address: 011.020.100.102 - LAN IP address: 192.168.102.15

b) As expecetd, since the Non-ARQ type D_PDU, the IP packet transports an User Datagram Protocol (UDP, a connectionless communication protocol) datagram with destination port 2753.
According to the official IANA service registry [4], the UDP port 2753 is registered as "de-spot". This means that if an application declares it uses UDP 2753, it’s conventionally associated with a service called de-spot, but that name doesn’t correspond to any widely known mainstream protocol like DNS or DHCP. It’s a registered but obscure / application-specific designation, port 2753 seems to be utilized by specific monitoring tools without a universal standard service name. 

c) The UDP datagram transports the 16 bytes payload [0x]:
00 10 00 03 06 00 72 c6 c0 a8 65 0f 00 00 0c c3
I asked ChatGPT to try to break down the payload byte by byte, it's something like "mission impossible" I know, but some results are worth attention. 

1. 00 10 → Possibly a message type or some identifier (2 bytes). Hex 0x0010 = 16 decimal (just the length of the message!)
2. 00 03 → Another 2-byte field, could be message type or command. Hex 0x0003 = 3 decimal.
3. 06 00 → Could represent a flags field, version, or sub-type. Hex 0x0600 = 1536 decimal.
4. 72 C6 → Often a transaction ID, session ID, or another 2-byte value. Hex 0x72C6 = 29318 decimal.
5. C0 A8 65 0F → This looks exactly like an IPv4 address in hex: C0 A8 65 0F → 192.168.101.15 (just the IP address of the sender!)
6. 00 00 → Possibly padding, reserved, or a 2-byte zero field.
7. 0C C3 → Could be a port, checksum, or some other 2-byte value. Hex 0x0CC3 = 3267 decimal.

The exact meaning depends on what application protocol is encapsulated inside the UDP packet. As seen, the IP address in UDP payload matches the source address in IP header: by itself, UDP doesn’t care about IP addresses, payload fields just contain whatever the application protocol puts there (data/metadata).
I do not know why the source IP address is repeated in the UDP paylod, maybe it's due to protocol design, NAT traversal, or validation (heartbeat/keepalive message?): I think that a network specialist could clarify the question and the used application protocol.

As is usual in SIGINT analysis, I followed a bottom-up approach, that is, I started from the HF bitstream and worked my way up to the application layer protocol. Top-down flow of the data is shown in Figure 7.

Fig. 7 - data flow during transmission

Every now and then I stop for a few hours to monitor the channel (14963.5 KHz) but up until the time of writing I have not had the luckiness of listening such transmissions, neither simple MS-141A exchanges.

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

(1) As per STANAG-5066 "C.3.2 Generic detailed D_PDU structure": All D_PDUs, regardless of type, shall begin with the same 16-bit synchronisation (SYNC) sequence. The 16-bit sequence shall (5) be the 16-bit Maury-Styles (0xEB90) sequence shown below, with the least significant bit (LSB) transmitted first: (MSB) 1 1 1 0 1 0 1 1 1 0 0 1 0 0 0 0 (LSB).

(2) most likely the D_PDU frame is repeated to provide some increased probability of receipt and reliability.

[1] http://linkz.ddns.net:8075/?f=14963.50usbz8
[2] http://i56578-swl.blogspot.com/2021/02/a-stanag-5066-off-line-dissector.html
[3] https://www.wireshark.org/
[4] https://www.iana.org/...service-names-port-numbers.txt

A new Russian PSK8 serial waveform

Some days ago my friend cryptomaster sent me an interesting recording dated December 4, 2025 about a test of new communications equipment conducted in the Russian Federation. The signal was recorded at the frequency of 15014.0 KHz/USB kHz and its external modulation parameters are similar to NATO standards used for serial waveforms, namely the symbol rate is 2400 Baud and the transmission mode is PSK8 (Figure 1). 

Fig. 1 - serial waevorms main parameters

The analysis of the ACF is very interesting (Figure 2). I think that the real structure of the frame is 106.66 ms which - at the speed of 2400 Bd - corresponds to a frame length of 256 tribit symbols (or 768 bits): a length quite usual in such PSK8 waveforms. In my opinion the strong 1173.33 ms spikes (corresponding to 2816 tribit symbols) could be caused by the interleaver (or the scrambler) length: in this case 8448 bits. As you know, an interleaver (and a scrambler) is deterministic and periodic and because of that, it can introduce hidden periodic structures into the signal, even if the original data looks random. When you compute the ACF, those periodicities may show up as spikes at specific lags. In this case 8448 is not a "casual" number but it's a quite structured one corresponding to 1056 bytes and it is exactly a multiple of the length of a single frame, ie 768 × 11 = 8448 (as you can see in Figure 2). 

Fig. 2 - ACF analysis

Something similar happens in MS-110A at low data rates (<1200 bps): in those cases, one group of four frames count 160 symbols (4×40) and it's just "in sync" with the scrambler length (160 symbols) causing the strong 66.67 ms ACF spikes rather tha the expected 16.67 ms [1].
About the interleaver, in the Russian MIL context the interleaver lengths are usually specified explicitly in bits or symbols (quantitatively), not categorized as “short,” “medium,” or “long” (qualitatively) like NATO documentation sometimes does, so if I'm right it could be a 8448-bit block interleaver, 1.17 s depth.

Now, why I talk about a Russian waveform? The analyzed signal is actually a segment of a longer recording which also includes some op-chats which are clearly in Russian language (Figure 3).

Fig. 3 - spectrum of the entire recording

My friend cryptomaster kindly provided me with a transcript of the chat. I didn't translate it, as the possible use of military jargon would have distorted the translation. The full transcript is available as a "transcript note" at the bottom of the post. Anyway, the .wav file you can download contains the entire recording (op-chat + signal).

The analysis of a 8448-bit slice of the PSK8 demodulated bitstream (only a conversion of phase positions), reshaped to a 768-bit period, doesn't help to detect/identify some sort of structured framing. Although repeating blocks of data are easily identifiable, the "usual" structure of Known/UnKnown data as we are used to seeing in similar waveforms is missing (Figure 4). Given the "experimental" nature of the transmission, it's possible that the same structures are being sent... but this is just pure speculation.
A more in-depth study of the code is certainly necessary, as is the need for further catches of this waveform.

Comments are welcome.

Fig. 4 - 768-bit period

 https://disk.yandex.com/d/oRognr-CGqxbgg

[1] https://i56578-swl.blogspot.com/2021/06/188-110a-acf-lengths-and-interleaved.html

transcript note
- 121, парусу.
- Парус, я 121, вы принимали от меня телекод? Квитанцию отдал, но вы не приняли по всему. После этого свой телекод отправил, но не принял от вас квитанцию.
- Мы отправку делали, получили на неё квитанцию и ваше сообщение получили и тоже дали квитанцию. Приём.
- Принято, отправьте в нашу сторону ещё одно сообщение.
- отправляем.

(передача сообщения)

- 121 парусу.
- у меня нет приёма. Приёмник не работает.
- (непонятно) или нет приёма, всё-таки?
- "Бозон" работает, а "чинара", у меня приёмник не работает на неё.  Дайте счёт до двадцати, я послушаю на приёмнике.
- Ну, канал, может быть, немного ушёл, но эти "ноги" снять сегодня не успеем, как поняли? Прём.
- Хорошо, да, ладно.
- Даю счёт (передаёт счёт до 20), приём.
- Парус, я принимал от вас на четыре бала, наверное, но с прерываниями.
- Может, на другой канал перейдём? Повыше? Приём.
- Давайте, перейдём на другой канал. 

STANAG-4538 LDL packets retransmissions, an interesting case

A few days ago I was casually watching the 4 MHz band when an unusually long STANAG-4538 (3G-HF) transmission on 4561.0 KHz/USB caught my attention and I decided to record it for later analysis.
Basically, in the usual STANAG-4538 way (ARQ), after the data link connection has been configured, the sending station and the receiving station alternate transmissions: the sending station transmitting xDL PDUs (Protocol Data Unit) containing payload data packets and the receiving station transmitting acknowledgment/control packets of whether or not the data packet in the preceding PDU was received without error (1). In this case the LDL protocol is used (Figure 1).

Fig. 1 - STANAG-4538 LDL transfer

As per STANAG-4538, the "original" datagram to be sent is split into fixed-length segments which will be processed into packets by the chosen LDLn protocol. Indeed, a LDL data packet is defined as a fixed-length sequence of n-byte data segment (n = 32,64,96,...,512) followed by a 17-bit Sequence Number plus an 8-bit Control Field (presently unused). During the construction of the LDL BW3, a 32-bit Cyclic Redundancy Check (CRC) value is computed across the  data bits of each data packet and then appended. Then, 7 flush bits having the value 0 are added to ensure that the encoder is in the all-zero state upon encoding the last flush bit. Sumarizing, the on-air length of a LDLn BW3 burst is computed in bit as 8n + 64, in this case (LDL512, n = 512) 4096+64 = 4160 bit or 520 bytes (Figure 2).

Fig. 2 - LDL512 demodulated bitstream

That said, we can inspect the last 64 bits (17-bit Sequence Number + 8-bit Control Field + 32-bit CRC + 7 flush bits) of the recorded BW3 bursts  (Figure 3).

Fig. 3 - last 64 bits of the demodulated LDL512 bitstream

The 8-bit reserved field is added after the CRC field and not after the Sequence Number, as specified in Annex C to STANAG-4538; I don't know if it's the modus operandi of the decoder. Moreover, the bits of the Sequence Number field are transmitted starting with the Last Significant Bit (bit 0) rather than the most significant bit (bit 16), most likely it's the modus operandi of the decoder, as above.
In this sample you may see that the Packet Number #3 is sent 20 times and it clarifies the unusually length of the transmission (actually the number of packet retransmissions is greater than 20 since some bursts were not correctly demodulated, hence not present in Figures, due to their bad SNR value). The Packet Byte Count field is always 511, this means it's a LDL512 transfer. The EOM & SOM fields are both set to "0" meaning that's an "interior" packet. The CRC fields show the same value.

110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
3           511          EOM                 CRC field                          control + flush bits
                             SOM

I stopped recording after more than 5 minutes, see Figure 4, and most of the time (4 minutes and 4 seconds!) was spent on the transmissions of the single packet #3; also note the repeated transmissions of packets #2 (2 times) and #4 (6 times) at the beginning and end of the recording (Figs. 2,3).

Fig. 4 - duration of the whole recording (software "audacity")

 

So, why so many retransmissions? 

STANAG-4538 is designed for High-Frequency (HF) radio communication, which is notorious for having a highly unstable and challenging channel environment. The large number of retransmissions may be a direct consequence of the protocol's need to ensure reliable data delivery over this unreliable medium. STANAG-4538 employs an ARQ (Automatic Repeat reQuest) scheme as part of its data link protocols to achieve this reliability. The maximum number of retransmissions in ARQ schemes is specified by the parameter N_tx (or often N_max​ or N_retries​): if the packet is not acknowledged as successfully received after the last retransmission it is typically discarded by the data link layer, and the link connection may be closed (2).  This clause normalizes the trade-off between reliability and efficiency/latency (preventing the channel from being permanently blocked by an unrecoverable packet). 

The usual or default value for the N_tx parameter is not specified in standard documentation summaries, not even in STANAG-4538, as it is a configurable parameter of the HF modem which is set by the manufacturer or even by the system operator. In commercial and military HF implementations of similar ARQ schemes, the maximum retransmission count is often set to a value like 4, 8, or 10, but the actual number should be verified against the specific equipment's configuration settings.

One of the causes of retransmissions is poor HF channel conditions: fading, multipath distortion, noise, interference and man-made interference (from electronics or other users). Any of these factors can cause bit errors in the received packet, which the receiver detects via a checksum (CRC) and then requests a retransmission of the corrupted packet.
A second important cause is the Adaptive Code Combining (Hybrid-ARQ). Indeed,  STANAG-4538's data link protocols utilize a form of Hybrid-ARQ with code combining. This mechanism is specifically designed to work in poor channels and directly contributes to retransmissions. Instead of just discarding an unreadable packet, the receiver stores the corrupted data. When a retransmitted copy of that same packet arrives, the receiver combines the information from all received copies (the original and all retransmissions) to try and successfully decode it. The fact that it takes over 20 attempts may mean the combined information only reaches the decoding threshold after a significant number of transmissions.

In short, the retransmissions aren't necessarily a sign of failure, but rather the core mechanism of STANAG-4538 actively working to provide error-free data transfer despite the inherent unreliability of the HF radio channel.

It should also be considered that the used KiwiSDR receiver [1] is a sort of "man in the middle", i.e. it sees all the traffic on the channel, but this does not necessarily apply to the stations actually involved (not all data/ACK packets can be correctly received by the two peers).

So, it is likely that the N_tx parameter is set to a value greater than 20 and channel conditions are very poor... but we could also consider another cause besides  STANAG-4538 ARQ.
Perhaps we are observing retransmissions "forced" by the higher-layer protocol running over the STANAG-4538 data link (running at Layer 2), specifically TCP (Transmission Control Protocol, running at Layer 4). The limit of N_tx applies strictly to the LDL/ HDL protocol itself. A high retransmission count may occur because of the interaction between the two layers, particularly when running IP over HF:

 

- STANAG-4538 (Layer 2) action
the STANAG-4538 data link protocol tries to deliver a single packet  and if all attempts fail, it discards the packet and moves on to the next one. Result: The packet is considered lost by the Data Link Layer.
- TCP (Layer 4) action
TCP is the reliable transport protocol often used for applications like web browsing, email, or file transfer, and it runs over IP, when a packet is lost by the lower layer (Layer 2, STANAG-4538), the TCP sender never receives an acknowledgment for that packet, TCP's retransmission timer eventually expires, and it assumes the network failed to deliver the data (TCP is not HF-aware!), crucially, TCP retransmits the data independently of the Layer 2 protocol.
- the domino effect
STANAG-4538 transmits a packet several times, it fails and discards the packet. TCP times out. It retransmits the data. The new TCP segment is given to STANAG-4538 which treats it as a new packet to send. STANAG-4538 transmits this "new" packet up to N_tx times again. If it fails again, TCP times out a second time, and the process repeats until the packet is successfully acknowledged.

If the channel conditions are so poor that the STANAG-4538 link fails more than N_tx times in a row before TCP gives up, the total number of retransmissions for a single packet could easily assume a large value, as the higher layer continually resubmits data to the persistently failing lower layer.
Anyway, technically TCP cannot directly cause packet retransmission, only STANAG-4538 does that: TCP increases the likelihood of retransmissions, but it does not initiate them!

Summarizing: 

N_tx parameter is set to a large value (>20) to prioritize ultimate delivery reliability over speed and to support Hybrid-ARQ mechanism

or

N_tx parameter is set to a low value (often in the range of 3 to 10 or similar small number) and TCP times out and re-injects the data.

Definitely channel conditions were undoubtedly poor and severe.

 

Perhaps - in my opinion - it would have been better to use LDL packets size smaller than 512 bytes (4160 bits). Under poor channel conditions, a smaller packet size is generally better, even though the number of packets increases. Shorter transmissions (reduced airtime) reduce exposure to fades, have lower probability of interference and collisions, enable faster ARQ cycles and improve latency:
large packet → high chance of corruption → many retransmissions

small packet → lower chance of corruption → fewer retransmissions (even though more packets)

 

Fig. 5 - Packet Error Probability (PEP) vs. packet length (theoretical model)

The airtime, or duration, of STANAG-4538 LDLn BW3 bursts is variable and depends on the amount of data being sent, specified by the parameter n. The total burst duration is given by the formula: duration (ms) =373.33 + n×13.33, (n = 32,64,96,...,512).

The possible total airtimes for a single BW3 burst for the four standard BW3 burst sizes (n=64,128,256,512) are:

n Value	Payload Duration	Total Burst Duration
64	853.12 ms	1226.45 ms (≈1.23 seconds)
128	1706.24 ms	2079.57 ms (≈2.08 seconds)
256	3412.48 ms	3785.81 ms (≈3.79 seconds)
512	6824.96 ms	7198.29 ms (≈7.20 seconds)

 

Longer packets like $n=512$ transmit more data per burst, leading to higher throughput, but they are also significantly more vulnerable to errors (higher PEP) since require a much longer airtime (up to $7.2$ seconds).

[1] recording tanks to linkz KiwiSDR #3 (French Alps)

https://disk.yandex.com/d/2r0xOdGLWu45UA

 

(1) STANAG-4538 xDL protocols:
HDL (High-throughput Data Link protocol) waveforms: BW1 for acknowledgement and traffic management, BW2 for traffic data
LDL (Low-latency Data Link protocol) waveforms: BW3 for traffic data, BW4 for acknowledgement and traffic management
HDL+ waveforms: BW6 for acknowledgement and traffic management, BW7 for traffic data

(2) Why the Limit is Necessary
HF Channel Volatility: HF radio conditions are highly variable due to ionospheric fading and noise. While the LDL protocol uses Code Combining (Hybrid-ARQ) to increase the likelihood of decoding a packet with each attempt, a limit is needed to account for extreme or prolonged channel outages.
Preventing Link Stall: Unlimited retransmissions would cause the entire data link to stall, continually trying to send a packet that may be unrecoverable due to a sudden deep fade or interference. By limiting the attempts, the protocol can decide to terminate the link and allow the higher layers (or the operator) to attempt a new link setup on a different, possibly better, frequency. 

 

UK DHFCS FSK 800Bd/850 & STANAG-4285 1200bps/L

Interesting and unknown (at least for me) FSK transmission in 800Bd/850Hz mode sent to me by my friend cryptomaster. These transmissions have been heard during the evening (UTC) on the frequencies 8014, 8180, 10008 and 12414 kHz.

Fig. 1 - FSK parameters

The signal has an ACF of approximately 1280 ms which corresponds to a period of 1024 bits (Figure 2).

Fig. 2 - ACF value and relative bitmap

  

The bitstream obtained after demodulation has a complex and very interesting structure (Figure 3).

Fig. 3 - demodulated bitstream

The most interesting thing is that after a few days the FSK signals have disappeared and been replaced by STANAG-4285 signals in two of the above-mentioned frequencies: 8013.20 and 10008.20 KHz/USB (Figure 4).

Fig. 4 - FSK & STANAG-4285 transmissions

The S-4285 transmissions - which have also disappeared - were recorded in 1200bps/L mode and once demodulated show a bistream period of 1536 bits which is very similar to the 1024 bits bitstream of the previous FSK transmissions: just 512 bits of difference, see Figs. 3 and 5 (below).

Fig. 5 - 1536 bits period bitstream of the STANAG-4285 transmissions

The format of the bitstreams (both FSK and STANAG-4285) suggests the use of a TDM (Time Division Multiplexer), probably the GA-205 model, or a modified version of it, as already analyzed in other posts relating to UK DHFCS (Defense High Frequency Communications Service) and Australian MHFCS (Modernized High Frequency Communications System) transmissions [1]. The STANAG-4285 1200bps broadcasts utilize time-division multiplexing to carry up to 12 KW-46 encrypted streams on a single frequency. Moreover, FSK/STANAG-4285 transmissions on the same channel have already been observed previously and attributed to DHFCS: Tx site of Crimond [2].  a single frequency.

Direction Finding tests (TDoA algorithm), although slightly inaccurate, indicate St. Eval (DHFCS) as the likely site of signal transmission (Figure 6).

Fig. 6 - some Direction Finding tests

It's difficult to determine the purpose of these broadcasts; perhaps they're tests or specific needs. Let's hope we have better luck and catch more similar signals.

https://disk.yandex.com/d/qIF5cmD797W_iQ (FSK signal)

https://disk.yandex.com/d/Y50xjENZ50TPAg (STANAG-4285 signal)

[1] http://i56578-swl.blogspot.com/search/label/1536-bit%20TDM
[2] http://i56578-swl.blogspot.com/2024/06/300-bps-fsk-stanag-4285-fleet-broadcast.html

Deep WALE (4G-ALE) Async call using PSK2

(for background http://i56578-swl.blogspot.com/search/label/4G-ALE)

Very interesting example of an asynchronous three-way Deep WALE handshake (4G-ALE, MS-141D App.G)(1) sent to me by my friend ANgazu; recordings credits to EA6AMM Gaspar. Although the common protocol exchange for 4G-ALE link establishment is the two-way handshake, it may occurs a traffic channel negotiation which requires a three-way handshake.
In figure 1 you can see the call which is formed by the "scanning call" (also known as "capture probe") + the actual Request, the call is then followed by the called & caller Confirm bursts. The scanning call is designed to capture asynchronously scanning receiver(s) so that they will stop scanning to receive the final Request. However, conversely of 2G and 3G ALE, the scanning call portion of the async WALE call is unaddressed: that is, the addresses of the stations are not sent during the capture probe and receivers are held unitl the reception of the ending Request.

Fig. 1 - Deep WALE async call

The scanning call consists of repeated blocks (known symbols) with an ACF value of 80 ms (Figure 2) that permit rapid detection of the call, and therefore very short scanning dwell times. As in 2G and 3G ALE, the duration of the WALE scanning call dependes on the number of channels in the scan set and is as follows:

Tcapture ≥ Dmin(N+2)

where Dmin is the asynchronous-mode minimum dwell time (200 ms as default setting) and N is the number of channels. Since the capture probe lasts about 3500 ms, assuming the default setting is used, the number of channels is 15.

Fig. 2 - ACF value of scanning call (capture probe) portion

But the most important thing - see Figure 3 - is that the Deep WALE waveforms (call and confirms) use PSK2 modulation(!) rather than PSK8 as required by MS-141B App.G standard.

Fig. 3

Once demodulated, the capture probe consists of a 192-bit sequence (originating the 80 ms ACF) which is repeated - in this sample - 44 times (blocks):

0x [D1 38 6C BC 22 71 BD 65 B9 21 D6 F2 C6 FD FE 8F 49 D1 D9 FD 36 0D F1 80]
0x [2E C7 93 43 DD 8E 42 9A 46 DE 29 0D 39 02 01 70 B6 2E 26 02 C9 F2 0E 7F] opposite polarity 

Fig. 4 - 192-bit sequences forming the scanning call blocks

These waveforms are not MS-141D App.G compliant at all; in fact, according to the standard:
- the modulation used shall be PSK8, while in the recorded samples is used PSK2;
- the scanning call blocks shall consist of 96 symbols, while here the blocks consist of 192 symbols, exactly double (obviously, the respective ACF values ​​are also double);
- the duration of the Deep WALE Request (~ 622 ms) does not match the expected 1520 ms value (240 ms preamble + 1280 data ms).

Perhaps it is some specific implementation of a new and more robust Deep WALE call, given that PSK2 is more robust than PSK8 especially in terms of error performance under the same noise conditions (2).

https://disk.yandex.com/d/GBKjZzt4q9509Q (recordings credits to EA6AMM Gaspar)

(1) The multiplicity of abbreviations and acronyms sometimes doesn't help, below what I used:
WB ALE (or WBALE), Harris implementation of 3GWB
WALE (or 4G ALE), wideband ALE as for MIL 188-141D App.G, fourth generation ALE
note that WB ALE is not synonymous with WALE since the latter has its own PDUs and waveforms.

(2) In PSK2, the phase shift between the two possible symbols is 180°, which makes it very easy for the receiver to distinguish between them even in the presence of noise. In PSK8, the phase difference between adjacent symbols is only 45°, so even a small amount of noise can cause symbol errors.

Link-22 12QAM waveform

Fig. 1 - Link-22 transmission

Recently my friend ANgazu from radiofrecuencias.es sent me a great catch of a Link-22 transmission - Figure 1 - recorded at 11128.0 KHz/USB. Identifying the mode (Link-22) is fairly straightforward by examining the bitmap depicting the framing period used by the waveform (Figure 2).
The 112.5 ms duration is typical of the waveforms used by Link-22 and described by STANAG-4539 standard (non-hopping TDMA traffic waveforms). Note that in this case the framing consists of 3 data blocks (DATA) interspersed with three mini-probes (MP) blocks.

Fig. 2 - typical Link-22 framing

Honestly, examining the individual bursts I expected to find QPSK or PSK8 modulations: I was very surprised when the phase plane revealed bursts with QPSK and even 12QAM constellations within the same transmission (Figure 3): clear sign that the header must therefore encode the modulation mode.

Fig. 3 - QPSK and 12QAM constellations

A 12QAM modulation is employed in non-hopping TDMA traffic waveform #13 (Annex G to STANAG-4539):

12QAM is unusual because QAM typically uses powers of 2 (so each symbol cleanly represents an integer number of bits). 12 is not a power of 2, so it cannot map bits directly since log⁡2(12) ≈ 3.585 bits per symbol, which is not an integer.
However, some NATO HF modem implementations of STANAG-4539 use a circular 12QAM layout (which uses two concentric rings) rather than the rectangular one (3x4 grid). Figure 4 shows an approximate layout:
- inner ring 4 points (like QPSK), offset for symmetry
- outer ring 8 points evenly spaced (like 8-PSK)
This design gives a radial + angular separation, making it easier to decode under fading and noise than a rectangular grid. 

Fig. 4 -  circular 12QAM (STANG-4539 style)

This variation of a constellation is not "new" in STANAG-4539 as, for example, the 64-QAM constellation described in paragraph #4.2.2.1.6: "This constellation is a variation on the standard 8 x 8 square constellation, which achieves a better peak-to-average ratio without sacrificing the very good pseudo-Gray code properties of the square constellation".

As seen, with 12QAM circular, the goal is 3.5 bits/symbol (b/sym). There are at least three practical approaches:
1) 4-bit labeling + FEC rate 7/8
2) Multilevel/TCM ( trellis-coded modulation): 3 info bits + 1 structural bit
3) Probabilistic Amplitude Shaping (PAS)
The most common is the 4-bit labeling + FEC rate 7/8:
- assign a 4-bit mapping to the 12 points (16 combos → 12 used, 4 unused).
- apply channel coding with rate R=7/8 (e.g., LDPC or turbo). Net efficiency: 4×7/8=3.5 b/sym.

I can give an Octave example [1] for such method with a 12QAM circular constellation. Since Octave doesn’t have built-in LDPC/RS at hand, the code illustrates it using a simple block code to emulate the R=7/8 effect (i.e., 7 info bits + 1 parity). The principle is the same as using LDPC/Turbo in practice.
What it does:
1. Defines the 12QAM circular constellation (4+8 rings) with 4-bit Gray-like labels.
2. Implements a (7,8) block encoder (simple parity, emulating FEC with rate 7/8).
3. Transmits random data: 7 info bits → +1 parity → 8 coded bits → mapped into 2 QAM symbols.
4. Sends through an AWGN channel.
5. At the receiver: nearest-neighbour detection, recover labels.

Fig. 5 - 4-bit labeling + FEC rate 7/8 simulation

Must be noted that:

* the STANAG-4539 12QAM waveform uses a channel coding with rate R=4/5 and TBCC (Tail-Biting Convolutional Code). Net efficiency: 4×4/5=3.2 b/sym.

* STANAG-4539 is not the same as Link-22, but Link-22 can use STANAG-4539 as one of its underlying HF bearers.

* the Octave code is just an example/simulation just to prove that  ~3.58 bits per symbol fits nicely with the interleaving, coding, and frame structures used in the waveform: I do not know what is the method for the 12QAM used in the analyzed signal.

The choice of 12 points is not arbitrary, it’s a trade-off between spectral efficiency and robustness: it can deliver intermediate data rates where 8-PSK is too low and 16-QAM is too fragile under HF channel conditions. In military waveforms like STANAG-4539, robustness and flexibility matter more than mapping convenience.

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

[1] https://disk.yandex.com/d/kZmCP-fdqtc-cw