Harris' 3G-ALE FLSU Async call (2)

Commenting the recent post about the Harris's implementation of the FLSU Async call [1], an anonymous reader sent me a good quality recording of that signal. Observing the spectrum/time FFT of figure 1 the call has a duration of about 9 seconds (9170 ms) and, according to the value of the ACF , it consists of 10 BW5 frames. By calculating the respective durations and taking into account the omission of the TLC sections exceeding the first, we get

1013.33 + (9 × 906.66) = 9173.27 ms

ie a value that matches the duration of the call and confirms the FLSU Async call implementation adopted by Harris (by the way, a 7-channel scan list in this sample).

Fig. 1

In addition to the time based approach, in order to verify the above results I tried a tribit symbols based analysis of the demodulated bitstream. Indeed, as per STANAG-4538 (and 188-141B too) the TLC section (256 pseudo-random tribit symbols) and BW5 preamble sequence (576 tribit symbols) are modulated directly without undergoing the PN spreading thus their patterns are easily identifiable within the bitstream. A good way to bring out the two desired sequences is to use synchronization of the bitstream:

a) synchronizing on the preamble sequence
10 rows come out, which therefore correspond to the preambles of the 10 BW5 PDUs (don't fall into the 4-bit HEX trap: since the PSK8 modulation, the symbols we are looking consist of tribit values, ie 4,4,7,3,... = 100, 100, 111, 011,...):

Fig. 2

b) synchronizing on the TLC sequence
as expected, the result consists of only 1 row which is just the one relating to the "entire" first BW5 PDU:

Fig. 3

As a further confirmation, I synchronized the stream on the "border" of the two sequences getting a single row result:

Fig. 4

