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.