Quantcast
Channel: diario SWL I-56578 Antonio
Viewing all 623 articles
Browse latest View live

splitting datagrams into LDLn Tx Frames

$
0
0
This post is added  to complete theprevious one, so to study and verify the way a datagram is splitted to fit the length of the chosen LDLn Tx frame (n =32,64,96,…,512 bytes) and the mechanism used to fill the remaining room. This recording concerns a 139-byte lenght 'Citadel' encrypted datagram which is sent within five LDL32 PDUs, ie using 5 x 32 = 160 bytes: the protocol shall fill the extra 21 bytes of the last PDU with 0-value bytes (Fig. 1). 

Fig. 1
After the data link connection has been configured (FLSU/BW5), the sending station and the receiving station alternate transmissions in the usual STANAG-4538 manner: the sending station transmitting LDL PDUs containing payload data packets (BW3), and the receiving station transmitting ACK PDUs (BW4) each containing an acknowledgment of whether or not the data packet in the preceding LDL PDU was received without error. The sending station sends an EOM PDU (BW4) repeated as many times as possible to indicate to the receiving station that the the datagram have been delivered successfully and the link will be terminated (Fig. 2)

Fig. 2
For a better understanding of the way LDL protocol works the incoming datagram, let's see how the LDL PDU and BW3 are formed (quoting Annex C to NATO STANAG-4538).
If the Tx Frame buffer is clear, construct a new outgoing data packet in the following manner (Fig. 3):
1. Get the next data segment (the next PacketLength consecutive data bytes to be transmitted) from Tx Datagram buffer; place these in the Payload field of the data packet. If fewer than PacketLength data bytes remain to be transmitted, place these bytes at the
beginning of the Payload field; fill the remainder of the field with zero-valued bytes so that the Payload field contains a filled segment.
2. Construct a sequence number and write this value into the packet’s Sequence Number field.
3. Construct a control field with all 8 bits set to zero.
4. Place the data packet generated in steps 1-3 into the Tx Frame buffer.
5. Send an LD PDU containing the tx frame in Tx Frame buffer, using BW3 waveform.

Fig. 3
It's worth noting that:
- one LDLn Tx Frame, same as an LDLn PDU, consists of a single data packet of n-bytes (n=32,64,96,…,512); then LDLn delivers chunks of n-bytes at time (n=32,64,96,…,512);


- one HDLn Tx Frame, same as an HDLn PDU, consists of n-data packets each of 233 bytes (n=3,6,12,24); then HDLn delivers n-packets at time, each of 233 bytes (n=3,6,12,24).

 
The number of bits in a BW3 data packet is of the form 8n+25, where n = 32, 64, 96, 128, 160, 192, 224, 256, 288, 320, 352, 384, 416, 448, 480, or 512 (number of payload data bytes carried by each LDL protocol forward transmission);  the additional 25 bits of payload in each BW3 transmission are LDL overhead (17 bits Sequence number + 8 bits for reserved use). A 32-bit Cyclic Redundancy Check (CRC) value is computed across the payload data bits in the data packet, and is then appended to the data packet, then 7 flush bits having the value 0 are appended to the (8n+57) bits of the data packet with CRC to ensure that the encoder is in the all-zero state upon encoding the last flush bit.
So each BW3 data packet has a length of 8n+64 bits (8n+17+8+32+7): just the latest eigth bytes will be used for the analysis.

From theory to practice, the way the 139 byte datagram is splitted in five LDL32 Tx Frames can be verified by inspecting the  Sequence Number fields in the last 64 bits of the five BW2 data packets of the copied transmission (Fig. 4).

Fig. 4
Someaspects must be first considered:

a) the 8-bit reserved field is added after the CRC fieldand not after the Sequence Number,as specified in Annex C to STANAG-4538; I don't know if it's themodus operandi of the decoder;

b)  following the last bit of the Payload field-value, the bits of the Sequence Number field are transmitted starting with the least significant bit (bit 0) rather than the most significant bit (bit 16). Most likelyit's themodus operandi of the decoder, as above;

c) as in the Sequence Number of HDL Tx frames (see the previous post), the bits 14-6 of the first packet in datagram contain the number of user bytes in packet -1 and this contrasts what specified in Table 7.1.4.1-2; it depends on the particular STANAG-4538 implementation?

c) the 'Packet Number', bits 5-0 in the Sequence Number field, indicates the position occupied by a data segment within a datagram. Since the datagram passed to LDL for delivery is an ordered sequence of up to 16,384,000 bytes (7,634,944 bytes for LDL), limiting the packets addressing to 6 bits could be fastidious in ARQ.

As expected, EOM and SOM fields (bits 16,15) show that the BW2 packet 0 contains the first packet of the datagram, while BW2 packet 4 contains the last packet of the datagram. Consequently, the Packet Number (bits 5-0) starts from 0 to 4: ie, the useful payload consists of five BW2 packets. Consider now the Packet Byte Count (bits 14-6): as already specified, this field show the number of user bytes in packet –1. Each of the first four packets contains 32 bytes (00001111 = 31) and the last packet contains 11 bytes (00001010 = 10). The outgoing datagram was then (4 x 32) + 11 = 139 bytes length.
During the traffic setup phase, the user process determines the number of data bytes per LDL PDU so as to deliver the user data efficiently. Once it is determined, every transmitted LDL PDU shall contain the same number of data bytes until the entire datagram has been delivered.



https://yadi.sk/d/PvOS5FbM3H96Wz
https://yadi.sk/i/UgFjnPTv3H97zz

 
 

CIS Navy FSK 50Bd/250 136 bit

$
0
0

Interesting signal from my friend KarapuZ: it's the quite uncommon 50Bd/250 136 Bit by some Cis networks, most likely CIS Navy. The waveform is similar to the well known T600 (50Bd 200/250Hz) but in this case the full period is 544 bits lenght, ie 4 x 136 bit frames.

Fig. 1
Fig. 2