So, in my opinion, both approaches demonstrate the composition of the FLSU Async call which is implemented by Harris: ie, the TLC section is sent only in the firts BW5 PDU (as per 188-141B #C.5.2.4.5.2):

 

Looking at the bitstream, it's also  evident that this network uses the Linking Protection (LP) procedure [2]. As per STANG-4538 #9.3.2 "Scanning call PDUs shall be scrambled using alternating word numbers 00000000 and 00000001. The word number used in scrambling the first scanning call PDU shall be selected so that the scanning call PDU sent immediately before the Call PDU is scrambled using word number = 00000001. The Call PDU that concludes an asynchronous-mode call shall be scrambled using word number = 00000010": that's the reason of the alternating patterns of figure 5.

 

Fig. 5

By the way, it's worth noting that LP does not address jamming or similar techniques, which are best countered by TRANSEC, nor is it intended to replace the COMSEC function of traffic protection: indeed, LP protects the linking function, including related addressing and control information.

 

A recent monitoring of 6.9 MHz band by my friend ANgazu (who I thanks for sending some recordings) shows the use of the same async call also in WBALE & WHARQ scenarios:

 

Fig. 6

 

https://disk.yandex.com/d/JCbCPlmTV_wl1g (Harris Async call)

https://disk.yandex.com/d/IQe71tmy0VIA3g  (WBALE & WHARQ)

[1] https://i56578-swl.blogspot.com/2022/10/harris-3g-ale-flsu-async-call.html
[2] https://i56578-swl.blogspot.com/2017/02/stanag-4538-3g-ale-flsu-calls-with.html

Harris' 3G-ALE FLSU Async call: a 141B/STANAG-4538 optimised implementation?

I recently had the chance to study some good quality recordings of (certified) Harris 3G-ALE Asynchronous calls and surprisingly I found some features of implementation derived from the now superseded 188-141B that are not defined - or even not supported - by the relevant standard STANAG-4538.

More than once I came across such type of "long duration" FLSU bursts and so far I have always identified them as FLSU Asynchronous calls (STANAG-4538) [1][2] ...but this time it is not like that. What doesn't fit is that while each burst 2-4-6 consists of a single FLSU BW5 PDU (Protocol Data Unit), as expected, also the bursts 1-3-5, although of longer duration, seem apparently formed of single FLSU BW5 PDUs (figure 1).

Fig. 1 - Harris 3G-ALE bursts

A short recap for background... 

As per STANAG-4538 #5.1.3, the Asynchronous call consists of a "sequence" of FLSU PDUs sent consecutively, more precisely:
"The Asynchronous call begins with the LBT [...] followed by the transmission of about 1.35N Async FLSU_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 (in seconds) [...] the sequences of the Async FLSU_Requests (Type-3 PDU) is then terminated by one normal FLSU_Request (Type-0 PDU)"(1):

Fig. 2 - Asynchronous FLSU call (1) (FIGURE 5.1.10-4 STANAG-4538)

Therefore, the Async FLSU call is easily reacognizable by the 1013ms "spikes" (ie the duration of the BW5 PDU) resulting from its Cross-Correlation Function. Obviously, the 7296-bit (or 2432-tribit symbols) period of the bitstream matches the PSK8 symbols of the BW5 waveform. Figure 3 shows the CCF and the bitstream of an Async call recording ( the .wav file is in the download list).

Fig. 3 - CCF and bitstream of the FLSU Async call

The 50-bit frames resulting from its demodulation (fortunately Linking Protection was not used) are consistent with the standard protocol. By the way, since the 10 Type-3 PDUs, the scan list consists of 8 channels.

 

That said, let's back to the Harris 3G-ALE recordings.

The Cross-Correlation Function of bursts 1-3-5 shows strong ~906ms spikes instead of the expected 1013ms ones, consequently the demodulated bitstreams have a 6528-bit period length which in turn makes 2176 PSK8 symbols: so, we have  

 

(2432 - 2176) = 256 missing symbols

Fig. 4 - CCF and bitstream of the Harris FLSU Async call

Looking at the BW5 timing, the initial TLC section consists of 256 PSK8 symbols: well, these are exactly the symbols that we are looking for! 

I mean that the TLC section is sent only in the first BW5 PDU thus the following ones are a bit shorter being composed of only the preamble and data sections: hence the (576 + 1600) = 2176 symbol length period and the ~906ms CCF spikes. This "formation" of the Async call also clarifies why my decoder recognizes only the "first" BW5 PDU (figure 1). By the way, the value 

1013.33 + (5 × 906.66) = 5546.63ms 

fits perfectly in Harris recordings.

Fig. 5 - formation of the Harris FLSU Async call

Such a call is exactly described in paragraph C.5.2.4.5.2 of  MIL 188-141B Appendix C:
"The LE_Scanning_Call PDU shall be sent repeatedly to capture scanning receivers [...] During a scanning call, only the first LE_Scanning_Call PDU shall include Ttlc (used for transmitter level control and receiver AGC settling). All succeeding LE_Scanning_Call PDUs and the LE_Call PDU shall omit Ttlc, and include only the BW0 preamble (Tpre) and data (Tdata) portions".(2)(3)

So, we face a STANAG-4538 FLSU Async call (since the use of BW5 waveform) which is 188-141B compliant for what regards its formation (since the omission of  the TLC sections): ie, a sort of  188-141B/STANAG-4538 mixed implementation. Below I have tried to find a satisfactory answer to this "particular" 3G-ALE call.

For simplicity and clarity of exposition, for now on I will refer to:
- "188-141B" as an FLSU Async call with omitted TLC sections (only the firts one is sent);
- "STANAG-4538" as an FLSU Async call w/out the omission of the TLC sections;
the FLSU protocol obviously implies the use of BW5 PDUs.

One could say that, given the nature of the TLC section (basically 256 throwaway symbols), sending it in a sequence of contiguous BW5 PDUs would makes a poor sense... but that's not entirely true. It is possible to verify that, starting from a certain number of channels onwards, the TLC sections act as a "buffer" and, ultimately, allow a successfully link establishment. Indeed, defining "scan time" the interval of time required for scan N-1 channels, linking is successful as long as the scan time does not exceed the duration of the Async call (figure 6).

Fig. 6 - "scan time" Vs Async call duration

Suppose we have a 21 channel network: the worst case that can happen is that a 141B async caller begins a call on the last channel of the scan list (after a successful Listen Before Transmit interval) while the called station has just begun to dwell on the first channel. Let's calculate how many PDUs must be sent in the call:

1.35 × 21 = 28.35 ≅ 28 Async FLSU_Request PDUs + 1 normal FLSU_Request PDU

for a total duration of (including the initial 1350 milliseconds LBT interval):

1350 + 106.66 + (906.66 × 29) = 27749.8 ms.

The called station will employ (20 x 1350) = 27000 ms to come upon channel 21, so it will receive only a portion of  (27750 - 27000) = 750 ms of the Async call: this means that a part of the acquisition preamble of the final FLSU_Request will be lost and presumably the linking attempt will fail or at least will be at risk. Such a problem will not happen in case of a STANAG-4538 async caller, since its call will last:

1350 + (1013.33 × 29) = 30736.57 ms

therefore the called station will receive a quite large portion of about (30736.57 - 27000) = 3736.57 ms of the Async call (ie more than 3 times the duration of a BW5 FLSU PDU).(4)

I plotted the durations of Async calls and scan times versus a scan list of 5 to 30 channels: the results are quite interesting (figure 7). In case of 141B, starting from channel 16 the distance between the duration of the call and the scan time is getting thinner, until it becomes null or even negative. STANAG-4538 implementation instead maintains a quite wide margin (figures 7a). Then I plotted the the difference (async call duration - scan time) referred to the "useful" duration of a BW5 PDU ( 906.66ms, ie preamble + data): say a sort of measure of the "linking useful margin" versus the number of channels. In case of 141B calls, as expected, the linking gets problematic starting from a 16-channel scan list (figure 7b); no problems in case of S4538 calls (figure 7c).

Fig. 7

Well, how many channels can be allocated to a scan list? Looking at the framing of BW5, the "Argument 1" field reserves 6 bit for the channel; excluding the default value ("111111"), 63 values (0...62) remain available. As it was already evident from figure 7, a 141B Async call does not capture the called station in case of such a large number of channels but - conversely - it's best performing then STANAG-4538 in a network with a smaller scan set (number of channels < 17) just because it has a shorter call duration and therefore a faster linking time (figure 8).

Fig. 8

Probably the Harris' choice of omitting the exceeding TLCs just lies in the fact of better performance in small scan lists (say an "optimised" implementation): perhaps a specific algorithm chooses whether or not to omit the TLCs exceeding the first, or perhaps it's a manual setting. That solution is anyway not compatible with the 188-141B implementation (BW5 is unknown to that standard) and probably also with a "strict" implementation of STANAG-4538: the unanswered calls in figure 1 could be a sign of interoperabilty problems (5), who knows. Judging by the behavior of my decoder, however, I verified that in case of a "late entry" the decoding is successfully only when the Async call contains multiple TLCs: but it's just a decoder, I don't know the algorithm it uses and doesn't matter. Unfortunately I don't have a military grade STANAG-4538 appliance to test its responses, so further analysis are needed to confirm my guess.

I want to thank my friend ANgazu who helped in the analysis and identification of the signal and sent me some recordings of these "mixed" Async calls that he heard just some days ago around 6950 KHz: sign that this solution is still in use today.

https://disk.yandex.com/d/xbGLZvU5y5A1Qg 188-141B FLSU Async call (single TLC)
https://disk.yandex.com/d/gXsMejYAvHFstA   S4538 FLSU Async call (multiple TLCs)
(regarding the Harris recordings, the author prefers that I keep this material confidential)

Some ending comments:

a) I played Lego ® bricks with the burst #1 of the Harris recordings. Using the great tool Audacity ® [3] First I isolated and removed the TLC section of the first BW5, then I did my best by cutting the burst into segments each of 906.66 ms duration. Then I assembled a new burst by inserting the TLC section before each segment and putting it all together. The result confirms the expectations, apart from two error PDUs due to the approximate way of the cut & paste. By the way, five scanning PDUs mean 4 channels in the scan list.

