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
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

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).

A better tool for screen capture is "autoscreen" (Fig. 13)

Fig. 13
You can download the software from:

ake screenshots automatically while you work and play! You can either use the interface or run it from a command line. The application ("autoscreen.exe") is a self-contained executable (which means there's no installation required) and sits in the system tray while it takes screenshots in the background without prompts or annoying pop-up messages.
The executable is only 209 KB in size so it can fit on a small (or a very old) USB thumb drive.
You can schedule to have screenshots taken every hour, minute, second, or millisecond. You can also specify what days the scheduled screenshots should be taken. The calendar enables you to see what days screenshots were taken. Remeber to un-check the "demo-mode" box !

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
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 (example of Async call with Link Protecting enabled).