30 January 2017

75bps Baudot encoding with 1.5 stop bits

As in the age of the old-fashioned mechanical teletypes, still today some asynchronous communication systems run at 75 baud using frames consisting of 1 start bit, 5 (Baudot code) data bits, and 1.5 stop bits, i.e. the duration of the stop "signal" is 1.5 times the normal data bit duration. Although a single 7.5 bits length frame is quite easy to see in the time-domain,  its bit-oriented view is impossible at least in the tools at my disposal (unless to aggregate two consecutive frames and then get an integer number of 15 consecutive bits).
This difficulty about the representation of 7.5 bits frames may lead to misinterpretation and erros, as I did it (!) using SA/Bee to analyze what seemed a 150bps/500 Hz FSK burst transmission copied on 16155.0 Khz (cf). Speed was misured using the AM detector tool (Fig. 1)

Fig. 1
and once demodulated, each burst exhibits a 15-bit period (Fig. 2)

Fig. 2

But the ACF tells a different story: the signal  is structured in 7.5 bits lenght frames each consisting of 1 start bit, 5 data bit and 1.5 stop bits and duration of ~100 msec (Fig. 3). This means ITA-2 coding, commonly referred to as Baudot, and a speed of 75 bps!

Fig. 3
As said, the impossibility to represent an "half bit" makes that two consecutive frames are considered and then either the speed and the period are misrepresented!
The transmission can be decoded using a common Baudot decoder and setting the right speed (75bps) and shift (500Hz): it consists of ten groups of 5 figures per burst, as shown in Fig. 4. Removing the five extra-bits (start e stop bits) from the 15-bit period stream we just get the 61 ITA2 5-bit characters of each burst.

Fig. 4
It's worth noting that things are worse trying to force the speed to 75 bps: one bit is lost  (Figs 5,6)

Fig. 5
Fig.6
By the way, the 1.5 bit lenght of the stop signal is derived from the design of early teletype machines, which was designed this way because the electromechanical technology of its day was not precise enough for synchronous operation: thus the systems needed to be re-synchronized at the start of each character while the stop duration gave the system time to recover before the next start signal.
Thanks to Cryptomaster for warning the (gross) error.

26 January 2017

Logs