b) You've probably noticed the possibility of a 768-bit/256-symbol period in figure 4:

 

As per STANAG.4538 #13.9.6, the BW5 PDU data symbols are PN-spread using a spreading sequence which is repeated every 4 blocks of 64 tribit sequences, ie every (64×4) = 256 symbols: these repetitions cause the 106.66ms ACF and hence the 256-symbol periodicity:

 By the way, yet another 106.66ms ACF...

(1) Transmitting 1.35N Async FLSU_Request PDUs guarantees that all other scanning PUs (Partecipating Units, ie the other nodes in the HF network) will scan the calling channel during the Async call, even under the worst case time of day 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 PU. Since the address of the called PU(s) is contained in the Async FLSU_Req PDU, all PUs that are not included in the call are free to resume scanning. Called PU(s) that receive one of the Async FLSU PDU’s stop scanning and wait for the normal FLSU_Request.

(2) MIL 188-141B refers to BW0 as the waveform to convey "LE_Scanning_Call PDU" and "LE_Call PDU" (LE stands for Link Establishment): FLSU, and consequently the BW5 waveform, were not yet defined at that time. 

(3) 188-141B (released on March 1999!) was superseded by 188-141C (December 2011), in its turn superseded by 188-141D (December 2017): the last two standards no longer have the Appendix C but only some short paragraphs, among them the #C.6 says "The specifications previously contained in this appendix have been replaced with reference to the essentially identical NATO STANAG 4538".

