CARB-data formats in CTA, IDR, NSS, PBB and TBB transmissions

As a final stage of my ITA2 tour I wanted to take a look at how CARB (Channel Availability and Receipt Broadcast) data are sent. By the way, CARB transmissions typically consist of clear-text informations on the frequencies available for ship-shore traffic and are used to perform a channel-link before a message could be sent. 

Most stations (CTA, IDR, NSS, TBB) use STANAG-4285 600bps/Long while PBB uses asynchronous FSK 75Bd/850 for its CARBs; all the messages are originated in ITA2 (Baudot) and sent using the 5N1 framing.

Given the use of the 5N1 framing, a sharp 7-bit period bitstream is expected but it happens only in transmissions from IDR and NSS in which the start and stop bits are well identified and with clear-cut outlines (Figure 1)

Fig. 1

whereas in the other cases (CTA,TBB and PBB) bits are mixed up and a strict 5N1 format is impossible to see (Figs 2,3)

Fig. 2

Fig. 3

In TBB transmissions the CARB data are sent within a 75-bit frame, with a variable spacing between the ITA2 characters (spaces consist of 1-value bits). It's just the variable spacing that makes clear 5N1 visualization impossible. To clean up the bitstream and remove the start and stop bits I used the "Del CT" tool provided by the BEE software, "Del CT" can be used to extract a character length of 5,6,7,8 bits (ITA2 and ITA5): in this case I used the "5 bit" setting. The tool searches and removes the framing, returning the initial ITA2 characters of the CARB strings (Fig. 4)

Fig. 4

The same procedure was used for CTA transmissions, in which the CARB frame length is 74 bits (Figure 5).

Fig. 5

Unlike the above, IDR and NSS use a fixed spacing between the characters and this allows the clear 5N1 visualization depicted in Figure 1 (a perfect 7-bit period frame).

Fig. 6

In cases like this it is not necessary to use the "Del CT" tool and the start and stop bits can be removed by hand (figure 7).

Fig. 7

The CARB transmissions from PBB, although they use asynchronous FSK and not the S-4285 waveform, adopt the same way of TBB and CTA: data are sent within a 64-bit frames and with variable spacing between characters. The five ITA2 bits are recovered from the demodulated bitstream by using "Del CT" tool (Figure 8).

Fig. 8

And... don't be fooled by your eyes: bits are sent serially from left to right and row by row!

Fig. 9

DDH7/ DDH9/DDK9 ITA2 FSK and Sorcerer

Following the previous post, I tried the asynchronous FSK decoder of Sorcerer on some 5N1.5 bitstreams transmitted by DWD: precisely DDH7, DDH9 and DDK9. All transmissions are FSK 50Bd/450Hz with 5N1.5 framing, as evidenced by the SA rasters in Figure 1.

 

Fig. 1

I added the generic decoder for synchronous FSK demodulator in order to see and process the bitstreams on which Sorcerer works. As already underlined, bit editors work with an integer number of bits since they can't represent an half bit, so a 5N1.5 bitstream is depicted as 15-bit frame obtained by aggregating two consecutive frames (ie, 7.5 x 2). The raster method of SA allows to detect  the length of 1.5 bit because it works in the time domain. Figure 2 indicates that in all three cases, Sorcerer correctly demodulates the signals.

Fig. 2

Unfortunately the asynchronous FSK decoder for ITA2 does not provide the 5N1.5 framing and therefore there are some uncertainties in the decoding; using 5N2 framing you get gibberish (Figure 3). It's worth noting that in the previous post a similar not-standard framing was correctly decoded by the S-4285 decoder using 5N1 either 5N2 settings.

Fig. 3

In these cases, asynchronous FSK with 1.5 framing, the best choice is Fldigi which provides this non-standard length of the stop bit (Figure 4). 

Fig. 4

French Navy FUE, STANAG-4285 asynchronous ITA2 framing

updated
Looking at milcomm logs in the web, I noted that the STANAG-4285 clear-text test transmissions of the French Navy call "FUE" from Brest are logged with different indications of the ITA2 data-format (here called as "framing"): sometimes 5N1 and sometimes 5N2, as also reported in some youtube video clips [1].
I tuned their 6348.0 KHz/USB frequency and recorded a sample of these transmissions, then I processed the wav file using two S-4285 well known decoders: sorcerer and multiPSK. It is interesting to note that the two programs correctly decode the test messages using both 5N1 and 5N2 framing settings (Figs. 1,2) and this is certainly curious because seven and eight bits are not the same thing.

