16 March 2018

unid 32-bit secondary protocol

The analysis is related to a 3G-HF STANAG-4538 transmission in which the traffic service is “Circuit Mode” and spotted on 7961 KHz/USB, 188-110A Serial is used as the traffic waveform. After demodulation of 188-110A, the stream obtained shows a series of data blocks, corresponding to the transmitted bursts, characterized by a 32-bit length period which is due to the headers of each block (Fig. 1). Comparing the headers gives a common structure of 120 bytes that differs by 32 bytes (Fig. 2).

Fig. 1
Fig. 2
A proposed byte-framing (LSB-> MSB) is presented below:

initial 176-bit length sequence of "0" followed by 2-byte sequence (SYN sequence?)
0x81 0x18 (10000001 00011000)

23-byte idle pattern 0x55  starting with 0x27

21-byte (preamble?):
0xD5 0x68 0xF1 0x90 0x70 0xEF 0x96 0x8E 0x70 0x11 0x0F 0x09 0xF7 0x6E 0xE9 0x68 0x17 0xF1 0x90 0x70 0xEF 

32-byte block, this block is different in each burst  as shown in Figure 2 (message identifier?, addresses?)

3-byte sequence 0x68 0xF1 0x90 followed by 4-byte sequence repeated four times (encoder key?)
0xF0 0x68 0xF1 0x90 (00001111 00010110 10001111 00001001)  

user-data follow

it is interesting to note that the sequence 0x68 0xF1 0x90 (00010110 10001111 00001001)  is repeated several times (also starting from byte fourty-nine).
This is an hand-made mapping since I do not own a protocol analyzer/dissector tool: comments are welcome.

13 March 2018

about LPC-10 frames (STANAG-4197/M39)

A few days ago me and KarapuZ were discussing about a way to detect/isolate the LPC-10 digital voice encoded frames from a STANAG-4197 waveform and avoid false decoding. I took advantage of an heavy cold to stay at home and deepen the subject a little more
Briefly, the 4197 modem generates two separate signal formats based on two tone libraries: the 16-tone library is used for the system preamble and the 39-tone library is used for digital voice data. The initial preamble (modem preamble) is used in the receive modem for the detection of signal present, the correction of doppler, and the identification of the beginning of the system preamble. The system preamble tones are modulated at 75 Baud and the encoded voice (say LPC) segment at 44.44 Baud : both the segments are formed using OFDM technology (Figure 1). 

Fig. 1
As said above, the aim was to dig the demodulated bitstreams and find the period of the LPC frames.  In all the demodulated streams, from different registered 4197 samples, we highlight a period of 252 bits that is due to the system preamble frames (Figure 2). Indeed, quoting STANAG-4197, "The system preamble consists of a 4-bit code word to indicate the mode of the transmitting terminal combined with a 108-bit COMSEC message indicator, plus a 16-bit all-zero word. These 128 bits are encoded by a Bose-Chaudhuri-Hocquenghen (BCH) error correction code (252,128) which provides a 252-bit which are transmitted as 126 dibits on the 16-tone library.
Fig. 2
To avoid their "interference", the system preambles were removed from all the streams getting the only LPC segments. From the reading of STANAG-4197 we expected a LPC period of 54 bits: "The Linear Predictive Code provides 54 bits per frame at 44.44 frames per second. [...] The modulator shall accept 78 bits per frame from the encoder. The data shall be assigned to 39 dibits (one dibit symbol per tone)", as depicted in Figure 3.
Fig. 3
Well, what we have seen are random-bit periods, never a 54-bit period, sometimes bursts with 78-bit periods (Figure 4). Perhaps the periods of 78 bits are just a coincidence, but given that the modulator works on frames of this length (Figure 3)  in my opinion this result should not be underestimated.