(4) The Called station 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. After receiving a valid FLSU_Request PDU, the addressed stations responds normally with the FLSU_Confirm PDU (STANAG-4538 #5.1.3)

(5) The BW5 bursts 2-4-6 of figure 1 may convey the FLSU_Terminate link PDU (type-2) which is sent by the caller station in case of link failure (STANAG-4538 #5.1.5). Unfortunately, Linking Protection is used so the decoding does not help to indentify the used BW5 types.

[1] https://i56578-swl.blogspot.com/2019/10/async-flsu-followed-by-stanag-4197-3g.html
[2] https://i56578-swl.blogspot.com/2021/04/a-long-and-protected-flsu-async.html
[3] https://www.audacityteam.org/download/

unid 150-300Bd/1000 FSK (150-300Bd/500 same system?)

 
This FSK signal has the same characteristic switch of the modulation speed (150Bd during reversals, 300Bd in traffic mode), but a different shift (~1000Hz instead of ~500Hz), compared to the one seen here (150-300Bd/500Hz FSK). The different speeds are well visible in the 93.33 ms raster in figure 2.  However it must be said that I rounded the value of the shift to the nearest thousand Hz, given that - in some parts and without filtering - the signal can vary from 997 to 1000Hz. By the way, the same rounding was also applied to the measure of the shift  of the similar 150-300Bd/500Hz signal.

Fig. 1

The similarities are not limited only to the FSK parameters but also to the bitstream' formation (figure 2):
* 24-bit length period with the presence of a "phasing" bit (the column of "0s");
* initial sequence generated by the polynomial x^12+x^10+x^9+x^3+1;
* even parity-check on the differential decoded stream. 

Fig. 2

Me and my friend cryptomaster also verified that the bitstream complies the same (8,24) check matrix generated with the polynomial x^7+x^3+x^2+x+1

1 0 1 1 0 0 1 0 1 1 1 1 1 0 0 0   1 0 0 0 0 0 0 0
0 1 0 1 1 0 0 1 0 1 1 1 1 1 0 0   0 1 0 0 0 0 0 0
0 0 1 0 1 1 0 0 1 0 1 1 1 1 1 0   0 0 1 0 0 0 0 0
0 0 0 1 0 1 1 0 0 1 0 1 1 1 1 1   0 0 0 1 0 0 0 0
0 0 1 1 1 0 0 1 1 1 0 1 0 1 1 1   0 0 0 0 1 0 0 0
1 0 1 0 1 1 1 0 0 0 0 1 0 0 1 1   0 0 0 0 0 1 0 0
0 1 1 0 0 1 0 1 1 1 1 1 0 0 0 1   0 0 0 0 0 0 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 1

that detects and fixes the polarity reversal of the ninth column of the bitstream and performs a H(24,16) coding (figure3).

Fig. 3

That said, we think that these two FSK waveforms belong to the same system although user and purposes are still unidentified. Monitoring is quite difficult since - apparently - a scheduling does not seem used (short transmissions have been heard "by chance" on 4535, 6511, and 8084 KHz).

https://disk.yandex.com/d/hYquU1-3wlvKTQ

R&S GM2100/2200 waveforms' preamble and its similarity to Link-11 SLEW

Me and my friend ANgazu from radiofrecuencias.es have recently studied curious, and apparently unid, burst transmissions occurred for about two consecutive days (7-8 Sept, ceased on 9 morning) on 12431 KHz USB. The idea of this post just comes during the analysis of that signal, noting an interesting similarity of its preamble to the one of Link-11 SLEW. The post then retraces those steps: from the analysis of the bitstreams (and recognition of the waveform) up to the in-depth examination of the preamble sequences and their coding.
The used waveform is the quite common and well-known PSK-8 & 2400 Bd occupying a 3 KHz bandwidth. The bursts do not appear synched or following a certain timing pattern, even if the sequence highlighted in the FFT-spectrum/time of figure 1 seems to be used.

Fig. 1

The good quality of the recording (courtesy of ANgazu) allow its demodulation using the PSKn demodulator of SA. The resulting bitstreams have a 480/96 bit length period, corresponding to 160/32 tribit PSK8 symbols (figure 2). Since these are bursts, the initial part is likely to consist of one or more TLC sections used for transmitter level control and receiver AGC settling (1). 

Fig. 2

The most interesting thing is that, after reshaping the bitstream to the 96-bit period, I found a 192-symbol  sequence which is the same as the one used in Link-11 SLEW acquisition preamble (figure 3). Indeed, quoting STANAG-5511 paragraph 10.1.1.1: "[the preamble] consists of a 192 tri-bit known sequence generated from a pseudo random code [...] these symbols are not scrambled and are applied directly to the 8 PSK modulator".

Fig. 3 -  the evident matching between the two 192-symbols sequence (*)

Judging from the preamble, it could be said that the bursts are Interrogation Messages of  Link-11 SLEW... but actually their durations and the structures following the preamble are not the same: indeed, Link-11 bursts have a well defined 45-symbols length header [1] which is not reflected in the analyzed bursts:

Link-11 SLEW waveform structure (Figure B-9, Stanag-5511)

So, a question arises: what other waveform has a 192-symbol length preamble? 

Checking my blog I found a match to the preamble of Rohde & Schwarz proprietary waveforms implemented in their GM2100/2200 HF modem [2] (although the term GM 2100 refers to the physical modem, from now on I will use it to refer to its characteristic waveform).  The framing consists of a 192-symbol sequence preamble followed by one ore more data blocks each consisting of 64-symbols: 48 unknown symbols (coded data) + 16 known symbols (test sequences). The postamble terminates the data blocks and consists of a 64-symbol End Of Message sequence. Except for the presence of an initial TLC section(s), the total length is then a multiple of 64 symbols.

Fig. 4 - GM2100 "signal format" waveform structure

To thoroughly analyze the bitstream under consideration, it's useful to refer to figure 5 that shows the ACF/period of a GM2100 transmission heard some years ago: since the 2400 Baud, the 133.45ms value corresponds to 320-symbol, or 5 data blocks, period:

Fig. 5 - GM2100 133.4 ms ACF

Back to our bistream, after removing initial TLC section(s) and preamble, the remaining bits, once reshaped to a 64-symbol pattern, are consistent with the GM2100 framing of figure 4. Moreover, it's easy to see in figure 6 that the five 16-symbol test sequences are repeated and are "segments" of the longer 80-symbol sequence (*):

 

0 2 7 7 3 5 1 0 1 4 0 5 0 0 0 0
4 1 1 2 1 4 1 5 4 2 7 4 5 1 6 4
5 4 3 7 0 7 6 2 6 2 4 6 7 2 4 7
3 0 3 1 3 5 1 2 5 0 1 7 1 4 6 0
0 5 7 7 2 5 2 7 7 4 7 5 5 0 5 6

The repetition of the five test sequences causes the (48+16)×5=320 symbol length period shown in figure 5.

 

Fig. 6 - GM2100 burst, demodulated bitstream (*)

Thanks to ANgazu, another important confirmation of GM2100 was a 188-141A 2G-ALE handshake (heard in that same frequency) which allowed us to identify the user as the Italian "Guardia di Finanza" (GdF): as it's known, they make a large use of R&S equipments in their onshore/offshore stations. Unfortunately, the handshake was not followed by any data traffic.

After identified the waveform, we agreed that the evident correspondence between the 192-symbol preamble sequences of Link-11 SLEW and GM2100 shall be further investigated anyway!

R&S documentation [2] reports the "autobaud" facility of the GM2100 waveforms: "A great advantage of the transmission method employed by GM2100 is automatic detection of the received signal data rate by means of a code received at the start of reception. This means that the receiving data modem need not be told the data rate of the transmitting modem".
A fairly likely conclusion - in my opinion - is that  R&S - as usual in the practice - use Walsh Orthogonal Modulation sequences in the sync preambles for both syncing and coding data-rate, FEC, interleaver, and modulation used in the following data blocks. 
Walsh Orthogonal Modulation is accomplished by taking each three bits (tribit) symbol and selecting a corresponding 4-fold repeated Walsh sequence, represented as octal characters (0 will be 0, and 1 will be 4); the selected four element Walsh sequence is repeated 8 times to yield a 32-element Walsh sequence used for the sync symbols (Table I)

Table I Channel symbol mapping for sync preamble.

The 32-element sequences of  Table I are then modulo 8 added to the scrambling sequence  7 4 3 0 5 1 5 0 2 2 1 1 5 7 4 3 5 0 2 6 2 1 6 2 0 0 5 0 5 2 6 6 (Table II). The scrambling sequence, from what I could find, is chosen from the long pseudorandom sequence of (2^16 -1) bits generated by the LFSR  x^16+x^15+x^13+x^4+1 [3].

Table II

The receive node, knowing the beginning and duration of each sequence, first "removes" the randomizing sequence from the received signal and then the resulting symbols are determined by the maximum likelihood method. 

So, the reason of the corrispondences shown in figure 3 is that both L-11 SLEW and GM2100 code their preamble by using the same 32-element Walsh randomized sequences (2). Notice that a similar method is also used in the preamble pattern generation of MIL-STD-188-110/FED-STD-1052.
By the way, I processed the recording using two GM2100 decoders but the analysis of  the resulting bitstreams did not reveal the presence of some known protocol, specifically the expected RSX.25 (the R&S implementation of X.25) which constitutes the main payload of these waveforms. The duration of the operations (~2 days), their modality and the lack of "consistent" traffic, lead us think about the execution of some test or training.

Ultimately, the practice of coding preambles using 32-element Walsh randomized sequences can lead to inaccurate conclusions or even false positive IDs, especially when analysis is limited to preambles only.

https://disk.yandex.com/d/Q-XCoIrJ2rbDdQ

(*) A comment about the bitstream of figures 3,6
SA is an amazing signals analyzer but it's not a "waveform decoder", this means that its PSKn demodulator does not sync on knowns sequences. When used on phase keyed signals, SA produces correct info and images (number of phases, angles, modulation speed, carrier frequency, ...) but for the same signal it returns different demodulated streams due to the inevitable phase-offset errors (figure 7). Hence, each output stream should be analyzed separately.

Fig. 7

(1) Existing HF radios were generally not designed with burst waveforms in mind. For example, MIL-STD- 188-141 military radios are allowed 25 ms to reach full transmit power after keying. While the transmitter radio frequency stages are ramping up, the input audio signal level is adjusted by a transmit level control (TLC) loop so that it fully modulates the transmit power. At the receiver, an automatic gain control (AGC) loop must also adjust to a new receive signal. To accommodate these characteristics of existing radios, the 3G burst waveforms begin with a TLC section of “throwaway” 8-ary PSK symbols that are passed through the system while the transmitter’s and receiver ’s level control loops stabilize. (Johnson, Koski, Furman, Jorgenson, "Third Generation and Wideband HF Radio Communications"). 

(2) According to Table II, the sequence of the link-11 SLEW acquisition preamble consists of the symbols 5,7,6,1,4,0 

7 0 3 4 1 1 1 0 2 6 1 5 1 7 0 3 5 4 2 2 6 1 2 2 0 4 5 4 1 2 2 6   5
7 0 7 0 1 1 5 4 2 6 5 1 1 7 4 7 5 4 6 6 6 1 6 6 0 4 1 0 1 2 6 2   7
7 4 7 4 1 5 5 0 2 2 5 5 1 3 4 3 5 0 6 2 6 5 6 2 0 0 1 4 1 6 6 6   6
7 0 3 4 5 5 5 4 2 6 1 5 5 3 4 7 5 4 2 2 2 5 6 6 0 4 5 4 5 6 6 2   1
7 4 3 0 1 5 1 4 2 2 1 1 1 3 0 7 5 0 2 6 6 5 2 6 0 0 5 0 1 6 2 2   4
7 4 3 0 5 1 5 0 2 2 1 1 5 7 4 3 5 0 2 6 2 1 6 2 0 0 5 0 5 2 6 6   0 

[1] https://i56578-swl.blogspot.com/2018/09/link-11-slew-transmission-format.html
[2] https://disk.yandex.com/i/mh2Ev4Bo15Az4Q
[3] https://disk.yandex.com/i/zOmzgHgthPXqMA
[4] https://disk.yandex.com/i/lb5zWmqYic7gBA

coastal HF Radars' embroideries

Interesting and in some way curious recording sent me by my friend "Sigurd from Netherlands". By varying the db level of the spectrum it is possible to see that actually the "embroidery" is composed of 3 distinct sweepers signals distinguishable by their different strengths, at least as they were received at my friend's site (figure 1).

 

Fig. 1 - spectral shapes at different db levels

Measurements of the main parameters, carried out separately on each sweep, return the following values:

A)
bandwidth (sweep width): 100 KHz
sweep repetition time (PRF): 2 Hz, slope: 200 KHz/s (500 msec duration)
mode: FMCW - Frequency Modulated Continuous Wave, down-chirped

B)
bandwidth: 50 KHz
sweep repetition time (PRF): 2 Hz,  slope: 100 KHz/s (500 msec duration)
mode: FMCW, down-chirped