just banned (although I'm a member...)

$
0
0

UTDX.de banned my IP, although I'm a member and I never posted messages in that forum. Weird behaviors there...
 

Logs

$
0
0

05717.0: MER39ALEX: Unid 0536 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to ALEX (20Apr17) (AAI)
06258.0: ---: Unid 1753 USB R&S GM-2100 serial modem 2400Bd bursts (22Apr17) (AAI)
06303.0: ---: Unid 1954 USB 2-way FLSU handshake followed by LDL32 sending 139 bytes 'Citadel' encrypted datagram (20Apr17) (AAI)
06303.0: ---: Unid 1958 USB 2-way FLSU handshake followed by LDL512 sending 2379 bytes 'Citadel' encrypted datagram (20Apr17) (AAI)
06745.0: COLMALEX: Unid 1722 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to MER22ALEX (19Apr17) (AAI)
06745.0: MER22ALEX: Unid 1724 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to COLMALEX (19Apr17) (AAI)
06745.0: MER39ALEX: Unid 1723 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to MER22ALEX (19Apr17) (AAI)
06745.0: MER39ALEX: Unid 1729 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to MER28ALEX (19Apr17) (AAI)
06933.0: M72: Israeli Air Force Boeing KC707, ISR 0707 USB MIL 188-141 2G-ALE calling itself ??? (06Apr17) (AAI)
07401.0: ZBOR: German customs Patrol vessel Borkum, D 0755 USB MIL 188-141 2G-ALE calling ZLST (11Apr17) (AAI)
07480.0: DO7: Polish Military, POL 0621 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to OS6 (12Apr17) (AAI)
07527.0: TYMT2: Spanish Police Toledo, E 0619 USB MIL 188-141 2G-ALE sounding (14Apr17) (AAI)
07692.0: Q7E: Moroccan Gendarmerie, MRC 1901 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to 0VM (09Apr17) (AAI)
07692.0: W4V: Moroccan Gendarmerie, MRC 1637 USB MIL 188-141 2G-ALE handshake Q7E followed by MIL 188-110A serial (07Apr17) (AAI)
07715.0: ---: Unid 1906 USB 3G-HF 2-way FLSU handshake followed by LDL128 transfer (11Apr17) (AAI)
07803.0: RFFXCC: French Forces CENTCORADIO FAVIERES, F 0710 (cf) ARQ-E 184.6Bd/400 test msg to REGLEGETPARA CALVI (10Apr17) (AAI)
07813.0: S31: Moroccan Military, MRC 1856 USB MIL 188-141 2G-ALE sounding (09Apr17) (AAI)
07885.0: PIZ: Unid 0818 USB MIL 188-141 2G-ALE any station call followed by MIL 188-110A serial (24Apr17) (AAI)
07903.0: ---: Unid 1819 USB 3G-HF 2-way FLSU handshake followed by circuit mode (MIL 188-110A serial) (14Apr17) (AAI)
07917.0: BS110A: Unid (prob. Algerian net, ALG) 0857 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to BS108B (17Apr17) (AAI)
07940.0: 400001: Mauretanian Law-Enforcement, MTN 1846 USB MIL 188-141 2G-ALE sounding (09Apr17) (AAI)
08021.0: ---: Unid 1200 USB STANAG-4285 600bps/L modem, KG-84 encrypted messages (11Apr17) (AAI)
08061.0: ---: Unid 2140 USB 3G-HF 2-way FLSU handshake followed by LDL232 transfer (10Apr17) (AAI)
08070.0: 123: Algerian Military, ALG 0906 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to AT5 (08Apr17) (AAI)
08086.5: ICI11: Italian Coast Guard Catania, I 1149 J3E/USB calling ship IGSV for a radio-check, no reply heard (11Apr17) (AAI)
08125.0: DU6: Polish Military, POL 0638 USB MIL 188-141 2G-ALE handshake HA9 followed by MIL 188-110A serial (12Apr17) (AAI)
08165.0: ---: Russian Mil, RUS 1700 USB CIS-45 HDR modem v2, OFDM 45-tone 40Bd DQPSK (20Apr17) (AAI)
08218.0: ---: Unid 1738 USB 2-way FLSU handshake followed by HDL+ (21Apr17) (AAI)
08327.0: ---: Unid 1416 USB 3G-HF 2-way FLSU handshake followed by 10 x LDL160 transfer (9 retransmissions of the same Citadel encrypted data packet) (14Apr17) (AAI)
08327.0: ---: Unid 1445 USB 3G-HF 2-way FLSU handshake followed by HDL+ transfer (14Apr17) (AAI)
08330.6: ---: Unid 0750 USB STANAG-4285 600bps/L modem, KG-84 encrypted messages (11Apr17) (AAI)
09182.0: N61: Chinese Military, CHN 1735 USB MIL 188-141 2G-ALE calling A99 (20Apr17) (AAI)
09328.0: ---: Russian MFA, RUS 0825 (cf) FSK 200Bd/1000 (08Apr17) (AAI)
10600.0: 641814: Unid USB MIL 188-141 2G-ALE sounding (13Apr17) (AAI)
10958.0: ---: Unid 1356 USB 3G-HF MDL transfer using LDL288 (08Apr17) (AAI)
11010.0: ---: Unid 0858 USB ARCOTEL-MAHRS 2400 Serial ARQ system (13Apr17) (AAI)
11130.0: GR2: Moroccan Military, MRC 1908 USB MIL 188-141 2G-ALE sounding (07Apr17) (AAI)
11165.0: BASOR1: Algerian Air Force, ALG 0811 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to CM1OR1 (09Apr17) (AAI)
11165.0: CM1: Algerian Air Force, ALG 0815 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to 761 (09Apr17) (AAI)
11165.0: CM1: Algerian Air Force, ALG 0818 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to 745 (09Apr17) (AAI)
11169.6: ---: Unid 0822 (cf) Siemens CHX-200 modem selcall (09Apr17) (AAI)
11226.0: AKR: USAF Akrotiri, CYP 1122 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to 201085 (24Apr17) (AAI)
11430.0: 410BBLU410CAVB: US Army 1248 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to 410BCDR410CAVB
11430.0: 64BSBT: US Army 1328 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to BDETOC3ABCT
11454.0: ---: Russian Mil/Gov, RUS 0928 USB CIS-3000 PSK-8 3000Bd followed by MFSK-64 (32+32) 45Bd (10Apr17) (AAI)
13449.5: ---: UK Mil/Gov St. Eval 1340 USB WinDRM-based OFDM 51-tone modem (14Apr17) (AAI)
16083.0: ---: Russian Intel, RUS 0900 USB CIS FTM-4, MFSK-4 150Bd (effective 37.5:Bd) 4000Hz modem (tones at: -6, -2, +2, +6 KHz) 8 mins lasting (10Apr17) (AAI)
16332.3: A: MX Beacon "A" Astrakhan 1238 CW id "._" (20Apr17) (AAI)


STANAG-5066 CFTP messaging over MIL 188-110A

$
0
0
The transmission has been copied on 7788.0KHz/USB and consists of an emails exchange between an Algerian Navy ship (Rais Hamidou) and the Headquarter of French Navy in Toulon (COMTOULON).  Messaging is performed by Stanag-5066 CFTP protocol (Internet Messaging over ARQ) in half-duplex mode, carried by MIL 188-110A serial waveform (Fig. 1). Link is not negotiated/established using ALE but by means of voice-comms between the operators.

Fig. 1
Basically, CFTP (Compressed File Transfer Protocol), sometimes referred to as BFEM (Battle Force Email), is a file transfer mechanism and STANAG 5066 Annex F defines its use for message transfer. CFTP is specified to work over a point to point network - that is, to communicate between a pair of nodes, with both nodes able to send data.

Fig. 2 - S5066 bitstream synched on D_PDU SYNC
The CFTP protocol shall not be used for Formal or High Grade Military Messaging (military orders) and may be used for informal interpersonal e-mail only; anyway, I'm interested in the way the "boxes" travel and not in their contents.
In operation, when an email message is received at a S-5066 node (port 5066 on localhost), it is placed in an incoming mail folder (mail spool directory). The CFTP client, also called the Delivery Agent, removes the mail from this incoming folder and compresses the message and information about the message, e.g. size, id, recipients, etc. into a file which is then transferred to the destination node using the Edition-1 Basic File Transfer Protocol (BFTPv1)  PDUs which are then incapsulated into Data PDUs (Fig. 2) before to be sent to the HF modem. The structure of BFTPv1  PDU is shown in Fig. 3, along with the g-zipped file from the copied transmission.

Fig. 3 - BFTPv1 Protocol Data Unit Structure
Client Delivery confirmation is provided by the receiving node using the Message Acknowledgement, sent as the body-part (!) of a CFTP/RCOPv1 PDU:

Fig. 4 - BFTPv1 Message Acknowledgement Structure
The CFTP mail-file is built as specified in paragraph "F.14.6 Detailed Description of CFTP, ANNEX F to STANAG 5066 Edition 3":

Fig. 5 - CFTP email-file
Below, some details about the two STANAG-5066 nodes in the play:

node: EMMA046
tactical callsign: PI (papa india)
S-5066 address: 006.014.100.001 (official  NATO S-5066 address)
email domain: toulon.frenchnavy.fr
host: EMMA046 (Rockliffe SMTPRA 4.2.4)
site: COMTOULON Toulon, French Navy

node: BDSL472
tactical callsign: BD (bravo delta)
S-5066 address: 010.000.000.001 

(near-official NATO S-5066 address since the 010.001 block is assigned to Algeria)
email domain: rh.raishamidou.dz
host: BDSL472 (Windows NT 6.1; WOW64; rv:24.0)
site: corvette "Rais Hamidou", Algerian Navy

Rais Hamidou corvette, photo from wikipedia https://fr.wikipedia.org/wiki/Rais_Hamidou_(corvette)
The other labels in the emails headers offer some other informations:  

1) PC at COMTOULON run an SMTP daemon hosted on a Rockliffe MailSite based server (Rockliffe SMTPRA 4.2.4):
https://www.rockliffe.com/index.html