05402.0: FC6FEM: Usa-FEMA Region 6, US 0759 USB MIL 188-141 2G-ALE sounding (19Jan17) (AAI)
05684.0: JNRNPR: USAF-NIPRnet Salinas, PTR 0807 USB MIL 188-141 2G-ALE sounding (19Jan17) (AAI)
05785.0: AVALLO: Italian Coast Guard patrol boat, I 0838 USB MIL 188-141 2G-ALE calling BURATTI (19Jan17) (AAI)
06550.0: R24504: US Army Helo 0928 USB MIL 188-141 2G-ALE sounding (19Jan17) (AAI)
06801.0: D20: Croatian NPRD Dubrovnik, HRV 0947 USB MIL 188-141 2G-ALE sounding (19Jan17) (AAI)
06806.0: KA31: Algerian Military, ALG 1533 USB MIL 188-141 2G-ALE handshake PY30 followed by MIL 188-110A (18Jan17) (AAI)
06831.0: V08: NPRD Net Velika Mlaka HRV 0917 USB MIL 188-141 2G-ALE sounding (19Jan17) (AAI)
07345.0: ZUG: possible Swiss net 0939 USB MIL 188-141 2G-ALE calling CAMP (19Jan17) (AAI)
07365.0: MNA: Algerian Air Force, ALG USB MIL 188-141 2G-ALE calling CM4 (19Jan17) (AAI)
07813.0: J64: Moroccan Army, MRC 1836 USB MIL 188-141 2G-ALE sounding (20Jan17) (AAI)
07813.0: P53: Moroccan Army, MRC 1838 USB MIL 188-141 2G-ALE sounding (20Jan17) (AAI)
07840.0: SDU: Polish Military, POL 0857 USB MIL 188-141 2G-ALE calling SDL (21Jan17) (AAI)
08083.6: ---: Unid 1840 (cf) Siemens CHX200 F1-modem (CHP-200) FSK 249Bd & 250Bd (20Jan17) (AAI)
08184.0: ---: Unid 1015 USB MIL 188-110A 2400bps test transmissions, preceeded by Spanish op-chat (17Jan17) (AAI)
08453.0: FUG8: French Navy, F 1433 USB STANAG-4285 600bps/L"OO FAAA DE RFFME ZNR UUUUU FUG 8 / 12 / 17 ZUI TESTING" "OO DE ZNR UUUUU RFM TO BT NON PROTEGE QRV BT" (18Jan17) (AAI)
09176.0: JCP: Saudi military, ARS 1835 USB MIL 188-141 2G-ALE calling RFP (23Jan17) (AAI)
09176.0: JCU: Saudi military, ARS 1832 USB MIL 188-141 2G-ALE calling RFU (23Jan17) (AAI)
09200.0: 1112: Moroccan Civil Protection, MRC 1818 USB MIL 188-141 2G-ALE sounding (20Jan17) (AAI)
10713.0: LCR154: Polish Military, POL 1227 USB MIL 188-141 2G-ALE calling SPI324 (17Jan17) (AAI)
10750.0: HQ3: Unid 1223 USB MIL 188-141 2G-ALE calling GANOB16 (17Jan17) (AAI)
11010.0: ---: Unid 0750 USB 3G-HF FLSU followed by HDL+ transmissions (BW6,BW7) (25Jan17) (AAI)
11028.0: CM1: Algerian Air Force Blida, ALG 0928 USB MIL 188-141 2G-ALE handshake COF followed by MIL 188-110A transmissions (25Jan17) (AAI)
11071.0: ---: Unid 1440 USB STANAG-4197 modem, after/before voice comms in Arabic (23Jan17) (AAI)
11091.0: ---: Unid 1503 (cf) R&S FSK 225Bd burst system (16Jan17) (AAI)
11115.0: 216301: Turkish emergency net, TUR 1008 USB MIL 188-141 2G-ALE sounding (26Jan17) (AAI)
11130.0: A201: Moroccan Military, MRC 1018 USB MIL 188-141 2G-ALE calling C3 (26Jan17) (AAI)
11130.0: C3: Moroccan Army, MRC 1045 USB MIL 188-141 2G-ALE sounding (23Jan17) (AAI)
11130.0: J522: Moroccan Military, MRC 1040 USB MIL 188-141 2G-ALE calling J5 (26Jan17) (AAI)
11130.0: MELICE: Moroccan Military, MRC 1011 USB MIL 188-141 2G-ALE calling EM3 (26Jan17) (AAI)
11130.0: O73: Moroccan Military, MRC 1004 USB MIL 188-141 2G-ALE sounding (26Jan17) (AAI)
11135.0: GANOB10: Unid 1440 USB MIL 188-141 2G-ALE calling HQ3, LQA request response (25Jan17) (AAI)
11135.0: HQ3: Unid 1124 USB MIL 188-141 2G-ALE calling GANOB10, LQA request response (25Jan17) (AAI)
11156.0: DJT: Algerian Air Force Djanet, ALG 0834 USB MIL 188-141 2G-ALE handshake CM4 followed by MIL 188-110A transmissions (26Jan17) (AAI)
11156.0: MNA: Algerian Air Force (prob. El Menia), ALG  0813 USB MIL 188-141 2G-ALE calling CM4 (25Jan17) (AAI)
11161.0: ---: Russian Intel/Diplo, RUS 0843 USB CIS-3000 PSK-8 3000Bd followed by MFSK-64 (32+32) 45Bd (25Jan17) (AAI)
11168.6: KWP95OS1: Unid US DoS station 1027 USB MIL 188-141 2G-ALE calling KWP97 (25Jan17) (AAI)
11180.0: R26573: US Army Helo 1413 USB MIL 188-141 2G-ALE sounding (25Jan17) (AAI)
11217.0: MEF: Unid (USAF/RAF aircraft?) 1418 USB MIL 188-141 2G-ALE calling XSS (25Jan17) (AAI)
11217.0: ST1: Unid 1100 USB MIL 188-141 2G-ALE sounding (23Jan17) (AAI)
11217.0: UKE304: RAF E3D awacs 1057 USB MIL 188-141 2G-ALE sounding, call to XSS at 1101 (23Jan17) (AAI)
11226.0: 201067: Unid aircraft 0848 USB MIL 188-141 2G-ALE sounding (23Jan17) (AAI)
11226.0: AKR: prob. RAF Akrotiri Cyprus 0840 USB MIL 188-141 2G-ALE calling 201067 unid aircraft (23Jan17) (AAI)
11235.0: ---: (no call) Italian Air Force, I 0941 USB MIL 188-141 2G-ALE calling 80 (Aircraft?) (26Jan17) (AAI)
11265.0: ---: Unid 1230 USB STANAG-4197 75Bd DQPSK (only the 16-tone part) (25Jan17) (AAI)
11350.0: HQ3: Unid 1146 USB MIL 188-141 2G-ALE calling GANOB3, LQA request response (25Jan17) (AAI)
11350.0: HQ4: Unid 1415 USB MIL 188-141 2G-ALE calling GANOB10, LQA request response (25Jan17) (AAI)
11421.0: ---: Unid 1320 USB Chinese MPSK 4+4 75Bd p/4 DQPSK modem (25Jan17) (AAI)
11430.0: ---: Unid 0910 USB 3G-HF FLSU followed by HDL transmissions (BW1,BW2) (25Jan17) (AAI)
11430.0: 01: Algerian AF, ALG 0838 USB MIL 188-141 2G-ALE calling ESC followed by STANAG-4538 BW3-BW4 waveforms transporting LDL packets, likely tests (23Jan17) (AAI)
11444.0: ---: Unid 1223 USB 3G-HF Asynchronous FLSU REQUEST (24Jan17) (AAI)
11452.0: ---: Russian Intel/Diplo, RUS 1044 USB MFSK-64 (32+32) 45Bd modem (23Jan17) (AAI)
11467.0: ---: Russian Intel/Diplo, RUS 1019 USB CIS-3000 PSK-8 3000Bd followed by MFSK-64 (32+32) 45Bd (25Jan17) (AAI)
11471.0: HMG: Algerian Air Force, ALG 1546 USB MIL 188-141 2G-ALE calling CM3 (22Jan17) (AAI)
11500.0: 2016: Turkish Red Crescent, TUR 1426 USB MIL 188-141 2G-ALE sounding (25Jan17) (AAI)
16329.5: ---: Unid 1140 USB Chinese MPSK 4+4 75Bd p/4 DQPSK modem (21Jan17) (AAI)
16903.0: N61: Unid 1419 USB MIL 188-141 2G-ALE calling A99 (21Jan17) (AAI)
17499.8: ---: Unid 0845 (cf) BPSK 125Bd modem (17Jan17) (AAI)

