install, run and test GNU Octave against T207 and CIS-11 streams

updated

This is just a quick how-to for Octave since some friends asked me for some tips about the installation and use of Octave with some analysis tools such as the ones for T207 and CIS-11 streams (...and hopely soon for the STANAG-5066 dissector).
GNU Octave is a high-level interpreted language, primarily intended for numerical computations. It provides capabilities for the numerical solution of linear and nonlinear problems, and for performing other numerical experiments. It also provides extensive graphics capabilities for data visualization and manipulation.
The GNU Octave language is largely compatible to Matlab so that most programs are easily portable. In addition, functions known from the C standard library and from UNIX system calls and functions are supported. C/C++ and Fortran code can be called from Octave.

The easiest way to install GNU Octave on Microsoft Windows is by using MXE builds. For the current release, both 32-bit and 64-bit installers and zip archived packages (.zip and .7z formats) can be found here under the Windows tab:
https://www.gnu.org/software/octave/download.html 
For executable (.exe) installers (the better way) the user can simply run the downloaded file and follow the on-screen installation prompts. It is recommended that the installation path does not include spaces or non-ASCII characters. Shortcuts to the program will be created automatically on the desktop: CLI for the command line and GUI for the graphic user interface, the latter (GUI) is the one that is normally used:

 The installation steps are shown below:

After the installation is finished you will have to create the main working directory, usually c/users/<your_name>/octave; this will be the the right place where to create the sub-directories to store the Octave .m scripts. For example, create the sub-directory /signal_analysis and download the file t207-test.txt to it, then create the sub-directory /m (within /octave/signal_analysis) and download the script T207_detect.m into the /m sub-directory (T207_detect.m is a tool to verify the presence of the so-called T207 "format"). Now double click on the GNU Octave GUI icon and Octave will start in its Command Window

Change the Current Directory from  /octave to /octave/signal_analysis by using the arrows of the file browser, and then run the two commands:

addpath ("./m")
T207_detect ("t207-test.txt",32,14)

The first command (addpath) tells Octave where to look for the invoked .m scripts, i.e. the su-b-directory /m where you previously downloaded the script T207_detect. The second command launches the T207_detect.m script which will process the file t207-test.txt: an ASCII-bit file containing a demodulated FSK bitstream, i.e. the file to analyze that you previously downloaded to the /signal_analysis sub-directory (the other parameter is the desired frame size, 14).

after few seconds (depending on the speed of your pc) you will see the result of the T207 detection:

After close the Figure 1 window, you may also see the results shown in the textual form. Now Octave is ready to accept a new command:

You can switch to the Editor Window in order to open and edit the scripts in the /m sub-directory

Well, in the same way as above, now you can analyse - for example - a bitstream to check the presence of the CIS-11 format:

1) download the .m script CIS11_detect.m to the sub-directory /octave/signal_analysis/m
2) downolad the files cis11-test1.txt  and  cis11-test2.txt to the sub-directory /octave/signal_analysis
3) switch to the Command Window and run the command  CIS11_detect against the two files:

In a few words:
/octave/signals_analysis     > will contain the files to be analyzed
/octave/signals_analysis/m > will contain the various Octave scripts

Well, now you are probably wondering what you have done.

1) An interpreted language (as for example BASIC or Java) is a kind of programming language whose implementations execute instructions directly and freely, without previously compiling a program into machine-language instructions: the "interpreter" will convert the the high-level language code into the code understand by the operating system (say assembly language or machine-language). 

2) Well, as said at the beginning of the post, Octave is something like a "software environment" which consists of a high-level interpreted language, the interpreter, several software "libraries" that you may link to your Octave code, editor and various utilities all grouped inside the graphic user inteface. Thus when you click the GUI interface you do nothing but load and run the Octave environment.

3) When you wrote the "T207_detect" command in the Command Window, you simply told the interpreter to read and execute the Octave code language instructions saved in the "T207_detect.m" file, passing it some parameters such as the name of the data file to be examined (t207-test.txt).