2) the "WOW64" in user-agent string means a 32-bit version of Internet Explorer is running on a 64-bit processor: so the ship is equipped with a 64-bit PC running Windows7 or Windows Server 7 (Windows NT 6.1)


By the way, it's interesting to note in the curious behavior of one of the two 188-110A modems and  precisely the one at the ship side of the link: the initial 2600Hz tone-beep is maintained for the duration of each single transmission time and does not affect the correct demodulation of the signal (Fig. 3)

Fig. 3
Although 188-110A is an auto-baud waveform, operators negotiate the speed and interleaver which will be used during the initial phase of the data transmission: this leads to think to inter-operability or deployment tests.

(due to confidentiality, wav file and bitstream are not avalilable. Sorry.)

STANAG-4538, point-to-point FLSU_Terminate PDU

$
0
0
Contrary to what one would think, an established 3G-HF PTP (Point-To-Point) packet link is terminated by the called PU rather than the caller PU; in S-4538 terminology, the akronym PU refers to a generic Partecipating Unit, typically a radio station. The link termination is a capability of the FLSU protocol by means of the FLSU_Term Protocol Data Unit (PDU) which terminates the sender’s participation in the current link, analogous to the  use of the 2G-ALE TWAS word.
A good example of a 3G-HF PTP link termination is shown in Figure 1: the different strengths of the received signals help to spot the two PUs.

Fig. 1
The caller PU issues a 2-way FLSU_Request Protocol Data Unit (PDU) which conveys the caller PU address, called PU address, priority, and the desired traffic service (xDL ARQ mode). The called PDU responds with a FLSU_Confirm PDU, indicating the ability to continue with the requested traffic service.
Both the caller and called alternate sending xDL PDUs, with the caller sending data using the xDL Data Send PDU, and the called responding with the xDL ACK/NAK PDU. This process continues until all data has been transferred error-free, as indicated by the caller sending redundant xDL End Of Message (EOM) PDU’s. Immediately after the xDL transfer is complete, both stations iunitiate the Fast Traffic Management (FTM) protocol to negotiate further traffic. This gives the called PU an opportunity to send data packets in the reverse direction (see this post).
After a the so-called Reversal Timeout has occurred (1), the last station to receive an xDL transfer shall terminate the link with an FLSU_Term PDU (2). It's worth noting that after the EOM PDUs, both PUs remain linked (!) and since the caller has already completed its data transfer, it is up to the user process at the called PU to deliver any packet traffic it has, or to terminate the link if it doesn't have traffic to send.
Note that:
- an xDL_EOM PDU indicates to the receiving station(s) that the data transfer will be terminated;
- an FLSU_Term PDU indicates to the receiving station(s) the sender’s departure from the current link.
Obviously, in MDL or EMCON scenarios the link termination is up to the caller PU (Fig. 2):

Fig. 2 - PTM scenario
The initial FLSU PDU establishes the point-to-multipoint link, then a series of three LDL-412 PDUs carry a multicast message. After the datagram transfer is completed, also using retransmissions of packets, the caller PU terminates the link with an FLSU_Term PDU. 
Note that the receiving PUs are set up to receive either an MDL forward packet PDU (BW3 burst waveform in this case) or an EOM PDU (BW4 burst waveform in this case): sending a FLSU_Term (BW5 burst waveform) at time (1) would impose a (not allowed) triple demodulation requirement on the receiving PUs.

All FLSU PDUs use the BW5 burst waveform and support a 50-bit structure, or BW6 and a 51-bit structure in conjunction with HDL+; the 51st bit is an additional CRC bit. The PDU Type field indicates the role of the PDU in the potocol: type = 2 is used for the Term PDU (5.3 Protocol data units, Annex C to STANAG-4538 Amendment 2).


As a final note, sometimes MIL 188-141C is referred to STANAG-4538 but this is not totally correct: yes, the specifications contained in the Appendix C have been replaced with reference to the essentially identical NATO STANAG-4538, but MIL 188-141C does not provide the FLSU Fast Link Setup protocol (BW5 burst waveform) neither HDL+ protocol (BW6 and BW7 burst waveforms).



https://www.youtube.com/watch?v=v5E5gLgee0c&feature=youtu.be&hd=1


https://yadi.sk/d/wbokQPIK3HWZky 

STANAG-5066, ARQ & non-ARQ PDUs in a real-world HF radio link

$
0
0
The STANAG-5066 standard, and its second generation Data Link Protocol, provides data transfer using ARQ as well as non-ARQ point-to-point, broadcast or multicast data transfer. The Data Transfer Sublayer (DTS) is responsible for the efficient data transfer across the radio link and use the D_PDU types displayed in Figure 1 to support both ARQ and Non-ARQ services:

Fig. 1 - D_PDU types used by STANAG-5066 DTS
For what concerns the I-frame D_PDUs: 

- the NRQ (No Repeat-Request or non-ARQ) Protocol, commonly known as broadcast mode, only operates in a simplex mode since the local node, after sending I-frames, does not wait for an indication from the remote node as to whether or not the I-frames were correctly received. Multiple repetitions of I-frames can be transmitted in order to increase the likelihood of reception under poor channel conditions, in accordance with the requested service characteristics.

- the SRQ (Selective Repeat-Request) Protocol operates in a half or full duplex mode since the local node, after sending I-frames, waits for an indication in the form of a selective acknowledgement from the remote node as to whether the I-frames were correctly received or not. The local node then either sends the next I-frames, if all the previous I-frames were correctly received, or retransmits copies of the previous I-frames that were not. The local node will retransmit copies of the previous I-frames if no indication is received after a predetermined time interval.

Pinpointing D_PDUs in a real-world HF radio link is not difficult since, regardless of type, they all begin with the same Maury-Styles 16-bit sync sequence 0xEB90, 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)
The D_PDU type field occupies the 4 most significant bits of the 3rd byte (Figure 2).

Fig. 2 - Generic D_PDU Frame Structure
The chosen example is a S-5066 data transfer that uses MIL 188-110A Serial as HF waveform (Fig. 3):


Fig. 3- 188-110A over-the-air symbols
Once removed the overhead bits added by 188-110A, the D_PDUs can be isolated by syncing the resulting bitstream with the sequence 0xEB90 (the DS_PDU SYNC sequence): the result is displayed in Figure 4.