21 January 2017

ROHDE & SCHWARZ 225Bd FSK burst system


Thanks to my friend cryptomaster from radioscanner.ru for the identification of the signal (it was previously tagged as unid).
 
This transmission, most likely a caller or an ALE system, has been copied on 11092.0 KHz/USB (1Khz offset) at 1503 UTC and consists of repeated series of five FSK bursts each burst with a duration of 680 msec and 2 seconds spaced (at least in this sample). Looking at the spectrogram in Fig. 1, bursts have start and ending tones which last respectively 50 and 100 msec and alternate their value in 957 and 1129 Hz at each transmission unless in the last two bursts where the final tone remain unchanged (Fig. 2): this is probably a characteristic format of the signal.

Fig. 1
Fig.
 
According to the Figs. 3,4  the signal has a transmission rate of 225 bps and 175 Hz shift and in some way it resembles the Kantronics G-TOR standard.

Fig. 3
Fig. 4
 

18 January 2017

Logs


05309.0: ---: Unid 0837 OFDM 39-tone STANAG-4197 messages (03Jan17) (AAI)
05405.0: BX01: Algerian Military, ALG 0656 USB MIL 188-141 2G-ALE calling BX02 (04Jan17) (AAI)
05708.0: JNR: USAF Salinas AFB, PTR 0728 USB MIL 188-141 2G-ALE sounding (04Jan17) (AAI)
05748.6: KWX57: Unid DoS station 0706 USB MIL 188-141 2G-ALE handsahake KWX59 flwd by short voice comms (04Jan17) (AAI)
05792.0: 201: Unid 0713 USB MIL 188-141 2G-ALE sounding (13Jan17) (AAI)
05838.0: ABC7: Croatian Military, HRV 0906 USB MIL 188-141 2G-ALE handshake ABD1 followed by STANAG-4285 1200bps/L transporting STANAG-5066/HMTP off-line encrypted msg (12Jan17) (AAI)
05853.0: 4236: Sonatrach, ALG 0737 USB MIL 188-141 2G-ALE sounding (04Jan17) (AAI)
05880.0: ---: Unid 0825 USB Thales Systeme-3000 ALE call followed by voice scrambler (12Jan17) (AAI)
06203.0: CM1: Unid net 0916 USB MIL 188-141 2G-ALE calling CHL (11Jan17) (AAI)
06205.0: IBIS10: Italian GdF Gaeta, I 0901 J3E/USB radio-check with ROSTRO509 and ORCA10, likely GC units (03Jan17) (AAI)
06262.5: IABC: Italian Navy vessel Galatea, I 1300 J3E/USB calling IDR S.Rosa Rome HQ for radio-check, no reply (11Jan17) (AAI)
06319.0: RAM1SOF1: Iraqi Military, IRQ 1844 USB MIL 188-141 2G-ALE calling RAMADISOF1 (10Jan17) (AAI)
06348.0: FUE: French Navy Brest, F 0754 USB STANAG-4285 600bps/long "FP DE FUE QSL P 050745Z JAN 17 TIME 0754Z KKKKILO" (05Jan17) (AAI)
06424.5: IDR: Italian Navy S.Rosa Roma, I 0847 J3E/USB radio-check with Orale, Bussola, Filone (03Jan17) (AAI)
06450.0: FAIS: Italian GdF patrol boat, I 0839 USB MIL 188-141 2G-ALE calling ANGELINI (12Jan17) (AAI)
06510.0: K1U: Slovakian AF prob. Kuchyna, SVK 0852 USB MIL 188-141 2G-ALE calling Z1V (03Jan17) (AAI)
06715.5: ---: Unid 0852 USB 3G-HF HDL data over BW2 (14Jan17) (AAI)
06840.0: R26308: Sikorsky UH-60L Black Hawk 0817 USB MIL 188-141 2G-ALE 2-way handshake RAPTOR (09Jan17) (AAI)
06905.0: YK02: Algerian Military, ALG 0840 USB MIL 188-141 2G-ALE calling YK01 (06Jan17) (AAI)
06906.0: 5001: Unid net 0841 USB MIL 188-141 2G-ALE sounding (01Jan17) (AAI)
07071.0: 5CIN2D: Unid net (French Navy?) 1332 USB MIL 188-141 2G-ALE calling 5CIN2D (???) (11Jan17) (AAI)
07455.0: RS0016D: RS/CS net 1030 USB MIL 188-110A serial transporting FED-1052 DLP, HARRIS 'Citadel' encryption (16Jan17) (AAI)
08875.0: J62: Moroccan Military, MRC 1008 USB MIL 188-141 2G-ALE sounding (01Jan17) (AAI)
08875.0: S32: Moroccan Military, MRC 1755 USB MIL 188-141 2G-ALE sounding (15Jan17) (AAI)
09025.0: 840187: Unid aircraft 1753 USB MIL 188-141 2G-ALE calling ICZ Sigonella (15Jan17) (AAI)
09183.0: OEB: Algerian Air Force Oum El Bouaghi, ALG 0941 USB MIL 188-141 2G-ALE calling CM5 (11Jan17) (AAI)
09189.0: ---: Unid 0949 USB MIL 188-141 2G-ALE Link Protect call (11Jan17) (AAI)
09199.0: ---: Unid 1148 USB series of FSK 1200Bd/1200 segments 3150 msec duration, ACF=25msec, costant 30-bit sequence, likely in idle state. Sometimes the series are preceeded by Arabic language op-comm (16Jan17) (AAI)
09203.0: ---: Unid 0834 USB MIL 188-141 2G-ALE Link Protected (05Jan17) (AAI)
10142.0: 01: Algerian AF, ALG 0755 USB MIL 188-141 2G-ALE calling BSF (04Jan17) (AAI)
10142.0: 01: Algerian AF, ALG 0759 USB MIL 188-141 2G-ALE calling ESC (04Jan17) (AAI)
10175.0: 66: Unid 1426 USB MIL 188-141 2G-ALE sounding (16Jan17) (AAI)
10345.0: JCU: Saudi Air Force, ARS 1419 USB MIL 188-141 2G-ALE calling RFU (16Jan17) (AAI)
10380.0: HQ3: Unid 1415 USB MIL 188-141 2G-ALE calling GANOB16 (16Jan17) (AAI)
10658.0: 4017: prob. Turkish Red Crescent, TUR 1409 USB MIL 188-141 2G-ALE calling 1020 (15Jan17) (AAI)
10935.0: ---: Ukraine Mil, UKR 1010 USB MFSK-4 (double FSK) 96Bd/500 (tones at -750, -250, +250, +750) (13Jan17) (AAI)
11028.0: 01: Algerian AF, ALG 0809 USB MIL 188-141 2G-ALE calling COF (13Jan17) (AAI)
11028.0: CM6: Algerian AF, ALG 0825 USB MIL 188-141 2G-ALE handshake COF followed by MIL 188-110A (13Jan17) (AAI)
11124.0: 01: Algerian AF, ALG 0756 USB MIL 188-141 2G-ALE calling ESA (13Jan17) (AAI)
11130.0: S33: Moroccan Military, MRC 1455 USB MIL 188-141 2G-ALE sounding (16Jan17) (AAI)
11130.0: S41: Moroccan Military, MRC 0842 USB MIL 188-141 2G-ALE sounding (13Jan17) (AAI)
11196.0: MSX: Unid 1510 USB MIL 188-141 2G-ALE sounding (16Jan17) (AAI)
11235.0: ---: no call, likely Italian AF, I 1031 USB MIL 188-141 2G-ALE calling CHARLY46 Italian AF 46th Air Brigade (11Jan17) (AAI)
11415.0: CENTR2: MFA Bucuresti, ROU 0806 USB MIL 188-141 2G-ALE calling YPM25 (13Jan17) (AAI)
11430.0: ---: Unid 1408 USB 3G-HF LDL protocol over BW3 transporting Harris 'Citadel' off-line encrypted data (11Jan17) (AAI)
11472.0: 001NET2: Unid 1454  USB MIL 188-141 2G-ALE calling 020NET2 CMD LQA REQUEST RESPONSE (16Jan17) (AAI)
11473.0: 01: Algerian AF, ALG 0741 USB MIL 188-141 2G-ALE calling BSF (13Jan17) (AAI)
11473.0: 01: Algerian AF, ALG 0800 USB MIL 188-141 2G-ALE calling ESC (13Jan17) (AAI)
11481.5: ---: Unid 0847 THALES Systeme-3000 handshake followed by THALES TRC-17xx HF modem PSK-8 24400Bd (13Jan17) (AAI)
12115.0: RHI: Saudi Air Force, ARS 0850 DSB MIL 188-141 2G-ALE calling AAI (09Jan17) (AAI)
12121.0: Russian Military, RUS 0840 USB CIS-112, OFDM 112-tone 22.22Bd BPSK modedm (09Jan17) (AAI)
12164.0: ---: Russian Mil, RUS 1024 CIS-45, OFDM 45-tone 33.33Bd BPSK HDR v1 modem (11Jan17) (AAI)
12173.0: ---: Russian Intel, RUS 0840 USB CIS FTM-4, MFSK-4 150Bd (effective 37.5:Bd) 4000Hz modem (tones at: -6, -2, +2, +6 KHz) (09Jan17) (AAI)
14686.0: ---: Russian Intel/Diplo, RUS 0925 (cf) MFSK-64 45Bd + QPSK 2400Bd 10KHz wide-band inserts (09Jan17) (AAI)
15602.0: ---: Unid Russian Military, RUS 0805 USB CIS-3000, 3000Bd PSK-8 serial modem (12Jan17) (AAI)
16214.0: ---: Russian Mil, RUS 1045 CIS-45, OFDM 45-tone 33.33Bd BPSK HDR v1 modem (11Jan17) (AAI)