Fig. 1

 

Fig. 2

Looking at the bit outputs produced by the two decoders, the stream is structured in five bits of data (ITA2 coding, commonly referred to as Baudot) sandwiched between one start bit and two stop bits, ie a 5N2 framing (Fig. 03).

Fig. 3 - sorcerer/multiPSK bitstream output

If the recorded transmission (S-4285 from FUE) were a "pure" 5N1 then things would be different since decoding with the 5N2 setting would produce errors, as in the case of a 5N1 CARB transmission from the Italian Navy IDR (Fig. 4).

 

Fig. 4 - decoding of a pure 5N1 transmission from Italian Navy "IDR"

Then, I tried to process the wav file from FUE using the HARRIS RF-5710A modem, configured for S-4285 600bps/L, connected to Realterm, a serial terminal program [2] (not a decoder!): the DTE port of the modem was in synchronous mode. These tests show that Realterm detects framing errors when the 5N2 setting is used, whilst the reception  is correct when the 5N1 setting is used (Fig. 5): indeed a different result if compared to that seen with sorcerer and multiPSK where the 5N2 setting produces right decodings (Fig. 6).

Fig. 5 - 5710A -> Realterm

Fig. 6 - decoding of the streams from Realterm

So it seems that not 5N1 neither 5N2 are used. By the way, Figure 7 shows some possible ITA2 framing derived from ASCII-bits output of sorcerer.

Fig. 7

That said, it's seems that we face a non-standard framing: 1 start bit, 5 ITA2 data bits, and <1-2> stop bits... or perhaps there is something odd in these decoders. I try a possible explanation.

Sorcerer and MultiPSK, two software modems/decoders, even if they do not provide the exact framing, they are able to recognize this data format by synchronizing their framing window to the incoming stream, say a "dynamic window", so that we get correct decodings using 5N1 or 5N2 settings. Realterm, just an RS-232 terminal, works with "static" framing windows of the UART, which are suited to the standard formats. So, facing this stream it most likely can synchronize using the 5N1 format because in case of 5N2 the UART does not see an integer number of stop bits.