4) Strictly, T207_detect.m is not indicated as a "program file" but rather as a "script file", ie a file containing any sequence of Octave commands (say instructions). It is read and evaluated just as if you had typed each command at the Octave Command Window prompt, and provides a convenient way to perform a sequence of instructions (you can't do that with a compiled language such as C). 

5) At the end of the day, T207_detect.m is nothing else that a sequence of Octave instructions that implement the algorithm described here in order to check if all the 14-bit sequences of a file verify the T207 checksum: even on large files the computer will take a few seconds, it would take hours, beer and coffee (lots of coffee ) if you do it by hand. 

Yes I know, that's a very basic approach to Octave but I hope it will allow you to start to work with some useful scripts, understand how it works... and maybe start to learn Octave. By the way, two important resources:
https://wiki.octave.org/Octave_for_Microsoft_Windows
https://it.wikipedia.org/wiki/GNU_Octave

weird, but intriguing, 75bps Baudot encoding with 3.8 stop bits (prob. ACP-127 msg)

That's a very interesting Baudot 75Bd/850 FSK signal recorded (and sent me) by my friend cryptomaster on 6721 KHz/USB: although its nominal parameters lead to an async STANAG-4481 transmission, the analysis (Figure 1) reveals an unexpected stop-bit length of 3.8 bits(!), i.e. an unusual 5N3.8 framing (it's to notice that, in case of lost sync, the stop-bit stretching allows faster resync and framing of the incoming data).

Fig. 1