16 January 2017

PM-SA, the Poor Man Spectrum Analyzer

This is a workaround to get a spectrum-analyzer tool for people like me who run 32-bit PC (real spectrum-analyzer need 64-bit systems).

The idea is to capture and store the SDR spectrograms (the waterfall) at fixed time intervals while the SDR is recording. When the recording time is elapsed, you may browse the saved screenshots and once you detect a certain signal you can access directly to it through the I/Q recording using the timestamp of that signal (which is printed in the waterfall). My test are with SDR-Console v2.3 and 20/20 v2.2 software, the latter is the programmable screen-capture tool.

setting the 20/20 v2.2 software

First of all, 20/20 v2.2 need to be executed as windows-95 compatible (Fig. 1)

Fig. 1
 
Run 20/20 v2.2 and hit files-> preferences to set the output directory and file, auto save, image format, and auto-increment as in Fig. 2 then set the capture-parameters paying attention to the Timed Options, Capture Target and Capture To (Fig. 3).

The most important value is the Timed Options: the Time Capure shall match the time needed to fill the SDR waterfall (better few second less so to get a little overlapping between two consecutive captures). In my case I preferred 60 seconds and then I will have 60 screen-shots/hour. Hit Ok and 20/20 starts.

Fig. 2
Fig. 3
setting the SDR software (SDR-Console v2.3)