About the graphic representatiosn of the bits in Fig. 7, it is worth saying that the bit editors work with an integer number of bits (they can't represent half bit) and that anyway the bit stream is the result as parsed by the decoder(!) and not the raw stream before the parsing. The 5N1.5 bit view is possible by aggregating two consecutive frames and then get an integer number of 15 consecutive bits (ie 7.5 x 2): as shown in Figure 7, the 15-bit period stream just exhibits 2 start bits and 3 stop bits... as expected for two aggregate 5N1.5 frames. Quoting Utility Planet "ITA2 bit states are based on timing, and they do not correspond to the base-2 places used in binary numerical notation" [3].

I noted the same behavior in a recorded transmission from Fort de France Martinique FUF (downloaded somewhere from the web): in this case I used multiPSK (Fig. 8).

Fig.8

As a final note, the ending message "INT ZBZ" (interrogative ZBZ) in military terms stands as "What is the printing acceptability of my signals ?", or simply "everything is ok with my transmission?" [4].

[1]  https://www.youtube.com/watch?v=8YBJ05aJcnA   

https://www.youtube.com/watch?v=47N4v4LuUec&t=19s

[2]  https://sourceforge.net/projects/realterm/
[3]  http://mt-utility.blogspot.it/2008/04/.../ita2.html

[4]  https://www.pwcares.org/doc/Z-Signals.pdf

https://yadi.sk/d/r8wjIqdt3SjFgN

Logs (06 - 23 Feb, 2018)

04221.0: ---: Unid 1811 USB STANAG-4285 600bps/L waveform, sending KG-84 encrypted msg (06Feb18) (AAI)
05122.0: NCC7: Unid 0936 USB 188-141A, calling FSE2 (23Feb18) (AAI)
05122.0: NCC7: Unid 0936 USB 188-141A, calling FSZ (23Feb18) (AAI)
05371.0: 9A5EX1P: Global ALE HF Network, HRV 1029 USB 188-141A, sounding (23Feb18) (AAI)
05708.0: 500335: Unid (aircraft?) 2153 USB 188-141A Handshake CRO HF-GCS node / short voice-comms / link terminate (23Feb18) (AAI)
05744.5: 43X02: Unid 1005 USB 188-141A, calling 43X01 (23Feb18) (AAI)
05823.0: 1112: Moroccan Directorate General of Civil Protection, MRC 2206 USB 188-141A, sounding (23Feb18) (AAI)
05838.0: O81: Moroccan Military, MRC 2200 USB 188-141A, sounding (23Feb18) (AAI)
05846.0: RDI: Saudi Air Force, ARS 2202 ISB USB 188-141A, calling DAI (23Feb18) (AAI)
06213.0: NR4: Slovakian Military, SVK 1019 USB 188-141A handshake KU1 / short female voice comms / link terminate (20Feb18) (AAI)
06218.2: NSS: NATO Roma S.Rose, I 0808 USB STANAG-4285 600L, 5N1 CARBs "NSS3I(0)/NSS4I(0)/NSS5I(0)/NSS2I(0)/" (20Feb18) (AAI)
06259.0: ---: Unid NATO stn USB 0819 STANAG-4285 600L, KG84 encrypted messages (20Feb18) (AAI)
06283.5: ---: Unid 2237 USB STANAG-4285 600bps/L, sending KG84 encrypted file (22Feb18) (AAI)
06303.0: ---: Unid 2237 USB 3G-HF 2-way FLSU handshake / HDL12 transfer (22Feb18) (AAI)
06348.0: FUE: French Navy Brest, F 2303 USB STANAG-4285 600bps/L Async (prob. 5N1.5) "FT DE FUE MCI BON QUART AR" (22Feb18) (AAI)
06562.0: 122203: Unid 2222 USB 188-141A, sounding (22Feb18) (AAI)
06670.0: CAMP: Unid (prob. Swiss net) 1455 USB 188-141A, handshake HQ / modified 188-110A Serial waveform, (88-bit key?) encrypted data (19Feb18)
06670.0: CAMP: Unid (prob. Swiss net) 1509 USB 188-141A, handshake HORBEN / modified 188-110A Serial waveform, (88-bit key?) encrypted data (19Feb18)
06733.0: DAGA88: 41 Stormo 88 Gruppo Sigonella patrol aircraft Atlantic, I 1405 USB in QSO with IDR Rome (19Feb18) (AAI)
06765.0: CRA: Roumenian MOI/Police (Craiova?), ROU 1111 USB 188-141A LQA exchange w/ 1PY (20Feb18) (AAI)
06795.0: 306013: Turkisk Emergency net Anakara, TUR 1614 USB 188-141A, calling 334013 Istanbul (18Feb18) (AAI)
06821.0: 128: Iraqi Gov. net, IRQ 2228 USB 188-141A, sounding (22Feb18) (AAI)
06850.0: 6005: Unid 2325 USB 188-141A, sounding (22Feb18) (AAI)
06850.0: 6013: Unid 2323 USB 188-141A, sounding (22Feb18) (AAI)
06850.0: 9001: Unid 2319 USB 188-141A, sounding (22Feb18) (AAI)
06850.0: 9004: Unid 2321 USB 188-141A, sounding (22Feb18) (AAI)
06866.0: 128: Iraqi Gov. net, IRQ 2255 USB 188-141A, sounding (22Feb18) (AAI)
06867.0: ABC7: Croatian Military, HRV 0831 USB 188-141A, calling ABD1 (20Feb18) (AAI)
06906.0: 5001: Unid 2251 USB 188-141A, sounding (22Feb18) (AAI)
06909.0: F10: Ukrainian net, UKR 2219 USB 188-141A, sounding (22Feb18) (AAI)
06942.0: 128: Iraqi Gov. net, IRQ 2247 USB 188-141A, sounding (22Feb18) (AAI)
06944.0: JCI: Saudi Air Force, ARS 1711 USB 188-141A, calling RFI (06Feb18) (AAI)
07405.2: ---: Unid 1000 USB STANAG-4285, idling (21Feb18) (AAI)
07584.0: TXFA5: Guardia Civil, E 0911 USB 188-141A, calling TWVB1 (08Feb18) (AAI)
07594.5: OEY20: Austrian Army, AUT 0955 USB 188-141A, calling OEY61 (21Feb18) (AAI)
07596.0: EK9: Greek Military, GRC 1427 USB 188-141A, sounding (20Feb18) (AAI)
07620.0: ---: Chinese Military, CHH 2015 LSB OFDM 30-tone PSK2 burst modem (21Feb18) (AAI)
07635.0: ---: Unid 0827 USB 3G-HF 2-way FLSU handshake / LDL32 transfer, sending 107-byte Harris "Citadel" encrypted file (06Feb18) (AAI)
07692.0: OF7: Moroccan Gendarmerie, MRC 0853 USB 188-141A, calling Z3F (17Feb18) AAI)
07715.0: 250: Chinese Military, CHN 1841 USB 188-141A, sounding (21Feb18) (AAI)
07823.0: ---: Russian Intel/Mil, RUS 1300 USB CIS FTM-4, MFSK-4 150Bd (effective 37.5:Bd) 4000Hz modem (tones at: -6, -2, +2, +6 KHz) 8mins lasting (20Feb18) (AAI)
07840.0: XPU: Unid 0846 USB USB 188-141A, calling 1VR (12Feb18) (AAI)
08022.0: TWBH6: Guardia Civil Huesca, E 0900 USB 188-141A, sounding (17Feb18) AAI)
08055.0: 913001: Mauretanian Gendarmerie, MTN 1834 USB 188-141A, handshake 980035 / voice comms (21Feb18) (AAI)
08058.6: KWS95: US Dept of State station 0910 USB 188-141A, sounding (21Feb18) (AAI)
08071.5: ---: Unid 0819 USB (cf +1500Hz) R&S-ARQ 228.6Bd/170 (aka ALIS), calling address 2191 (21Feb18) (AAI)
08091.0: EHVNET1: Unid (poss. USAREUR, US Army Europe) 1308 USB 188-141A, calling DHCNET1 (06Feb18) (AAI)
08101.0: ---: Unid 1655 (cf) TADIRAN HF voice scrambler (11Feb18) (AAI)
08148.0: ---: Russian Intel exp. 0900 USB MFSK-16 16.66Bd 175Hz, also heard on 11431.0 and 11574.0 at different times  (12Feb18) (AAI)
08148.0: ---: Russian Intel, RUS 0900 USB exp. MFSK-16 16Bd/175 Hz (21Feb18) (AAI)
08190.0: ZANOTTI: Italian GdF patrol boat, I 0919 USB 188-141A, handshake TARANTO / R&S X.25 proprietary waveform (21Feb18) (AAI)
08322.2: ---: Unid 0852 STANG-4285 300bps/L waveform, sending KG-84 encrypted msg (08Feb18) (AAI)
08587.0: ---: Russian Gov/Mil, RUS 0920 USB CIS-60, OFDM 60-tone 30Bd PSK4 waveform, voice comms in Russian (08Feb18) (AAI)
08801.2: ---: Polish Intel, POL 1005 (cf) (new/development) FSK 400Bd/800 waveform (08Feb18) (AAI)
08975.0: 9MP: Unid 0918 USB USB 188-141A, calling 1VR (15Feb18) AAI)
08975.0: 9MP: Unid 0929 USB USB 188-141A, calling CMR / 188-110A Serial (15Feb18) AAI)
08975.0: SRR: Unid 0952 USB USB 188-141A, calling SWF (14Feb18) AAI)
09028.0: GCRR: Spanish Air Force Lanzarote airport, E 1020 USB STANAG-4197 ANDVT modem, voice comms in Spanish (09Feb18) (AAI)
09065.0: ---: Russian Gov/Mil, RUS 0850 (cf) FSK 100Bd/500, encrypted tfc, off 0900 (15Feb18) AAI)
10427.0: ---: Russian Intel, RUS 0910 USB exp. MFSK-16 66Bd/175 Hz (20Feb18) (AAI)
10667.0: HA2: Polish Military, POL 0943 USB 188-141A 2-way LQA exchange w/ TA6 (20Feb18) (AAI)
11158.0: ---: Russian Gov/Mil, RUS 1040 USB CIS-112, OFDM 112-tone 22.22Bd BPSK waveform (07Feb18) (AAI)
11196.0: MSX: Unid 1025 USB 188-141A, sounding (06Feb18) (AAI)
11235.0: ---: no call (prob. Italian AF, I) 1052 USB 188-141A, calling 80 (17Feb18) (AAI)
11235.0: ---: no call (prob. Italian AF, I) 1101 USB 188-141A, calling 59 (17Feb18) (AAI)
11235.0: 45: Italian AF unid asset, I 1045 USB 188-141A, calling RUPE (17Feb18) (AAI)
11403.0: ---: NATO tactical data-link 0940 USB LINK-11 CLEW waveform (aka TADIL-A, OFDM 14-tone 75Bd DQPSK) on single channel (06Feb18) (AAI)
11430.0: ---: Unid 0810 USB 3G-HF 2-way FLSU handshake / HDL+ transfer (15Feb18) AAI)
11458.0: R03: Roumenian MAECT Bucharest #3, ROU 0921 USB 188-141A, calling MOG Athens Embassy (06Feb18) (AAI)
11550.0: ---: Unid 0853 USB THALES Système 3000 robust MFSK-8 (20Feb18) (AAI)