Fig. 4
 
The NON-ARQ DATA (type 7) and EXPEDITED NON-ARQ DATA (type 8) D_PDUs are used to send segmented data when the transmitting node needs no explicit confirmation the data was received (NRQ mode).

Fig. 5 - type 8 D_PDU
 
The DATA-ONLY (type 0) D_PDU is used to send segmented data when the transmitting node needs an explicit confirmation the data was received. The DATA-ONLY D_PDU is used in conjunction with a basic selective automatic repeat request type of protocol.

Fig. 6 - type 0 D_PDU

The ACK-ONLY (type 1) D_PDU is used to selectively acknowledge received DATAONLY or DATA-ACK D_PDUs when the receiving station has no segmented C_PDUs of its own to send.

Fig. 7 - type 1 D_PDU

As indicated in Figure 2, the header of every D_PDU includes an end-of-transmission (EOT) field. This 8-bit field specifies how much of the current transmission remains, in units of one-half second. This elegantly eliminates the end-of-transmission ambiguity that arises during an extended channel fade. If even a single header is received error-free, the receiver knows when it will be safe to send an ACK. Note that this field bounds the duration of STANAG 5066 transmissions at just over two minutes. This field is also used in case of non-ARQ (type 8) D_PDUS, as displayed in Figure 8

Fig. 8 - the (decreasing value) EOT field

Note:
in some cases, the shown results could suffer of the lack of error-frames which have not been correctly demodulated or discarded.

STANAG-4538 HDL+, BW7 QAM-16 waveform

$
0
0

- Burst Waveform 6 (BW6) is used to convey the HDLP_DHDR, HDLP_ACK, and HDLP_EOT PDUs of the HDL+ data link protocol, and to convey PDUs of the FLSU and FTM protocols on a packet link established for delivery of data traffic using HDL+ (note the Link terminate PDU that is conveyed by a BW6 burst). BW6 PDUs bursts have 51 bits of payload, an on-air duration of 386.67 ms, and are transmitted using a PSK-8 modulation.
- Burst Waveform 7 (BW7) is used for transfers of traffic data by the HDL+ protocol. The HDL+ protocol combines high data rate waveforms similar to those of STANAG 4539 or MIL-STD-188-110C Appendix C with incremental redundancy techniques. 

- La burst waveform 6 (BW6) viene utilizzata per trasmettere le PDU HDLP_DHDR, HDLP_ACKe HDLP_EOT del protocollo HDL+ e per trasmettere le PDU dei protocolli FLSU e FTM su link che utilizzano HDL+ (notare che la PDU che termina il link viene infatti trasmessa da un burst BW6 e non da un bust BW5 come avviene nel caso di link che utilizzano HDL e LDL). Le PDU BW6 dispongono di 51 bit di carico utile (payload), una durata in aria di 386,67 msec e vengono trasmesse usando una modulazione PSK-8.
- La burst waveform 7 (BW7) è invece utilizzata dal protocollo HDL+ per il trasferimento dei dati. Per BW7, il protocollo HDL+ combina forme d'onda simili a quelle specificate da STANAG 4539 o MIL-STD-188-110C Appendice C, ma con differenti tecniche di ridondanza incrementale.

Given the variable lengths and modulation formats of HDL+ data, it's necessary to include a header at the beginning of each BW7 PDU (which was unnecessary in LDL and HDL) that announces the number of packets and modulation format of the following payload section of the transmission (HDLP_Data PDU). For this header, the HDL+ uses a BW6 PDU (HDLP_DHDR PDU). 
Since BW6 symbols are modulated using a PSK-8 constellation, the structure composed of BW6-BW7 PDUs
will be clearly visible in those cases where BW7 use a different constellation for its symbols, such as QAM-16 or QAM-64 (BPSK and QPSK are scrambled to appear on-air as a PSK-8 constellation). 

Date le lunghezze variabili e i diversi formati di modulazione dei dati HDL +, è necessario includere una "intestazione" (header) all'inizio di ogni PDU BW7 (che non era necessaria in LDL e HDL) che annuncia il numero di pacchetti e il formato di modulazione della seguente sezione dati della trasmissione (PDU HDLP_Data). Per questa intestazione, HDL+ utilizza una PDU BW6 (PDU HDLP_DHDR). Poiché i simboli di BW6 sono modulati usando una costellazione PSK-8, la struttura composta dalle PDU BW6-BW7 sarà chiaramente visibile nei casi in cui BW7 utilizza una costellazione diversa per la modulazione dei suoi simboli, come ad esempio QAM-16 o QAM-64 (BPSK e QPSK vengono sottoposti a scrambler per apparire in-aria come simboli PSK-8).

Just yesterday, I copied a such HDL+ data transfer on 11132.0 KHz/USB. As displayed in Figure 1, the 8th power harmonics are present for all the duration of the BW5 and BW6bursts, but only in the initial segments of the BW7 bursts, ie in the BW6 PDUs that work as headers. The HDLP_DATA PDUs are instead modulated using a QAM-16 constellation (12 points in the outer ring, 4 in the inner ring).

Proprio ieri, ho copiato una simile trasmissione HDL+ su 11132.0 KHz/USB. Come mostrato in Figura 1, le armoniche di ottavo grado (segno di una modulazione PSK-8) sono presenti per tutta la durata dei bursts BW5 e BW6, ma solo nei segmenti iniziali dei bursts BW7, cioè nelle PDU BW6 che fungono come intestazione. Le PDU dati (HDLP_DATA) sono invece modulate usando una costellazione QAM-16 (12 punti nell'anello esterno, 4 nell'anello interno).

Fig. 1

For what concerns the analysis of the BW7 waveform, no initial synchronization preamble is required since this role is filled by the BW6 HDLP_DHDR PDU. Instead, an initial probe sequence containing two repetitions of a 32-symbol Frank-Heimiller sequence (a total of 64 known symbols) is transmitted.
The following section is used to convey between one and fifteen (inclusive) packets. Each packet is composed of a sequence of unknown/known (“UK”) frames. Each UK frame contains a data block, a sequence of 256 unknown symbols modulated with payload data, followed by a 32-symbol mini-probe. The number of UK frames used to convey each data packet depends on the signal constellation, the code rate, and the payload size.

Per quanto riguarda l'analisi della forma d'onda BW7, non è richiesto alcun preambolo iniziale di sincronizzazione poiché questo ruolo viene svolto dalla PDU BW6 HDLP_DHDR. Invece, viene trasmessa una sequenza iniziale (probe) contenente due ripetizioni di una sequenza Frank-Heimiller a 32 simboli (per un totale di 64 simboli noti). La seguente sezione di viene utilizzata per trasmettere tra uno e quindici pacchetti. Ogni pacchetto è composto da una sequenza di frame sconosciuti/noti (Unknown/known, "UK"). Ogni frame UK contiene un blocco dati, una sequenza di 256 simboli con i dati di payload (sconosciuti), seguito da un mini-probe a 32 simboli (noti). Il numero di frames UK utilizzati per trasmettere ogni pacchetto di dati dipende dalla costellazione del segnale, dalla velocità di codifica e dalla dimensione del payload che deve essere trasmesso.

Fig. 2
Fig. 3
 
Other than the recording of the transmission, a short video (from my YouTube channel) that illutrates the analysis with SA  is also available.


https://youtu.be/rRI-kgf_b9Y







NATO "copy-and-paste" ...and errors