The most important settings are intended to adjust the waterfall speed and height. In my opinion, 10 lines/second is the better resolution value, allowing to fit the waterfall in about 60 seconds (Fig. 4). Remeber that the time needed to fit the waterfall shall match the Time Capture value in Fig. 3! Note also that you have to set Add timestamp option in SDR-Console (Figs 5).

Fig. 4
Fig. 5
Once found the best values and window heigth, you may start the recorder after setting the duration of the recording (Fig. 6).

Fig. 6
Now you may go for a walk or at your job, stay with your partner, have a fresh beer or simply go to sleep: 20/20 & SDR recorder will do the job for you, once recording finished you will have the chance to analyze the stored waterfall screen-shots.



Analyzing the spectrum

Remember to stop 20/20: it run in background, saving screen-shots at the scheduled time. Browse the directory where 20/20 stores the screen-shots, as indicated in Auto Save (Fig. 1), you will see something like Fig. 7

Fig. 7
Images can be seen one at time, back or foward, using the Windows images viewer or some other similar tool. This way you may carefully examine every single “capture” using also the zoomer. At the same time, run SDR-Console and playback the recordered I/Q file (Fig. 8) keeping it paused. Minimize the SDR-Console window.

Fig. 8
When you see an interesting signal (unknown or maybe known by its shape) in a certain stored screen-shot, you have to write down the related timestamp and go to the SDR-Console window. Now, working with the playback navigator you have simply to access to the time slot which is related to the seen signal and play it, i.e. as shown in Figs. 9,11 (the being analyzed screen-shots) and 10,12 (playing the needed time slots from the I/Q file). Pay attention to the different time-format in the captured screen-shots and I/Q file!