unid 128-bit Initialization Vectors

Interesting (proprietary?) adaptive HF modem spotted on 6670.0 and 7998.5 KHz/USB. The modem uses a waveform set from 188-110A and STANAG-4539 and switches from 300bps up to 4800bps modes with constant modulation rate of 2400 symbols/sec. The data transfer phase follows the 188-141A handshake between the ALE calls:  
- CAMP,OUTPOST (in the sample recorded on 6670.0 Khz)
- HORBEN, CAMP (in the sample recorded on 7798.5 KHz)
(these callsigns are unknown to me, some DXers attribute these callsigns to the Swiss Emergency Network)
Although it is the same network, as can be supposed from the callsigns, it's interesting to note that in the sample recorded on 6670 KHz the 110A waveform exhibits four initial unmodulated tones  at 500, 1200, 1700 and 2600 KHz which are non provided in the standard.

Me and J-4538 investigated the bitstreams after the removal of the overheads due to the bearer HF waveforms and we found the same structure of the sent messages,  no matter 188-110A or 4539!

Fig.1 - the 128-bit period of the secondary protocol

 

a possible transmission frame could be (Fig. 2):
a. frame sync 
b. 5 x 128-bit Initializaction Vectors
c. phasing/idling
d. encrypted data block 

e. ending part consisting of a "1s" "0s" sequence