$
0
0
Computer-based editing can involve very frequent use of copy-and-paste operations but sometimes these operations can lead to significant errors. I came across a case by reading the Annex C to STANAG-4538 Ed.1, more precisely the Amendment 21. The problem arises in "TABLE 7.2.5.2-1. LDL actions", where is specified (litterally):
"Note: The LDL transmitter can send duplicate packets either as a result of missing an LDL_ACK PDU,or at the end of a datagram, in order to fill the (otherwise unused) packet positions of an LDL_DATA PDU. The LDL receiver is required to inspect the sequence number of each data packet received without errors, and to use the sequence numbers to identify and discard duplicate packets."(highlighted in Figure 1).
Fig. 1
This text is clearly a copy-and-paste from "TABLE 7.1.5.2-2. HDL actions", unless the the term HDL (Figure 2):
Fig. 2

Well, the statement "The LDL transmitter can send duplicate packets either [...] or at the end of a datagram, in order to fill the (otherwise unused) packet positions of an LDL_DATA PDU."  (Fig .1) is wrong since LDL protocol, contrary to what HDL does, does not provide 'packet positions' in its DATA PDU but rather one single packet at a time! (each HDL_DATA PDU is a sequence of 24, 12, 6, or 3 data packets, in which each packet is composed of 233 bytes of payload data; each LDL_DATA PDU is a single data packet composed of 32, 64, 96,..., 512 bytes of payload data).

It's an oversight that hopefully will be edited in the next edition :)

interesting paper about IP Multicasting in HF Radio Networks

$
0
0
I recently found in the web the interesting paper titled IP Multicasting in HF Radio Networks (2008) that proposes a multicast data link protocol for third generation (3G) high frequency (HF) radio networks:
http://mac-ee211.nmsu.edu/hf/papers/3g_mdl.pdf
I have a doubt about the "MDL Operation" paragraph and the related Figure 3 of the paper:



According to §4.6.5 "Dual Demodulation" of Annex-C to STANAG-4538 Ed.1: under no circumstances shall PUs be required to simultaneously demodulate more than two waveforms.
Well, at time "tn" in Figure 3 the receiving PUs expect an LDL_DATA PDU (BW3) or an LDL_EOM/TERM PDU (BW4): sending a FLSU PDU (BW5) would impose a triple demodulation requirement. 

Thus, the calling PU shall send an LDL_EOM PDU (BW4) to indicate that the entire datagram has been transferred and the FEC Phase 0 session is terminated; then the following FSL PDU (BW5) will be sent to announce the repetition of the datagram in the alternate FEC code:

Anyway, since the multicast scenarios proposed in the paper have been evaluated using the DoD-validated HF Network Simulator (NetSim-SC), and then not implemented in real radios, the procedure depicted in Figure 3, although wrong, could be a simplification.


CIS 81-81 single channel variant, FSK 40.5Bd/500Hz

$
0
0

this is a single channel variant of CIS T-206-3M (3M1) modem that operates at a speed of 81 Baud in case of two stations are worked (two distinct channels). It's a quite "old" system, most likely in use by some ex USSR republic. 
The recordered transmission has been copied on 08195.0 KHz (cf) during an idling cycle.





Logs from Tuscany

$
0
0

07500.0: AI1: Algerian Military, ALG 0721 USB MIL 188-141A LQA Request Response to XV1 (10May17) (AAI)
07509.0: ---: Unid 0714 USB 2-way FLSU handshake followed by HDL+ datagram (10May17) (AAI)
07545.5: ---: Unid 0742 (cf) RATT 75/850 encrypted tfc (10May17) (AAI)
07554.6: FUG: French Navy Saissac, F 0810 USB STANAG-4285 1200bps/L continuous pseudo-random broadcast (10May17) (AAI)
07570.0: KA31: Algerian Military, ALG 1537 USB MIL 188-141A, LQA REQUEST RESPONSE to NX30 (28Apr17) (AAI)
07572.0: MATADOR: Unid Spanish station 0740 J3E/USB radio-check (same for other heard calls such as TIGRE,Arion,PAISAN,...) (25Apr17) (AAI)
07580.0: IN4: Unid 0626 USB MIL 188-141A call to TMR410 (09May17) (AAI)
07626.0: 277: Unid prob. Chinese Diplo, CHN 1745 USB MIL 188-141A, handshake w/ 278 followed by MIL 188-110A serial (28Apr17) (AAI)
07655.0: 1PY: Roumanian MOI/Police, ROU 0733 USB MIL 188-141A LQA Request Response to CAL (10May17) (AAI)
07660.0: ---: Unid 0630 USB 2-way FLSU handshake followed by LDL128 'Citadel' encrypted 628 bytes datagram (09May17) (AAI)
07660.5: ---: Unid USB THALES Skymaster, ALE Skyhopper mode (09May17) (AAI)
07732.5: BM11: Belgian Military - NATO PfP exercise, B 0757 USB/J3E working AM11, SVK1 (Slovakian Mil.) (03May17) (AAI)
07775.0: HA9: Polish Military, POL 0829 USB MIL 188-141A LQA Request Response to DU6 (09May17) (AAI)
07788.0: BD: Algerian Navy "Rais Hamidou" class corvette, ALG 1406 USB STANAG-5066 CFTP test msgs exchange w/ PI, COMTOULON Toulon French Navy, MIL 188-110A as HF carrier (26Apr17) (AAI)
07830.0: MDN: Algerian Ministry of Defense, ALG 1355 USB MIL 188-141A LQA Request Response to NX01 (02May17) (AAI)
07885.0: SAZ: Unid (Swedish Military?) 0652 USB MIL 188-141A LQA Request Response to WWX (09May17) (AAI)
07890.0: NX10: Unid 0826 USB MIL 188-141A call to KB11 (09May17) (AAI)
07899.0: XS61: Algerian Military, ALG 1343 USB MIL 188-141A handshake w/ NX40 followed by (likely Harris AVS) scrambler (02May17) (AAI)
07964.0: ZM53: Unid 0919 USB MIL 188-141A 2-way LQA exchange with NX50 (10May17) (AAI)
08010.0: ---: Ukraine Militay, UKR 0652 USB MFSK-4 (double FSK) 100Bd 500Hz,(tones at -750, -250, +250, +750) (03May17) (AAI)
08054.0: BX02: Algerian Military, ALG 0622 USB MIL 188-141A LQA Request Response to BX01 (05May17) (AAI)
08061.0: RK37: Algerian Military, ALG 1336 USB MIL 188-141A call to NX30 (02May17) (AAI)
08066.0: CO1: Unid 0650 USB MIL 188-141A LQA Request Response to BE1 (long scanning call) (10May17) (AAI)
08066.0: CO1: Unid 0802 USB MIL 188-141A LQA Request Response to BE1 (long scanning call) (09May17) (AAI)
08067.0: ---: Unid 0746 (cf) BELL 103 compatible modem (10May17) (AAI)
08073.0: ---: Russian Intel/Diplo, RUS 0735 USB MFSK-64 (32+32) 45Bd modem (10May17) (AAI)
08083.5: ---: Unid 0833 USB 2-way FLSU handshake followed by HDL+ datagram (09May17) (AAI)
08092.0: 343013: Turkish Civil Defense, TUR 0819 USB MIL 188-141A sounding (09May17) (AAI)
08125.0: OS5: Polish Military, POL 0707 USB MIL 188-141A LQA Request Response to A9 (10May17) (AAI)
08128.2: ---: Unid 0816 USB STANAG-4285 1200bps/L continuous pseudo-random broadcast (10May17) (AAI)
08132.0: BP26: German Police vessel, D 0604 USB MIL 188-141A handshake w/ BPLEZS followed by R&S GM2100 modem transporting R&S X.25 login procedure (03May17) (AAI)
08182.0: XJJ: UK-DHFCS, G 0834 USB MIL 188-141A, several handshakes w/ XSS followed by MIL 188-110A serial (28Apr17) (AAI)
08195.0: ---: Russian Military, RUS 0825 (cf) FSK 40.5Bd/500 (CIS 81-81 single channel variant), no traffic (10May17) (AAI)
08204.5: ---: Unid 0740 (cf) RATT 75/850 encrypted tfc (10May17) (AAI)
08327.0: ---: 0729  USB 2-way FLSU handshake followed by HDL6 sending 'Citadel' encrypted datagram (29Apr17) (AAI)
08327.0: ---: Unid 1545 USB 2-way FLSU handshake followed by LDL32 sending 139 bytes 'Citadel' encrypted datagram (28Apr17) (AAI)
10539.6: ---: Unid 0844 (cf) Siemens CHX-200 modem selcall (02May17) (AAI)
10601.0: ---: Unid 1529 USB MIL 188-141A running in Linking Protection mode (28Apr17) (AAI)
10751.0: ---: Unid 1407 (cf) FSK 300Bd/500 messages, 360-bit ACF (28Apr17) (AAI)
10833.0: ---: Unid 1511 USB MIL 188-141A running in Linking Protection mode (28Apr17) (AAI)
10900.0: ---: Unid 0913 USB 3G-HF 2-way FLSU handshake followed by 2 x HDL12 data transfer (04May17) (AAI)
10935.0: 830NETIP: Unid 1355 USB MIL 188-141A call SORIA06NETIP (05May17) (AAI)
10935.0: SORIA06NETIP: Unid 1355 USB MIL 188-141A call 830NETIP (05May17) (AAI)
11010.0: ---: Unid 1619 USB ARCOTEL MAHRS 2400Bd serial modem (10May17) (AAI)
11125.0: ---: Unid 1615 Hagelin HC-256 voice scrambler (10May17) (AAI)
11132.0: ---: Unid 0935 USB 3G-HF 2-way FLSU handshake followed by HDL+ data transfer using BW7 QAM-16 bursts (Stanag-4539 HF waveform) (04May17) (AAI)
11132.0: ---: Unid 1051 USB 3G-HF MDL transfer using LDL416 sending 'Citadel' encrypted datagram (30Apr17) (AAI)
11135.0: HQ4: Unid 0710 USB MIL 188-141A LQA Request Response to GANOB8, AMD "IFBUIFSHSBIBN" (05May17) (AAI)
11156.0: LAG: Algerian Air Force Laghaout, Alg 0900 USB MIL 188-141A handshake CM4 followed by MIL 188-110A Serial (07May17) (AAI)
11168.6: KWX57: US DoS Ankara, TUR 0829 USB MIL 188-141A LQA Request Response to WNG767 US DoS Pristina/Kosovo (04May17) (AAI)
13373.0: ---: Russian Mil, RUS 1130 USB CIS-45 HDR modem v2, OFDM 45-tone 40Bd DQPSK (03May17) (AAI)
13555.0: ILZ: Algerian Air Force, ALG  0913 USB MIL 188-141A, LQA REQUEST RESPONSE to CM4 (30Apr17) (AAI)
14623.0: D78: Unid, prob. Chinese net 1304 USB MIL 188-141A, LQA REQUEST RESPONSE to A98 (30Apr17) (AAI)
15957.0: ---: Russian Air Force, RUS 1256 (cf) FSK 50Bd/500, encrypted messages (02May17) (AAI)