Fig. 9
Fig. 10
Fig. 11
Fig. 12
20/20 v2.2 can be downloaded from:

(googling for it ...you may turn up an XXX site).


12 January 2017

STANAG-4538, HDL+ transmissions on a bidirectional link



According to the different signals strength, two radio stations (also termed Partecipating Units, PUs, in STANAG-4538) alternatively forward their data on the same channel with a fixed interval of about 7.5 sec, while ARQ acknowledgements flow in the reverse direction of data.  These half-duplex transmissions have been copied on 6973.5 KHz at 1300 UTC, since the schema used by the stations it could be probably a test.
Unless the two initial BW5 exchanges which convey fast link setup PDUs (Fig. 1), all the protocol data units (PDUs) are sent using the BW6 and BW7 waveforms.

Fig. 1
Actually the transmission of the PDUs (either data, control and management packets)  is performed using the sequence BW6, BW6, BW7, BW6, BW6 which - as seen - is repeated each ~7.5 seconds (Fig. 2)

Fig. 2
The role of the two BW6 bursts that initiate each sequence could be misleading but it's important to note that "[...] if a link has been established for delivery of packet traffic using the HDL+ data link protocol, all FTM and FLSU PDUs transmitted for the remaining duration of the packet link shall be transmitted using the BW6 burst waveform, up to and including the FLSU_TERM PDU transmitted to terminate the link, and any optional response to the FLSU_TERM" (STANAG 4538 Annex C Edition 1, Amendment 2, Draft 03). 
This means that BW6, other than the DHDR (BW7 header), ACK, and EOT (EOM) PDUs of the HDL+ protocol, is also used to convey PDUs of the fast link setup (FLSU) and fast traffic management (FTM) protocols in HDL+ links! Since FLSU and FTM PDUs generally use a 50-bit structure (BW5), when in conjunction with HDL+ they will use the 51st bit of BW6 as an additional CRC bit.