Since the bit editor works using integer numbers (it can't draw half bit), the bitstream is shown with the 5N4 framing  (Figure 2, negative polarity): it means that parsing the 5-bit code will inevitably produce some errors.

Fig. 2 - the bitstream as it appears after demodulation

At first glance, the decoded text looks like a message with errors due to a noisy signal or having a poor SRN (Figure 3), but an in-depth analysis of one of the decoded text reveals interesting details that allow us to identify sender/recipient and the very nature of the message: in my opinion, a radar detection report sent in ACP-127 style message. Obviously, decoding suffers from the non standard framing so, after various decoding runs, I re-built the message using the parts taken here and there and that -in my opinion - make more sense.

Fig. 3 - Baudot decoded text

T-O  081506z Fet 21

that's the DATE-TIME-GROUP (DTG)  of the message; indeed, as you can see in Figure 1, the transmission was recorded on 2021-02-08t15_12_04z so we have 08 (day 8) 0815z (time) february 2021 (Fet 21). This way of coding the date also corresponds to what is indicated in the Code FM-13-x-SHIP (or shortly FM-13) [1].

FM TIRPA 29 TO CEFAE
FM is the originator's sign, the originator of this message is indicated by the designation immediately following. TIRPA  is the callsign adopted by the French Aviation Defense Service (ICAO DEF), TIRPA 29 could be an aircraft  [2]. TO is the "Action Addressee", ie the addressee(s) immediately following (CEFAE) is to take action on the message.

INFO AERO LANN BIHOUE
INFO is the Information addressee sign (as "CC"), in this message is the French Naval Aeronautical Base of Lann-Bihoué located in the Atlantic region, placed under the operational command of the Atlantic zone (AERONAV/AWLANT, see below) [3].

MCA ACT/AERONAV/AWLANT
likely the Aéronautique Navale (AERONAV) operational command of the Atlantic zone (Air Wing Atlantic, AWLANT). Since the "scene", MCA could mean Maritime Cryptologic Architecture (here the term "cryptology" refers to the SIGINT functions of the maritime Services and incorporates Information Security or INFOSEC functions).

NMR/004 NP 0802 TXT LR 3/1
number of the message (NMR 04), date February 8th (NP 0802) and format of the message (TXT)

DDGH/FRA/JEWNDE VIENNE
the term "VIENNE" could be misleading (city of Wien) but actually JEWNDE VIENNE stands for "JEANNE DE VIENNE", a F70 type anti-submarine frigate of the French Navy. DDGH is the acronym of Destroyer, Helo Capable, Guided Missile.

GPOSIHION 4642.7N/0023.9W SUFFIX GOWF PAPA
it's likely a (geo) position  (suffix is probably GP, GOLF PAPA ). Don't know the format the coordinates are expressed, it seems they do not exactly follow the FM-13 [1] specs even if the terms North and West are easily recognizable. Trying a parsing, the result is quite realistic (46°25'12", 2°23'24")

ROUTE/VITESSE 293 VRAA
respectively course and speed (see below)

And here things get more interesting:

RMQ:CFTERCEPTION ESM DRBV 26A X SN 40270 / CONFIANCE 3
DRBV 15 / SN 65+53 / CONFIANCE 3  

I guess this text refers to INTERCEPTION ESM, where ESM stands for Electronic Support Measures: i.e. something related to radars [4], indeed:

- DRBV-26A (Jupiter) is a Thomson-CSF early warning radar performing long-range air surveillance on board medium and heavy-tonnage ships. DRBV-26A operates in D-Band, and is available with a cost-effective fully solid-state transmitter [5][6]
- DRBV 15 (Sea Tiger) is operating in S-Band air and surface surveillance and target designation radar. The system is designed for medium to large ships and can be integrated with weapons systems [7] [8]
- CONFIANCE is the degree of the detection confidence, levels range is from 1 (low) to 3 (high).

 SN 40270 and SN 65+53 are probably some of the out measurements from the radars.

BT /0 NNNN
Break and End-of-Message Indicator (EOM)

Since the French Navy frigate "Jean de Vienne" is equipped with both the radars (DRBV-26A and DRBV 15) [9], I think that the recorded transmission could be an ACP-127 tactical message about a radar detection (or something very similar to it). It's not clear to me who the fields position-course/speed refer to (sender? ship? or maybe the radar target?).
Anyway, it's quite unusual to see such (prob.) ACP-127 messages in clear text as well as the 5N3.8 framing, probably derived from a STANAG-4481F modem: could they be trainings? Comments are welcome.

 

Frigate Jean De Vienne (CC BY-SA 3.0, https://commons.wikimedia.org/)

Update (thanks to Jean-Marc Liotier @liotier)
CEFAE Centre d'entraînement et de formation de l'aéronautique navale, navy school in Lann-Bihoué.
Looks like training is the reason for using this elderly format to report ESM sightings.

[1] http://www.vos.noaa.gov/...

[2] https://en.wikipedia.org/wiki/List_of_airline_codes 

[3] https://www.defense.gouv.fr/marine/operations/... 

[4] https://en.wikipedia.org/wiki/Electronic_warfare_support_measures

[5] https://fr.wikipedia.org/wiki/Jupiter_(radar)#DRBV-26A

[6] https://www.radartutorial.eu/19.kartei/07.naval/karte005.en.html

[7] https://www.helis.com/database/sys/677-air-search... 

[8] https://www.radartutorial.eu/19.kartei/07.naval/karte099.en.html 

[9] https://it.wikipedia.org/wiki/Classe_Georges_Leygues

 

https://yadi.sk/d/XNSJvAOX-VezKw

Swedish STANAG-5066 client-application... (2)

(just a little update to the previous post) A further confirmation of the role of the STANAG-5066 DTS (Data Transfer Sublayer) in the duplication of D_PDUs  comes from the examination of the S5066 frames produced by the dissector that I'm still writing (Figure 1).
As said previously, C_PDU segment offset in the duplicated D_PDUs does not change and thus the same data segment is processed two times and then sent into two distinct frames (#85 and #86 in this example). In this regard, it's interesting to notice the valuse of the EOT field. The field End Of Tansmission (EOT) contains a binary number expressing the number of half (1/2) second intervals remaining in the current transmission from the beginning of the current D_PDU. Once an EOT is sent, the EOT in each subsequent D_PDU in that transmission contains a consistent calculation of the EOT, that is, monotonically decreasing in half-second (0.5 second) intervals (calculations by the transmitting node is rounded up to the nearest half-second interval). As you may see, the flow control updates the EOT value.

Fig. 1

Swedish STANAG-5066 client-application, a look at the DTS sublayer

(Just an update about the "Swedish Defence client-application for STANAG-5066" topic)
As said in the previous posts, the users employ the 3G-HF "Circuit Mode" service (STANAG-4538), data are transferred in non-ARQ mode using the STANAG-5066 stack and basic end-to-end transport protocols (UDOP/RCOP). Since the use of 3G-HF, the stations partecipating the netwok synchronously scan the assigned pool of frequencies and transmissions just happen when in need. 
I came across on a transmission, on 4742.0 KHz/USB, that exhibits two features never seen before in the previous transmissions (at least in my case):
● the used HF waveform is STANAG-4539 3200bps (usually they employ 188-110 1200bps along with S-5066 or alone in 8-bit text mode);
● the multiple occurrences of the ASCII string "WVKA" inside a message, which implies a look at the role of the Data Transfer Sublayer (DTS) of STANAG-5066.

Fig. 1 - Multiple occurrences of the string "WVKA", here in block 2 out-of 20

It's noteworthy that, actually, the occurrences are about the half since data are repeated!

Just a reminder for background: in case of a source message that is larger than the MTU (Maximum Transmission Unit) of the S-5066 subnetwork interface (usually <=2048 bytes), the client-application segments the message into n-blocks (A_PDUs) before its submission. The blocks are then encapsulated into the final C_PDUs, which in turn are segmented by the Data Transfer Sublayer (DTS) into smaller 200-byte D_PDUs (PDU stands for Protocol Data Unit).

Fig. 2 - progressive encapsulations and segmentation in S-5066 stack

It's possible to verify that in some circumstances - probably when UDOP protocol is used - segmenting a C_PDU results in duplicate D_PDUs (!), except the first and the last D_PDUs (read below). As clearly shown in Figure 3, the analyzed transmission just matches that case.

Fig. 3 - The duplicated D_PDUs in the block 2 out-of 20 (the same block of Figure 2)

This behavior is easily seen in many transmissions, whether they use S-4539 or 188-110A waveforms: note in Figure 4 that the first D_PDU is repeated only in the first C_PDU, while the last D_PDU is never repeated.

Fig. 4

Where do the duplicate D_PDUs come from? Inspecting the headers in Figure 5, it's possible to note that the "C_PDU Segment Offset" field contains the same value in the pairs of the duplicate D_PDUs. Given that the Segment Offset indicates the location of the first byte of the segment with respect to the start of the C_PDU, it means that the C_PDU (and thus the upper sublayers) does not contain duplicate data, otherwise the Segment Offset fields in the pairs of the duplicate D_PDUs would have contained different values! Thus, in my opinion, the duplicate D_PDUs are originated by the DTS sublayer. Notice that what we see in Figure 5 are the on-air bytes, thus after they have leaved the DTS (see the S-5066 stack in Figure 2).

Fig. 5 - headers of the D_PDUs (each row is a D_PDU, see Figure 2)

Segment Offset fields contains a 200 bytes step values, as expected:
0x0000 =    0
0x00C8 =  200
0x0190 =  400
0x0258 =  600
0x0320 =  800
0x03E8 = 1000
...

The receive node will re-assembly a C_PDU from its segments (the D_PDUs) after they have passed the CRC error-check and have no detectable errors: probably the redundancy is used in this regard. I did not find any reference in the S-5066 standard, at least the one at my disposal, and I tend to exclude possible errors of the S-4539 (or 188-110A) decoder since the same results were obtained using different decoders and different HF waveforms: so, at least in my opinion, the repetition of the D_PDUs could be a custom modification of the code of DTS  (switchable to maintain NATO compatibility) or a new feature added to a recent edition of S-5066. Definitely, even if the latency increases (such transmission mode takes about twice as much time, although they have moved on the 3200 bps of S-4539) the add of redundancy improves the general reliability of the system since S-5066 is used in non-ARQ mode.

As for the string "WVKA", only guesswork can be made: further recordings are in need. For now, I'm going to code a S-5066 dissector to facilitate the reading of the headers...

https://yadi.sk/d/9vqs2DfTOKN1sg
https://yadi.sk/d/s7oyiYaTt406vw 

Fast WALE (4G-ALE) and wide band traffic (WBHF)

Thanks to a reporting of my friend Martin G8JNJ, on 4744.0 KHz - mostly in the morning -  it is possible to receive transmissions which use Fast WALE (188-141D App.G) and WBHF (188-110D App.D) waveforms: it's the first time for me that I have the canche to "see" and analyze 4G-ALE signals. 

The WALE (4G-ALE) system uses waveforms derived from the WBHF waveforms for its transmissions, and draws ideas from both second and third-generation ALE for its protocols. The WALE waveforms operate in 3 kHz and provide two interoperable modes for sending PDU: the “Fast” WALE waveform (intended for very fast link setup in voice-quality channels) and the “Deep” WALE waveform (designed for operation in the most challenging channels, including SNR < 0dB). The choice between Fast or Deep WALE can be made on a call-by-call basis as receivers listen to both types of WALE calls, as well as 3G & 2G ALE calls for simultaneous operation with existing narrowband circuits.[1]

In the recorded session shown in Figure 1, the transmissions consist of two-way WALE handshakes followed by data transfers using ARQ method and WBHF waveforms: the bursts following the last ACQs are probably an EOM signaling given that the following session begins with a WALE handshake. Since the strong signals in the analyzed sample, I can't say if it's a bidirectional link. 

Fig. 1

The WALE LSU protocol use a fixed 96-bit length PDU for both Fast and Deep waveforms with a correction coding consists of a constraint length 9 (CL-9), half rate convolutional code producing a 192-bit coded block (ie, for each bit input to the encoder, two bits are taken from the encoder). Using Fast WALE the coded and interleaved bits of each PDU are sent in alternating blocks of unknown (data) symbols and known (probe) symbols.

The WALE waveforms employ PSK8 modulation of an 1800 Hz subcarrier at a rate of 2400 symbols per second. The two more dense states in the phase plane of Figure 2 are due to the BPSK modulation of  Fast WALE data.

Fig. 2

 

In the analyzed samples the portion before the coded and interleaved PDU, according its 83.33 ms duration, consists of 200 PSK8 symbols (figure 3). Since the preamble and the TLC sections use the same 32-element Walsh chips (32 PSK8 symbols), the initial portion consists of 1 TLC block (13.333 ms) followed by 168 PSK8 symbols (70 ms) which do not resolve into an integer number of 32-element Walsh chips! These values, durations and symbols, are not compliant with relevant standard (188-141D #G.5.1.8.2) which requires nine 32-element Walsh chips for the Fast WALE  preamble, for a total of 288 PSK8 symbols and a 120 ms duration.

Fig. 3

The structure of the known/unknown symbols blocks is exactly compliant with 188-141D: ie, 288 PSK8 symbols and a 120 ms duration (figure 4). Notice that according 188-141D, the length of the preamble shall be equal to the sum of the lengths of the known/unknown symbols blocks.

Fig. 4

The traffic waveforms are PSK8 modulated at symbol rate of 9600Bd, ACF value is 120ms that makes a 3456-bit length period or 1152 PSK8 symbols (Figure 5): the frame structure (Figure 6) matches the waveform #7 of 188-110D App.D ie, 1024 Unknow symbols (3072 bit) + 128 Known symbols (384 bit). 

Fig. 5 - WBHF waveform #7

Fig. 6

The bursts I termed as "EOM" also employ PSK8 modulation at symbol rate of 9600 Baud and have a frame length of 1504 symbols (Figure 7).

Fig. 7

[1] https://www.rapidm.com/wp-content/uploads/2018/10/RM10_WBHF_EN.pdf

https://yadi.sk/d/FkvzXFHKLL0Rbw