RACAL MA4248 "MEROD", ARQ FSK 266.6Bd/800Hz

$
0
0

The transmission was heard on 9274.0 (cf) and consists of FSK-2 bursts with shift of 800Hz and manipulation speed of 266.67 Baud. Thes features points at the RACAL MA4248 device, also known as MEROD (Message Entry Read Out Device): thanks to my friend KarapuZ for the help in identification.

Fig. 1 - manipulation speed
Fig. 2 - FSK shift
Once demodulated the signal, the measured period is 48 bits:

Fig. 3 - 48-bit period
The RACAL MEROD transmissions can be decoded by Code-300, although the contents are encrypted: 

Fig. 4 - MEROD RAC-ARQ mode running in Code-300

The RACAL MA4248 "MEROD" device was  designed for sending messages in burst transmission mode over HF/VHF/UHF radio links and were therefore used by special forces in combination with a man pack radio, these unit is also known as a tactical data entry device, TDED. MA4248 utilise a complex error correction system that ensures that the message can be correctly received over very poor quality HF links.  

Fig. 5 - RACAL MA4248 device


Unid 2400Bd QPSK burst system

$
0
0

This mode employ 4-ary phase-shift keying (QPSK) on a single 1800 Hz carrier as the modulation technique for data transmission, the modulation of the carrier is a constant 2400 symbols/sec waveform.

Fig. 1
Each transmission consists of four 870 ms bursts each composed of a preamble followed by 21 data blocks (Figure 2); each data block is composed of 90 QPSK symbols: 31 known symbols probe followed by 59 (unknown) data symbols (Figs 3,4).

Fig. 2
Fig. 3
Fig. 4
These transmissions have been heard up & running for some hours on 10410.0 KHz/USB on 18 May morning, sometimes a second station has been heard working in a ARQ-like mode (Fig. 5).

Fig. 5
No idea about the source and the name of such system.
Other unid transmissions using QPSK bursts modulated at 2400 symbols/sec are discussed here:
http://i56578-swl.blogspot.it/2016/08/unid-qpsk-2400bd-single-tone-burst.html
http://i56578-swl.blogspot.it/2016/07/unid-qpsk-2400bd-1125ms-acf.html

--> update

The same transmissions have been heard also by cryptomatser and are discussed in radioscanner.ru forum by him and KarapuZ,  here the link:
Http://www.radioscanner.ru/forum/index.php?action=search&loc=1&forum=21&topic=39959&page=1319757


Doppler spread monitoring in 9 MHz band signals

$
0
0

Looking for "Spectan" software download I come across an interesting  web page  about the "Precision Carrier Doppler Analysis": intrigued by this argument, I tried to replicate the Doppler spread analysys and these are the results of my one-day monitoring of two transmissions in the 9 MHz band (9182.0 and 9115.0 KHz, both in USB).

Due to the time-varying nature of the ionosphere, the propagation path is never static and the received sky-wave signals may suffer distortion in the form of temporal dispersion (delay spread) as well as fluctuation in the signal’s amplitude and phase (Doppler spreading). Recent high latitude measurements have observed multipath signals of more than 10 ms duration and other signals have shown evidence of Doppler spreading greater than 50 Hz. More typical mid-latitude sky-wave channels might show delay spreads of 1 - 4 ms with Doppler spreads of 1 Hz or less.
In a few words, Doppler spread occur because during the day the apparent height at which signals are reflected changes quite markedly, leading to quite easily observable frequency shifts. It is the rate of change of apparent height which is related to the frequency shift. Doppler spread  is commonly defined as the range of frequencies over which the received Doppler spectrum is essentially non-zero. When a pure sinusoidal tone of frequency fc  is transmitted, the received signal spectrum will have components in the range fc – fd to fc + fd , where fd is the Doppler shift. 