That said, the HDL+ sessions can be read as in Fig. 3. Each change of data flow is preceeded by two TM handshake that synchronizes the PUs

Fig. 3
The two ending BW6 bursts of each sequence, as usual, signal the end of the data transfer. When the sending PU receives an HACK PDU indicating that the entire contents of the datagram have been delivered successfully, it sends one or more (up to four) EOT PDUs, starting at the time at which it would have otherwise transmitted the next data PDU, to indicate to the receiving PU that the data transfer will be terminated.

Since in HDL+ the ACK/EOT PDUs and the FLSU/FTM PDUs use the same 51-bit burst wavefom 6, they will have the same on-air duration, 386.67 msec, and the same number of on-air symbols, ie 544 PSK-8 symbols or 1632 bit after removed the initial TLC/AGC guard sequence of 192 symbols (Fig. 4).

Fig. 4 - BW6 544 on-air symbols

For what concerns the data exchanged between the two PUs, the HDL+ protocol sends its datagrams using a forward transmission composed of two PDUs: an HDL+ data header PDU, which is transmitted using the BW6 burst waveform, and an HDL+ data PDU, transmitted using the BW7 burst waveform. These two PDUs are transmitted contiguously with no dead time separating them. No initial synchronization preamble is required, since this role is filled by the BW6 burst waveform.
The payload section is used to convey between one and fifteen (inclusive) packets of payload data Each packet is conveyed by a sequence ofunknown/known (“UK”) frames. The number of UK frames (Figs. 5a, 5b) used to convey each payload data packet depends on the signal constellation, the code rate, and the packet payload size.