Fig. 2

https://yadi.sk/d/xS71SjuN3NQjbu (6670.0 KHz)
https://yadi.sk/d/OqKqMjp53TXKHW (7998.5 KHz) 

OFDM 30-tones PSK-2 40Bd

Yet another unid (to me) OFDM transmission spotted by ANgazu on 4 MHz band by using a remote Kiwi SDR in Sweden (SM2BYC).
The waveform uses OFDM technology for 30 channels, 50 Hz spaced, modulation is PSK-2 in each channel with a symbol rate of 40Bd. The occupied bandwidth is about 1500 Hz. Speed and modulation are confirmed by analyzing the whole signal and also a single channel (Figs 1,2). A short preamble consisting of FSK-2 40Bd/320 bursts precedes the OFDM (Fig. 3).

The same signal was spotted by KarapuZ on may 2015, here his post in radioscanner:

http://www.radioscanner.ru/forum/topic39959-92.html#msg1182537

Fig. 1

Fig. 2

Fig. 3

 

https://yadi.sk/d/Luracw3c3SU3K8

OFDM 20 out of 26 tones modem (possibly a Chinese waveform?)

The transmission has been spotted by ANgazu on 4102.0 KHz/USB by using a remote Kiwi SDR in Sweden. The signals consists of 4500 msec bursts, sent contiguously, and occupies a bandwidth of 2000 Hz (Figure 1).

Fig. 1

The waveform uses OFDM technology for 26 channels although 20 of these are used, ie the six tones 5,8,9,13,18,23 are off (at least in this sample). Modulation is PSK-2 in each channel with a symbol rate of 60Bd. Speed and modulation are confirmed by analyzing the whole signal and also a single channel (Figs 2,3).

Fig. 2 - analysis of the full OFDM spectrum

Fig. 3 - analysis of a single OFDM tone

KarapuZ suggets that it's likely a Chinese waveform, in this case the signal should be tuned on LSB. On my side I tried to synthetize a similar waveform although the results obtained (bandwidth and speed) are slightly different as shown in Figure 4.

Fig. 4 -synthetized OFDM 20-of-26 waveform

In another recording I also found bursts with 24 out of 34 tones up and PSK-2 modulation at 50 Bd (Fig. 5) , these short bursts are in between the groups of 20/26 bursts.

Fig. 5