Looking for suitable transmissions to monitor, I decided in favor of the continuous B'casts of the Russian Navy on 9 MHz band: such transmissions are on USB and use the AT-3004D modem known as CIS-12. The signal consists of 12 BPSK modulated tones (MPSK), 120 bps per channel, with a Pilot Tone at ~3300 Hz which is just used for Doppler correction at receiving sites.

1) daylight path, 9182.0 KHz CIS-12 transmission (Fig. 1)

Fig. 1
During the daylight path the  the Doppler spread is less than 1 Hz (as expected), since during the day the D layer supposedly absorbs the signal before it reaches the ionosphere. However, the absorbtion is not always complete, and the signal is also propagted via its E-layer daytime reflection. The E layer is relatively stable, and shows little Doppler spread (Fig. 2).
Starting from about 1630 UTC (Fig. 3), the region of the transmitter enters in its Grey Line and the signal starts to be seen from various scatter paths and then reflected from the F-layer. The rise of the Doppler spread is quite easily observable.

Fig. 2
Fig. 3
 
2) darkness path (after local sunset), 9115.0 KHz CIS-12 transmission (Fig. 4)
 
Fig. 4
Starting from about 17.30-1800 UTC (summer time, in my area) the D layer stops absorbing completely, and the signal starts to be reflected from the F-layer. At this time the effective height of the F layer is rising as ion density decreases and the Doppler spread reflects the instability of the F layer. I do not know the reason of the drift around 20.00 UTC.

Fig. 5
Fig. 6
It's interesting to see that the two transmissions have Doppler tones which differ of about 10 Hz: most likely it is due to two different transmitters.

3) setup
As said, the software used for this monitoring is "Spectran" - Current version : Version 2 build 216 - and it can be downloaded from http://www.weaksignals.com/
Spectran is a spectrum analyzer written by Alberto, I2PHD and Vittorio, IK2CZL, members of the PAcket Digital Amateur Network group (PADAN), who created also other weak signal and QRSS programs. Spectran allows real time or deferred spectral analysis / waterfall display, in addition to real time audio filtering (band pass, denoising, band reject and CW peaking) of audio signals, using the PC sound card to digitize the input analog signal, or taking as input a WAV file. Its characteristics are well suited to dig weak signals buried into noise, thanks to a selectable bin size down to 21 millihertz.

The "Doppler mode" settings that I used for this monitoring are shown in Figure 7:

Fig. 7
And... yes, It would be much more interesting to monitor the same transmission for more than one day and in different seasons, but this is not my job :)
 

FSK 100Bd/620, Polish Intel

$
0
0
update (26May17)

This morning I copied a transmission on 10211.6 KHz/USB with same ACF (96 bit) but with different frame structure that exhibits a sort of 24-bit length "preamble" followed  by 16-bit length data blocks (8+8 UK) and resembling, in some way, the Stanag/MIL-STD framing.



https://yadi.sk/d/jJ_1leZR3JYWKW

  

FSK 100Bd/620, Polish Intel (10Feb16)


FSK-2 modulation with 620 Hz shift and 100 Baud speed, in use by Polish Intel service.

pic. 1 - baudrate and shift
The signal exhibits clean ACF spikes at 96 bits (~960ms lenght). Looking morecloselyone can distinguish six periods of16bits, most likelythey represent a five digits code and a separator between the groups as also shown in the bitstream (pic. 3).

pic. 2 - 96 bits ACF (6 x 16 bits digits)
.
pic. 3
Looking at the whole demodulated bitstream (pic. 4), although inclusive of the overhead bits, we canget an ideaof the signal structure. First of all, note that the ACF is due to the final part "D" and then does not characterizethe entiresignalbut onlya part. While the parts A and E can be assumed as the 'start' and 'end' of transmission, it's difficult to fix the roles of the other groups: message, destination address, coded-instructions and so on. Talking with my friend KarapuZ, he says we need much more recordings for statistic comparisons since a previous recording of 2014 just exhibits that same characteristics. And if he says so...

pic. 4

short log