Fig. 5a - four UK frames

Fig. 5b - two UK frames
According to the table of Fig. 6, the modulation used in BW7 bursts is QAM-64 since there are 4 or 2 UK frames in the HDL+ payloads (if it was PSK-8 we would have seen the heigth harmonic in Fig. 7).

Fig. 6
Fig. 7
Link is disconnected by the FLSU "link termination" PDU followed by the (optional) "link termination confirm"; both the FLSU PDUs, the FLSU_TERM, are sent using bust BW6 waveform as specified in STANAG-4538 for HDL+ packets links.

I want to thanks my friends KarapuZ who recordered the signal and Marco for sending me the STANAG-4538 Annex C Amendment.


5 January 2017

STANAG-4538: an example of a 3G-ALE Asynchronous FLSU call

This recording is a real-world example of a 3G-HF FLSU (Fast Link Setup) asynchronous call copied on 15062 KHz/USB: although in 3G networks synchronous calls is the preferred mode, async call might be used if the called (or the caller) station may not have achieved net synchronisation. 
The async call of the fast link setup protocol begins with the LBT (listen before transmit) for at least one dwell period, followed by the transmission of 1.35N (nearest integer value) Async Request PDUs on the requested link frequency, where N is the number of channels in the scan list, and 1.35 is the duration of each dwell period in seconds. The async call  procedure ends with a single LFSU Request PDU (Fig. 1).

Fig. 1
The transmission copied on 15062 KHz/USB consists of several BW5 bursts (PDU_Request PDUs) sent multiple times (Fig. 2) followed by a single BW5 burst. Just the ending BW5 burst (FLSU_Term PDU) leads to think to a "1-way Async LQA Sound" scenario because a failed call will end with a xDL_EOM PDU (BW1 or BW4 bursts).

 
Fig. 2
Looking at the 50-bit payloads in Fig. 3, the PDU of type "011" is sent 13 times, followed by a single PDU of type "000": since PDU type "011" identifies the Async_FLSU_Req PDU, and "000" the FLSU_Request PDU, the sample exactly matches the async call procedure as illustrated above. It's worth noting that since there are 13 Async_ FLSU_Request PDUs, the number of the channels for this network is equal to 9.

Fig. 3
Quoting from STANAG-4538 "Transmitting 1.35N Async_FLSU_Request PDUs guarantees that all other scanning stations will scan the calling channel during the async call, even under the worstcase time of day (current time) offset conditions. If the time of day offset can be estimated more accurately, fewer than 1.35N Async_FLSU_Request PDUs may be sent to capture the desired station.
Since the address of the called station(s) is contained in the Async_FLSU_Req PDU, all stations that are not included in the call are free to resume scanning. Called station(s) that receive one of the asynchronous FLSU PDUs stop scanning and wait for the normal FLSU_Request PDU, which is sent immediately after the final Async_FLSU_Request PDU. The maximum wait duration is approximately equal to 1.35(N + 1) seconds, where N is the number of frequencies in the scan list". 

STANAG-4538 5.3 Annex C "Protocol data units" helps to parse the call:


001 00 0000100001 0000000100 0 0 011 111111 000010 10011000  [A
sync_FLSU_Req]
001 00 0000100001 0000000100 0 0 000 111111 000010 00001110  [FLSU_Request]

As a finale note, it's interesting to see in Fig. 5 that the on-the-air symbols of the async call have a 7296 bit length period, ie exactly 2432 PSK-8 symbols, just because of the (nearly) uniformity of the payloads.

Fig. 4
Fig. 5

In this recording, LP feature (Link Protecting) seems entirely disabled then PDUs are sent over the air unscrambled.