A distinctive feature of the 20/26 waveform is its period that is formed by 14040 bits (Fig. 6): thanks to KarapuZ for the demodulated bitstream.

Fig. 6 - 14040 bits period

07 June 2018 - update
The OFDM has been spotted on 4816 (cf) by AngazU, in this sample they use only one out of two sequences. OFDM Parameters are the same.

https://yadi.sk/d/etaTfAa73SFnKm

unid FSK 400Bd/800 system

Unid FSK system heard around 1005z on 8800 KHz (cf +1200Hz) running at 400 Baud and 800 Hz shift (Figure 1). Unfortunately I went late on the signal so I missed the initial part of the transmission which could have provided more details useful for identification  (at least the encryption, if any).

Running the cross-correlation function, KarapuZ noted spikes at ~4007 msecs (Figure 2) that could mean a period of about 1600-1608 bits length. Hope to catch a complete transfer, but it will not esay.

Fig. 1

➤ update
@Priyom.org sent me an interesting coment on my twitter account, I'm happy to share here in the blog, thanks my friend:
Hi, this 400Bd/800Hz system is likely yet another Polish Intel development. It is obviously different from their ACF=896 FSK's. It sends Mon/Thu 1000/1005z on 8800u. Here is a complete recording from yesterday:

http://priyom.org/media/189987/new-f03.wav

https://yadi.sk/d/n0ybNa2A3SEatz

STANAG-4538, LDL32 transfer bearing a clear-text message

The transmission was heard at 0904z on 11426.5 KHz USB (01 Feb 2018) and it's the first time I meet a clear-text message sent using a 3G-HF xDL protocol, in this case the LDL (Low-Latency Data Link) protocol.

In this transfer each LDL_DATA PDU carries a single data packet composed of 32 bytes of user data (LDL32 mode) followed by a 17-bit sequence number and an 8-bit control field (presently unused) added by the LDL protocol: this way the LDL32 PDUs are composed of 256+25 = 281 bits. The Burst Waveform 3 (BW3) is used for transfers of traffic data by the LDL protocol; BW3 computes and adds a 32-bit Cyclic Redundancy Check (CRC) to the LDL data packet plus 7 flush bits having the value 0, so the total length of an LDL32 BW3 is 281+32+7 = 320 bits (Figure 1).

Fig. 1 - LDL32 BW3 structure

As indicated in Figure 1, in order to get the user-data stream we have first to remove the first packet since it is sent twice, then remove the 64-bit LDL32 and BW3 overhead from each of the remaining 3 packets.  The result, 3 x 32-byte user data segments, is shown in Figure 2.

Fig. 2 - 3x32 byte user data segments

As you see the stream exhibits a 8-bit period and consists of a clear-text (not encrypted!) message composed using the  "Arabic chat alphabet" also known as Arabish:

KI YALHAG GHAZALI 3ANDKOM YAHBAT M3AH 5

"The Arabic chat alphabet is used to communicate in Arabic over the Internet or for sending messages via cellular phones. It is a character encoding of Arabic to the Latin script and the Arabic numerals.  Regional variations in the pronunciation of an Arabic letter can also produce some variation in its transliteration (e.g. ﺝ might be transliterated as j by a speaker of the Levantine dialect, or as g by a speaker of the Egyptian dialect)." [1] 
Since there are different transliterations depending on the region, and considering possible receive errors, the right English translation of the message is difficult. I tried to translate the received text directly into Arabic using the on-line google translator but got a bit poor meaning text ("So that you may go down with me") so I twitted a brief analysis hoping to have some useful comments... and I had them from my friends Guido (aka Decode_Signals) and - naturally - from KarapuZ.
Guido confirmed my opinion about the Arabish and advised the above link to wikipedia, while KarapuZ suggested another transliteration that probably makes a better sense: "(so that) he will come to Gaza with him" (Figure 3).

Fig.3 - the transliteration proposed by KarapuZ

I do not know who run the 11426.5 KHz frequency, AFAIK S-4538 is used in military environment, neither if the received text is a test message o a real message: maybe other messages (useful to understand the context) were sent just before and I did not hear them, anyway that frequency deserves to be monitored. 
I post the analysis for the same reason: anyone have some other comments or can shed a light on the meaning of the message?

[1] https://en.wikipedia.org/wiki/Arabic_chat_alphabet

https://yadi.sk/d/e5515bbl3S4EU8

Baudot encoding with 1.5 stop bits

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 (!), when 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.