$
0
0

 
05825.0: ---: Ukraine Militay, UKR 0618 USB MFSK-4 (double FSK) 100Bd 500Hz,(tones at -750, -250, +250, +750) (18May17) (AAI)
06547.0: SHANWICK: Shanwick MWARA IRL 2023 USB/J3E ATC in comms w/004 (17May17) (AAI)
06873.5: XEN: Unid UK-DHFCS node, UK 2054 USB MIL 188-141A handshake w/XSS followed by MIL 188-110A Serial (17May17) (AAI)
07505.9: XLA: Unid 0808  USB MIL 188-141A call to XLB (19May17) (AAI)
07510.0: HI9: Polish Military, POL 0751 USB MIL 188-141A call to HE5 (19May17) (AAI)
07510.0: HI9: Polish Military, POL 0908 USB MIL 188-141A call TU9 (22May17) (AAI)
07559.0: ---: Unid 0741 3G-HF 2-way FLSU handshake followed by LDL320 sending 591 bytes Citadel encrypted datagram (20May17) (AAI)
07594.5: OEY: Austrian Army, AUT 0848 USB MIL 188-141A call OEY61 (22May17) (AAI)
07605.0: LEONE1: Italian Air Force airborne, I 0754 J3E/USB in comms with ground "take off at 52" (22May17) (AAI)
07628.0: PI: French Navy ODPI Toulon, F 1141 J3E/USB in comms w/FLA, QSLing RATT 75Bd/850 KG-84 encrypted message sent from FLA (QSL de votre message) (20May17) (AAI)
07655.0: RAM: Roumenian Police Ramnicu Valcea, ROU 0831 USB MIL 188-141A call to 1PY (18May17) (AAI)
07655.0: VAS: Roumenian Police Vaslui, ROU 0837 USB MIL 188-141A call to 1PY (18May17) (AAI)
07669.0: ZM55: Unid (presumed Algerian Mil.) 1603 USB MIL 188-141A LQA Request Response to NX50 (20May17) (AAI)
07669.0: ZM66: Unid (presumed Algerian Mil.) 1600 USB MIL 188-141A LQA Request Response to NX50 (20May17) (AAI)
07669.0: ZM68: Unid (presumed Algerian Mil.) 1608 USB MIL 188-141A  2-way LQA exchange w/NX50 (20May17) (AAI)
07711.6: ---: Unid 0730 (cf) continuous RATT 75Bd/850 (20May17) (AAI)
07754.0: Z01: Unid, prob. Polish Military 0845 USB MIL 188-141A call KA1 (22May17) (AAI)
07765.0: BX80: Unid 0736 USB MIL 188-141A LQA Request Response to NX80 (20May17) (AAI)
07766.5: B10: Unid, prob. Ukrainian net 2012 USB MIL 188-141A sounding (17May17) (AAI)
07830.0: WG01: Algerian Military, ALG 0912 USB MIL 188-141A call NX01 (22May17) (AAI)
07890.0: KB15: Unid (presumed Algerian Mil.) 1546 USB MIL 188-141A 2-way LQA exchange w/NX10 (20May17) (AAI)
07890.0: KB17: Unid (presumed Algerian Mil.) 1545 USB MIL 188-141A 2-way LQA exchange w/NX10 (20May17) (AAI)
07890.0: KB20: Unid (presumed Algerian Mil.) 1543 USB MIL 188-141A 2-way LQA exchange w/NX10 (20May17) (AAI)
07899.0: NX40: Unid (presumed Algerian Mil.) 1247 USB MIL 188-141A LQA Request Response to XS62 (21May17) (AAI)
07899.0: XS54: Algerian Military, ALG 1556 USB MIL 188-141A LQA Request Response to NX40 (20May17) (AAI)
07937.0: EVW: Unid 1508 USB MIL 188-141A handshake w/TJ4 (20May17) (AAI)
07945.5: ANOUAL2: Moroccan Military, MRC 2018 USB MIL 188-141A sounding (17May17) (AAI)
07964.0: ZM60: Unid (presumed Algerian Mil.) 1519 USB MIL 188-141A LQA Request Response to NX50 (20May17) (AAI)
07964.0: ZM60: Unid (presumed Algerian Mil.) 1519 USB MIL 188-141A LQA Request Response to ZM40 (20May17) (AAI)
07964.0: ZM64: Unid (presumed Algerian Mil.) 1530 USB MIL 188-141A LQA Request Response to NX50 (20May17) (AAI)
08020.0: 88: Italian Air Force C-27J Spartan "MM62214 46-88", I  0914 USB MIL 188-141A call CHARLY46 (22May17) (AAI)
08023.0: BX80: Unid 0739 USB MIL 188-141A LQA Request Response to NX80 (20May17) (AAI)
08023.0: FQ71: Unid 0813 USB MIL 188-141A LQA Request Response to NX80 (20May17) (AAI)
08034.0: ---: Unid 0808 3G-HF 2-way FLSU handshake followed by Circuit Mode service using MIL 188-110A Serial (20May17) (AAI)
08061.0: RK37: Unid (presumed Algerian Mil.) 1551 USB MIL 188-141A LQA Request Response to NX30 (20May17) (AAI)
08162.0: 035: Ungarian Military, HNG 1514 USB MIL 188-141A LQA Request Response to 093 (20May17) (AAI)
08190.0: CAVATORTO: Italian GdF patrol boat, I 0723 USB MIL 188-141A call to BARBARISI (17May17) (AAI)
08195.0: 1PY: Roumenian Police, ROU 0729 USB MIL 188-141A 2-way LQA exchange with SIB Sibiu (22May17) (AAI)
08582.0: P52: Moroccan Military, MRC 2048 USB MIL 188-141A sounding (17May17) (AAI)
08582.0: X42: Moroccan Military, MRC 2048 USB MIL 188-141A sounding (17May17) (AAI)
09044.0: ---: Unid, prob. Russian Mil/Diplo 1257 (cf) FSK 300Bd/500 360-bit ACF (18May17) (AAI)
09274.0: ---: Unid 1155 (cf) RACAL MA4248 "MEROD" FSK 266.7Bd/800 bursts, call to @VW96G61B (15May17) (AAI)
10225.5: ---: Unid 0929 USB Unid QPSK 2400Bd burst system, 180-bit ACF (modified Stanag-4539 TDMA?) (23May17) (AAI)
10425.0: ---: (no call) Unid 0714 USB MIL 188-141A LQA Request Response to 1VR (20May17) (AAI)
10853.5: XCF: Unid UK-DHFCS node, UK 1318 USB MIL 188-141A call to XSS (18May17) (AAI)
10935.5: ---: Unid 0921 USB MIL 188-141A Linking Protection mode handshake followed by MIL 188-110A Serial modem (23May17) (AAI)
11032.0: ---: Unid (presumed Bulgarian Diplo) 0830 USB RFSM-8000 with data-masking (22May17) (AAI)
11050.0: ND1: Unid 1457 USB MIL 188-141A handshake w/SK1 followed by MIL 188-110A Serial (19May17) (AAI)
11165.0: AOS: Algerian Air Force Ain Oussera, ALG 0802 USB MIL 188-141A call CM1 (22May17) (AAI)
11430.0: ZRO: NATO NCS 0809 USB MIL 188-141A call STM (23May17) (AAI)
11430.0: ZRO: NATO NCS 0828 USB MIL 188-141A call ACR (23May17) (AAI)
11543.0: ---: Unid 0751 USB 3G-HF 2-way FLSU handshake followed by HDL+ (22May17) (AAI)
13110.0: ---: Unid, prob. Russian Mil/Diplo 1330 (cf) FSK 300Bd/500 360-bit ACF (18May17) (AAI)
13560.0: ---: Russian Navy, RUS 0739 (cf) CIS Navy "Akula", FSK 500Bd/1000 (23May17) (AAI)
15040.0: 240: Unid 1342 USB MIL 188-141A sounding (18May17) (AAI)
15858.0: MHFCS network, AUS 1350 ISB, GFSK 600Bd/340 on LSB & FSK 50Bd/340 on USB (17May17) (AAI)
17409.5: ---: Uk Mil/Gov, UK 0728 USB WINDRM modified waveform OFDM 51-tone (23May17) (AAI)


3G link + S5066: example of Circuit Mode (HF2000, Swedish Army)

$
0
0
Nice example of how to send STANAG-5066 data on a 3G link, using the Circuit Mode service provided by the 3G-HF STANAG-4538 profile.
The link is established with the 2-way FLSU procedure: the FLSU_Request PDU (BW5) sent by the caller station specifies the traffic waveforms that will be used during circuit mode, in this case MIL 188-110 (also termed MS110), and it is followed by an FLSU_Confirm PDU by the called station (not heard at my side). Once circuit mode begins, any station can initiate transmissions using the specified traffic waveform. A CSMA/CA process is used to avoid collisions. After the transfer is completed, an FLSU_Term PDU is sent by the caller and the link is terminated (Fig. 1).

Fig. 1
The most interesting aspect is the use of STANAG-5066, which has been detected thanks to the lack of the encryption before the MS110 modem: indeed, STANAG-5066 allows to indentify the Authority/Country by the addresses coded into the Data PDU (D_PDU), unless dummy addresses are used:

Once removed the overhead bits added by MS110, the D_PDUs can be isolated by syncing the resulting bitstream with the sequence 0xEB90 (regardless of type, all the D_PDUs begin with the same sync sequence): the result is displayed in Figure 2.

Fig. 2
The Size-of-Address Field specifies the number of bytes in which the source and destination address are encoded, the address field may be from 1 to 7 bytes in length (as in this case), with the source and destination address of equal length.The first half is the destination address and the second half is the source address:

In this case:
source address: 006.046.000.028
destination address: 006.046.001.010
both belonging to the block 6.46.x.y allocated to Sweden (Table N-6 European National Addressing Schema):

Fig. 3
Almost surely it is the HF2000 System developed by the Italian "Marconi Selex" company:

The user data carried by D_PDUs are structured in a 8-bit code (Fig. 4):

Fig. 4
By the way, the transmission has been copied on 10590.5 KHz/USB and thanks to S5066 Addresses this is the firts time I identify a 3G-HF transmission.



CIS Makhovik ("The flywheel") before CIS-12

$
0
0

CIS Makhovik ("The flywheel") is classified as "vocoder" but can be used also for sending encrypted data. It was originally designed to operate in the UHF but very often is found on the HF as a waveform of the AT-3004D/AT-3104D modem. In this ample (Figure 1) is possible to see the switch from the flywheel to CIS-12 waveform. The flywheel modulation can be QPSK, MSK, and PSK-2 as in this sample (speed is 1200 Baud).

Fig. 1
Fig. 1 - 425.8 msec period



unid STANAG-4539 burst ARQ system in multichannel mode

Viewing all 623 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>