Fig. 4
The reason, the most probable, is the use of a ciphering device in the chain (Figure 5): the signal coming from a headset/handset or from on-board communication systems is digitalized by the LPC vocoder, encrypted and then modulated in accordance with STANAG 4197.
Fig. 5
Although a period of 252 bits is a hallmark of 4197, it is not sufficient to identify LPC frames, at least as long as a ciphering device is used. The doubt remains on those 78-bit period frames, a length that corresponds exactly to the 39 dibits assigned to the LPC tones.
The tests were done on about two dozen samples, some of them coming from the same source, so it would be useful to repeat the measurements on other and different recordings, better if un-encrypted. 
Unfortunately, 4197 / LPC-10 are not very frequent but 188-110 39-tone (also known as M39) could be a way out: according to 188-110B # "the modem should be expandable to include the Advanced narrowband digital voice terminal (ANDVT) (thirty-nine tone) mode. If included, this mode shall be in accordance with MIL-C-28883 and STANAG 4197." This is possible since 188-110B App. 8 waveform adopts a same 39-tone libray as STANAG-4197.

Fig. 6
Looking at one of these demodulated streams we had more luck and we found a period of 54 bits length that could be(!) what we were looking for (Figure 7).  More over, quoting STANAG-4197 "The 39 dibit/tone assignments shall be permuted to minimize the effect of the frequency selective fading and narrow-band interference [...]. The permutation pattern shall repeat after 39 frame periods.", we have also tried a 78 x 39 = 3042 bits period getting a quite good result.

Fig. 7
Fig. 8
Further 4197/M39 recordings will help.

10 March 2018


STANAG-4481 PSK (4481-P) is basically a STANAG-4285 sub-mode which adopts fixed 300 bps data-rate and long interleaving. 4481-P is used by for the NATO Naval BRASS (BRoadcast And Ship-Shore) project. BRASS uses 300bps for continuous broadcasting over wide coverage areas due to its repeated preamble data for which supports maintaining sync during long transmissions as well as late entry where a station can start to receive at any point during the transmission as long as their terminal is not set to begin on the SOM sequence.
In the heard transmission, spotted on 8322.2 KHz/USB, it's interesting to note the presence of the 64-bit KG84 sync sequence into the demodulated bitstream that denotes an encrypted message (Fig. 2)

Fig. 1
Fig. 2

6 March 2018

some tests with Harris RF-5710A modem

All that passes through the output from the HARRIS RF-5710A modem [1] is the decoded "unknown" data content and none of the raw octets (the overhead added by the HF waveform) will pass; unknown data may be synchronous or synchronous, ITA2 or ITA5 coded, clear-text or encryptyed blocks. Moreover, this is not a piece of software running on a PC but rather "hardware" that shall be connected through its serial interface port (DTE Port): the use of the synchronous or asynchronous port configuration is dictated by the type of equipment that is interfaced to the modem and the mode of operation.

Fig. 1a
At the other side, modern day PCs employ 9 pin RS-232C and do not support external receive (RX Clk) and transmit (TX Clk) clocks which are required for synchronous modes of operation. It is therefore impossible to set a synchronous mode of operation on these PCs and it means that you can only handle asynchronous (unknown) data using two possible configurations:

a) DTE Port Async - PC Port Async (Async-Async)
b) DTE Port Sync  - PC Port Async (Sync-Async), only if the on-air speed is constant, ie no autobaud waveforms

Since the Async configuration, Pc Port (and DTE Port in Async-Async) must be set to the same framing of the on-air data or you get gibberish. For what concerns the data rates:

Async-Async: ports speed can be equal or greater than the on-air speed
Sync-Async: PC port speed must match the on-air speed

Fig. 1b

The modem provides (un-framed) 8-bit ASCII output so to get ITA2 or 6-7 bits coded data you will need to run a terminal software that provides a binary stream, since dumb terminals as Putty will only display ASCII characters, and process it with a bit editor. I tried several softwares (Termite, Realterm, Aspmon,...) and in my opinion the best solution is the "Br@y Terminal" [2].
In Figures 2,3 you may see the same transmission as appear after a software modem (Sorcerer) and as sent by the 5710A modem: note the presence of the start/stop bits in the Sorcerer output. In case of non-ASCII data, as said above, the original binary stream can be obtained by processing the modem output with a bit editor and removing the extra-bits added (3 bits in case of ITA2 data, as in Figure 7)

