French Navy FUE, STANAG-4285 asynchronous ITA2 framing

26 February 2018

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