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:

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 sent by the caller PU, followed by the (optional) "link termination confirm" sent back by the receive PU; both the FLSU PDUs, the FLSU_TERM, are sent using bust waveform 6 (Fig. 8 ) as specified in STANAG-4538 for HDL+ packets links.
 
Fig. 8


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-ALE 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 (Fig. 1).
Fig. 1
As in the previous post transmission consists of several BW-5 bursts sent multiple times (Fig. 2)

 
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]

Protocol Field
001 = FLSU PDU
Priority
indicates the priority level of the traffic (if any) that the sender of the PDU intends to send on the link once it is established. 0 = highest priority

Destination Address
0000100001 is the address of the PU to which this PDU is being sent

Source Address
0000000100 is address of the PU that is sending this PDU

Address Type
Address type indicates if the 10 bit destination address represents a multicast group or an individual address. In this case 0 = Point-To-Point: destination is an individual address
 
XN (Cross Net)
The XN field indicates that the destination is in the same network as the caller when set to 0. When set to 1, the destination is in a different network
 
PDU type
3 (011) = Asynchronous FLSU_REQUEST
0 (000) = REQUEST 2Way: a “request with acknowledgment”
 
Argument1
in case of PDU type = REQUEST specifies the channel used for traffic. A default value of 63 ("111111") specifies that the current calling channel shall be used for traffic
 
Argument2
in case of PDU type = REQUEST specifies the traffic type, in this case 2 (010) = digital voice
 
CRC
The CRC field contains an 8-bit cyclic redundancy check (CRC) for error detection, computed over the preceding 42 bits of the PDU. The generator polynomial is X8 + X7 + X4 + X3 + X + 1.


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 while in the previous post the payloads' rotation probably caused the 768 bit period.

Fig. 4
Fig. 5


3 January 2017

unusual PDUs carried by STANAG-4538 BW-5 waveform

Some days ago I was reading 3G-HF transmissions on 11430.0 KHz/USB and one of them caught my attention because of its duration, more than 16 seconds (~16208 msec): too long to be an HDL (max 10240 msec for HDL24) or an LDL (max 7198 msec for LDL) transfer.
The Cross Correlation Function in Fig. 1 reveals it consists of 16 frames sent contiguously, each frame has a duration of 1013 msec and consists of 2432 (PSK-8) symbols at 2400Bd speed: although its total duration is misleading, its characteristics match the STANAG-4538 BW-5 burst but transferred 16 times in a row. (Fig. 2).

Fig. 1 - CCF function
Fig. 2
Burst Waveform 5 is used by the fast link setup (FLSU) protocol and its closely associated FTM protocol, which are sometimes referred to together as simply FLSU. Their PDUs are distinguished by the protocol field in the first three bits of the 50-bit paylod: "001" for an FLSU PDU versus "100" for an FTM PDU. After decoding, the expected sixteen 50-bit PDUs are shown in Fig. 3. Curiously, only the last contains a valid 3-bit identifier in the protocol field ("001" = FLSU) while the first fifteen PDUs contain the "000" identifier which makes the carried payload at least unusual if not unknown, at least according to the STANAG-4538 first edition.


The signal has a good quality, no noise or fadings and then its main features are easily obtainable (see the constellation below) so a decoder error appears at least unlikely, even more in the same positions. Moreover, the first 15 PDUs exhibit a sort of altenate patterns which are best visible in Fig. 4 and likely make sense.

Fig. 4
Since the manufacturers of equipments or protocol developers/implementers may modify the standard if it does not impair its performance, perhaps we are dealing with a modification or an extension of the (Async ?) FLSU PDU, since BW-5 waveform is unchanged. But  it's only a my opinion, so comments and hints are welcome!

Since the good quality, I also demodulated the PSK-8 constellation in order to examine the on-the-air symbols and their arrangement. The obtained bitstream has a 768-bit period that makes 256 PSK-8 symbols (Fig. 6). The lenght of the period (256 symbols) is in contrast with the result of 2432 symbols seen above: likely the CCF spikes are synced with the 240 mesc preamble while the lenght of the period could be due to alternation of the payloads and the 16-ary ortogonal Walsh function used in BW-5 waveform for the data format.


Fig. 5
Fig. 6


 https://yadi.sk/d/BhP9ocMt36fCVd