Fig. 2
Fig. 3
I tested the modem using several waveforms, here I report only the tests of STANAG-4285, 188-110A Serial and FSK to confirm what said above about the settings of the serial ports, more precisely:

* STANAG-4285 600bps L, ITA2 Async transmission 5N1 (NSS CARBs, NATO from S.Rosa-Rome)
* 188-110A Serial 1200bps L, ASCII Async transmission 8N1 (test file from DMT) 
* FSK 50Bd/450, ITA2 Async transmission 5N1 (DDH9)

Figure 4 shows the case depicted in a): DTE Port and PC Port set to Async, data and ports use the same 5N1 framing, on-air data rate is 600 bps while both the ports are set to 2400 bps (four times the on-air speed). Figure 5 shows the same configuration (Async-Async) but in case of a 188-110A Serial waveform.

Fig. 4 - decoding STANAG-4285 in Async-Async mode
Fig. 5 - decoding 188-110A Serial in Async-Async mode
Figure 6 shows the case depicted in b): DTE Port set to Sync and PC Port set to Async. The  framing settings are the same but in this case the PC Port speed must match the on-air speed (DTE Port is set to Sync!). This is why this configuration (Sync-Async) can handle only fixed data rate waveforms. Fig. 6 is related to 4285 tests, the same Sync-Async test was also done using 188-110A Serial getting the same results.

Fig. 6 - decoding STANAG-4285 in Sync-Async mode
Fig. 7 - 8-bit stream as received from the 5710A
Note the 5-bit ITA2 stream after the extra-bits removal

FSK test is shown in Figure 8, since the low on-air rate (50Bd)  you must set the DTE Port to Async: for this test I used 600bps while framings is the same as the one on-air data.

Fig. 8 - decoding FSK in Async-Async mode

For Sync intercepts, an hardware SYNC <=> ASYNC adapter or a synchrounus DB-25 RS-232 interface are needed (both costly). The adapter needs to support all the one-air Sync mode data rates as does the PC Port which must be set to the same. On my side, I'm waiting for a synchronous interface to complete the Sync-Sync tests.

HW modems are NOT friendly as are software solutions, you will need to know how to deal with what is coming out as to its meaning.

[1] https://tsc-60.cellmail.com/tsc-60/modem/Harris.modem.5710a.pdf
[2] https://sites.google.com/site/terminalbpp/

28 February 2018

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

27 February 2018

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

26 February 2018

French Navy FUE, STANAG-4285 asynchronous ITA2 framing

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


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   

23 February 2018

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)

20 February 2018

6670.0 KHz, modified 188-110A Serial waveform

A confirm of the modified 188-110A Serial waveform, already heard on 6670 KHz and reported here. The change mainly consists of an added preamble consisting of 4 unmodulated tones at 500, 1200, 1700 and 2600 KHz as shown in Figure 1; the frequencies are comptated considering the calibration error of my SDR in this band.

Fig. 1
Data are sent using the standard 188-110A Serial waveform. It's worth noting the evidence of the 160-symbols scrambler that causes proununced 66.66 msecs ACF spikes: indeed, at slow data rates the lenght of the frame is 40 symbols (20 U + 20 UK) ie an integer submultiple of the lenght of the scrambler. The scrambler length is also highlighted by the 010101 trailer sequences sent at the end of each messages (Figure 2).

Fig. 2
 Each data block has the same initial 40-bit string repeated five times:
and once synched the blocks to that string the resulting stream exhibits 4 x 88-bit strings in each data block, this may be due to the use of a 88-bit length key (Fig. 3)

Fig. 3
The data transfer follows a 188-141A handshake between the ALE calls "CAMP" and "HORBEN", possibly a German or Swiss net (still there is not a positive identification).

16 February 2018

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:

Fig. 1
Fig. 2
Fig. 3