C)
bandwidth: 50 KHz
sweep repetition time (PRF): 2 Hz,  slope: 100 KHz/s (500 msec duration)
mode: FMCW, up-chirped

Fig. 2

Note that although the 3 sweeps have same rate, B and C are characterized by lower slopes: that's is due to their scanning width that is lower than the one of sweep A (50/100 KHz). 

Other than the sweep rate, the signals share the same center frequency value: probably they are in some relationship and belong to the same system/organization. The different signal strengths lead to think of different transmitting sites or the use of phased antenna sets, so that the effective radiation pattern of a certain signal is reinforced in the direction of the used receiver (I also add that I have only 15 seconds of recording available so it is not possible for me to know if and how the signals may vary). Since the observed working frequency (around 13 MHz) has been allocated by the International Telecommunication Union to support the use of coastal High-Frequency Radar [1],  those emissions are most likely sourced by some WERA (WavE RAdar) systems located in North Europe: this type of OTH-SW (Over-The-Horizon Surface Wave) radar can pick up back-scattered signals from ranges of up to 200 km [2].

WERA HF coastal radar system (https://www.researchgate.net/figure/WERA-HF-costal-radar-system_fig1_251860940)

https://disk.yandex.com/d/ENoqrSNtbQ03KQ 

[1] https://www.itu.int/en/ITU-R/terrestrial/fmd/Documents/Res%20612.pdf (ITU Resolution 612 of the 2012 World Radio communication Conference)
[2] https://www.radartutorial.eu/19.kartei/10.weather/karte012.en.html

OFDM-48 and some comments about OFDM analysis with SA

I wanted to further investigate the OFDM-48 signal published a few days ago [1], in particular the "mode" of construction of the signal and consequently the correct PSK modulation used in the channels. Signals Analyzer documentation [2] reports that, according to the method of forming the data channels and pilot tones, it is possible to meet at least three modes of OFDM signals, actually there may be more modes but SA OFDM tool considers the most basic ones:

Mode A:
All channels are formed "as is", including pilot tones. In this case, the pilot tone cannot be chosen arbitrarily, and is assigned from a limited number of suitable candidates. A typical representative of this mode is the WINDRM 51-tone signal.

Mode B:
All channels are configured as potential pilot tones, any channel can be assigned as a pilot. A typical representative of this mode is CIS-12.

Mode C:
Mixed formation type, all channels are formed as they are, according to mode A. But the pilot tone (s) is formed in a special way, according to mode B. In this mode, any channel or channels can be assigned to the pilot . A typical representative is 188-110B-39 tone signal.

In general, it should be noted that mode B is typical for CIS signals and mode C for NATO signals, even if the 16-tone 188-110 App.A signal is formed according to mode B. Of course this is a subdivision that comes from analysis and practice, although it's quite confirmed.  Most likely, in hypothesis, the signals of modes A and C are formed using 2^n dimensional FFT/IFFT algorithms, and signals according to the mode B without these restrictions.

To appreciate their differences, I synthesized two distinct OFDM-48 signals (modes A and B) using the OCG (OFDM Calculator - Generator) tool [3] downloaded from the radioscanner.ru site. The synthesis process requires the calculation of the OFDM parameters ("Calculate") which will then used in the synthesis stage ("Synthese"). The input fields of the "Calculate" tag (see figure 2) must be filled with the appropriate values, among them I chosed the Fmin Fmax values according the bandwidth limits of the original signal after its direct translation (figure 1).

Fig. 1 - direct translation of the original recording

After entered the correct values for FFT_size/2, TonesMin/Max and Fmin/max, the "Calculate" stage returns the relative OFDM parameters (figure 2); it should be noted that the values of SymbolRate and DeltaFreq calculated by the tool correspond exactly to those desired, that is to those obtained at the time from the analysis of the "original" signal (respectively: 50 Baud and 62.5 HZ).

Fig. 2 - computing the OFDM-48 parameters

As said, the values returned by the "Calculate" stage must then be entered in the input fields of the "Sythese" tag to build the desired OFDM signal; values FFT_Size/2 and TonesTotal are the same of the Calculate stage. As shown in figure 3, I synthesized the OFDM-48 signals (MakeOFDM button) according to the A and B modes, both using PSK2 modulation and without pilot tone(s).

Fig. 3 - synthesis of the two OFDM-48 signals

So I went on to analyze the two OFDM signals with the GREAT ADVANTAGE of already knowing their main parameters, especially the "formation" mode and the used modulation (PSK2).
To the facts, if the "mode" used in the analysis match the one used during the formation of the OFDM signal then we will get the actual modulation used in the channels. The following figures 4 and 5 show this evidence: the PSK2 constellation (the modulation actually used in channels) appears only when the "modes" of the analysis and the OFDM formation match; otherwise, the DBPSK constellation appears.

Fig. 4 - analysis of the OFDM-48 PSK2 mode-A signal

Fig. 4 - analysis of the OFDM-48 PSK2 mode-B signal

As proof, I synthesized the same OFDM-48 signal but this time with DBPSK modulation (figures 5 and 6).

Fig. 5

 

Fig. 6 - analysis of the OFDM-48 DBPSK mode-A signal

This means that we can obtain the correct values of the baud rate, spacing and number of channels but if we do not know a priori the used modulation we could face a margin of uncertainty about it. The best way to fix such impasse is to isolate a single channel and analyze it as if it were a normal PSK-n signal but with the foresight to use the differential mode (Diff = 1) when studying its constellation (figures 7,8). However, this is not always possible because it depends on the quality of the recording.

Fig. 7 - OFDM-48 PSK2, single channel verification

Fig. 8 - OFDM-48 DBPSK, single channel verification

 

That done, I tried to trace back to the "native" sampling rate (SR) of the original OFDM-48 signal analyzed in the previous post [1].

(the following comments are from "Analysis OFDM with CP in SA versions 6.2.6.5" [4])
It is well known that in OFDM signals there is a concept called "native sampling frequency" (SR) which has to satisfy some principles:
- SR/Br = x
- SR/Sh = y
where Br is the symbol rate (Baud), Sh is the separation between channels (Hz), and x y are positive integers. The SR frequency has to be a multiple of Br, and its relation to the channel spacing is “native”. On the other hand, we speak of “independence” of the SR frequency and “native” and “non-native” SR frequencies, which must certainly have specific values.

Let's explain this. A given recording has been sampled at a particular rate: we speak of "independence" because that sample frequency does not have to correspond to the "native" frequency. This does not influence or affect the obtaining of the parameters of an OFDM signal, indeed if necessary, the value of SR can be resampled/recalculated as necessary. Since the "native" value of the sample rate is a multiple of both Br and Sh, if we calculate the exact values ​​of Br and Sh, we will have the possibility of estimating a set of SR frequencies SR1, SR2, SR3..., SRn that meet the requirements and in which at least one frequency of them will be the “native” one.

Back to the native SR, if its value is not known but the OFDM signal formation values LU and LG are (1), then the following formula can be used:

SR = (LU + LG) * Br

Well, OCG tool also gives the possibilty to get pairs of LU LG (just "Get LU,LG" tag) according the desidered values of the signal such as channels, shift, and Br. We can choose any LU LG pair but it is better to leave the signal as much as possible as it is, ie without "heavy" resampling and using a pair of values as close as possible to the pair found from the analysis of the original signal [1]. In this case I chose the pair LU = 228  LG = 57 (figure 9), therefore:

SR = (228 + 57) * 50 = 14250 Hz

as you see, the resulting SR frequency is almost the same of the one used when recording the signal.

Fig. 9

The analysis of the signal after its resample at 14250 Hz is shown in figure 10. Since it is assumed to be a CIS signal, and they usually use mode B, it can be said that the modulation used is DBPSK, even if mode A & PSK2 remains equally likely.

Fig. 10 - analysis of the resampled OFDM-48 signal

Without using OCG, a trick to obtain one or more "effective" SR frequencies is to multiply the value of the shift by an positive integer n, ie:

SR = Sh * n  

taking into account the bandwidth occupied by the signal, ie the resulting SR value must be equal to twice the  upper boundary (see Nyquist rate [5]). In this case n would be = 228.

 

(1) the relation between the duration of LG (guard interval) in samples and the duration of LU (length of useful information) in samples gives the factor K (or "Magic K", visible in the OFDM analysis results), since K = LG/LU. Defining a consistent value of K is one of the primary goal/task of the analysis of signals OFDM, knowing this factor it is possible to receive all much more precisely and faster. 

https://disk.yandex.com/d/dCOOJWxO5-EgnA

 

[1] https://i56578-swl.blogspot.com/2022/09/cis-48-calls-ofdm-transfers.html
[2] http://signals.radioscanner.ru/info/item173/
[3] https://disk.yandex.com/d/w6lLMglpFGoHDw
[4] http://signals.radioscanner.ru/info/item284/

[5] https://en.wikipedia.org/wiki/Nyquist_rate

 

other useful links:
- http://signals.radioscanner.ru/info/item241
- http://www.radioscanner.ru/info/article192/