19 October 2017

Radio Teleswitch, an example of AM Signalling System (AMSS)
(by ANgazu)

BBC Radio-4 (LF 198 Khz) is a radio station that broadcasts a great variety of programs. At first glance, it looks like any other AM commercial emitter, but there is a feature that makes it different: its carrier is PSK modulated, transmiting  data to switch electric meters and consumer appliances to take advantage of best electric tariffs [1].
This sample was recorded using TWENTE sdr in USB mode so to preserve the carrier, its spectrogram is as any standard AM broadcast (Fig. 1) and it's occupation is about 12 Khz as most AM comercial stations.

Fig. 1
When zooming on carrier (Fig. 2), there is a  signal using about 50 Hz BW on each side of the carrier and once filtered, the modulation speed is 50 symbols/sec (Fig.3).

Fig. 2
Fig. 3
In this case, carrier is the AM carrier so we  can go to  the signal constelation that shows that the carrier phase is shifted  ±  22.5º (Fig. 4). This small shift is suitable  for retrieving data and is small enough to avoid interferences with the intended AM signal.

Fig. 4
To  demodulate this signal, you have to filter out the carrier and proceed as in any BPSK signal. ACF is about 2 seconds, this means that there are 30 frames within each second and everyone carries 100 bits. Signal is "manchester" coded so we will have 50 bits of information per frame (Fig. 5). The signal is idling most of the time (01010101…) 

Fig. 5

[1]

14 October 2017

ISB SDR ARQ system heard in the 6 MHz maritime band
(KLN Networks CNHF system?)


Robust ISB SDR ARQ system heard on 6231.5 KHz/USB (Maritime Mobile band) 2800Hz offset from carrier, around 0630z on 12 October and in which the two channels are used as follows:

- on USB upper channel: user data transfer using adaptive 2400 Baud PSK-2 and QPSK burst waveform, according to the channel conditions and the feasible data-rate. Initial bursts use PSK-2 modulation at 2400 Baud;  
- on LSB lower channel: link and traffic management (ACKs and mode used for data transfer) using 1500 Baud PSK-2/QPSK waveform; 

is not clear if the change of the mode used for data transfer is signaled in the management channel by the caller or it is requested by the called station.

Fig. 1 - user data transfer waveform (upper channel)
Fig. 2 - link and traffic management waveform (lower channel)

At least in this sample, data bursts last 2088 msec for PSK-2 and 3144 msec for QPSK, the initial bursts have a duration of 520msec; link and traffic management bursts last 310 msec. PSK-2 and QPSK data bursts exhibit strong ACF spikes every 523 msec which suggest a 1256 symbols frame structure (Fig. 3); initial data bursts have ACF = 0, probably Walsh modulation is used (Fig. 4).

Fig. 3
Fig. 4
Together with IK1YDE we studied the bitstreams after PSK-2 and QPSK demodulations and found a frame structure similar to those provided by the recent MS-110 Appendix C for the waveforms ID 5 and 6 (Fig.5). Indeed both PSK-2 and QPsK frames consist of 288 symbols (Fig. 6): 32 knwon symbols (mini probes) followed by 256 unknown (data user) symbols. It must be noted anyway that the data rate of the analyzed waveform (in its USB channel) is 2400 Baud and doesn't match the one provided by the waveforms 5 and 6 of MS-110 App.C.
Most likely the 1256-bit ACF is due to the length of the interleaver or the scrambler sequences.

Fig. 5
Fig. 6 - data bits and symbol numbers

Talking with KarapuZ about this system, he suggested a SDR equipment rather than a ISB mode (I edited the text of the post accordingly) and proposed to have a look at the KLN Networks website since they are testing a proprietary 3G HF hybrid system (termed CNHF) to support the ship traffic in Artic regions [1]. In that high latitudes satcomm links can't be easily used since geostationary satellites do not cover these areas, moreover due to the long dark periods the low portion of HF shall be used (lack of F layers). Perhaps may catches are related to their tests... but it's only my guess (I emailed them to ask a confirm and maybe shed some ligth on this system).





TADIRAN HF modem running in MFSK-4 + scrambler mode

TADIRAN HF modem, probably the HF-6000 model, running in COMSEC mode using MFSK-4 125Bd/300Hz and scrambled voice-comms. Transmission heard on 5885.0 KHz/USB at 0755z with a very poor SNR. The sample marked as "A" is the "autocall" waveform: it follows the MFSK/scrambler session and terminates the link.




12 October 2017

OFDM modem 12+12 tones 48Bd (Marconi 25-tones)


Probably a simplex transmission heard on 6246.5 KHz/USB. Although the SNR is poor, it's possible to see a central un-modulated tone a + 1500Hz  that splits the signal in two identical parts which I analyzed separately. The results show an OFDM modulation of 12 + 12 tones at a rate of 48 symbols/sec; the on-air constellation seems to be QPSK on each channel.

Fig. 1
Fig. 2
Fig. 3
 The initial part exhibits an upper un-modulated tone and a short FSK

Fig. 4

 Modem name and users are unknown to me.

Update:
thanks to hf_linkz who pointed me to the correct identification of this modem: it's the "Marconi 25-tones" as depicted here:
http://signals.radioscanner.ru/base/signal125/ 
https://www.sigidwiki.com/wiki/Marconi_Selenia_25-Tone_Modem  





THALES mention

happy to be mentioned by THALES in their HFXL modem "Sea Trials" presentation during the last HFIA meeting in Kjeller Norway on 8 September 2017. Thanks to Catherine LAMY-BERGOT, from THALES, who kindly asked the permission to use the material from my blog.
The whole presentation HFXL Sea Trials on French BPC, as well as other works, can be downloaded from here:
http://www.hfindustry.com/meetings_presentations/2017_sep_hfia.htm


 




11 October 2017

unid STANAG-5066 RCOP/UDOP client, Swedish Army (update-4)

[read all the posts about this topic]

data block
Adding the data blocks to form a single file show a repeated 33-byte length pattern which precedes the "magic string", probably  a  common heading to all the messages (Fig. 1). As well as for the "magic string", it's difficult to say the scope of these sequences: indeed, further analysis will focus on the data block trying to get some meaningful. Recordings, help and tips are welcome!

Fig. 1

Some interesting observations from the recent catches.

1. I had the chance to copy a transmission on 5206.3 KHz followed by an identical one on 5059.4 KHz after few seconds (Fig. 2). This is quite easy to accomplish since they use S-4538 FLSU for link setup, so the stations of the network are synched and scan the same pool of frequencies at same times. Repetitions increase the reliability of the system but do not know if it was just a planned episode or a routine scenario (more powerful monitoring tools would help...)

Fig.2

2. Usually transmissions are originated from nodes belonging to 006.046.000.zzz block (mostly HWK01) and directed to nodes of the 006.046.001.zzz block. This time I copied a trasmission inside the 006.046.001.zzz block (never copied so far), namely from BYN21 (006.046.001.006) to NZH21 (006.046.001.052).
As above: episode or a normal way to operate?

Fig.3

3. Luckily I copied some transmissions probably just few minutes after the start of a new epoch time of the timestamp clock and thus with a timestamp exhibiting a length of 7, 8 and then 9 bytes (Fig. 4). This is a full automated system working in a FIFO logic, ie the messages are wrapped and forwarded in the same order they arrive  (first came first served).  As well as for the IDs, the wrapper does not use a fixed length for the timestamp: it simply catches the value, computes its length and arrange them in the form {<length>,<content>}. This clarifies why so far I found transmissions with 9 and 10 bytes lengths.
As already debated, the variable lengths of IDs and timestamp affect the length of the data block since it shall be computed to fit the max transmission unit of the protocol (2039 bytes). 


Fig.4


STANAG-5066 Addresses and "Magic Strings"
heard so far:


[006.046.000.zzz] block
HWK01   006.046.000.028, 006.046.000.102
ZMK002  006.046.000.037
OYO01   006.046.000.101 *

[006.046.001.zzz] block
FRJ    006.046.001.001 *
BYN21  006.046.001.006 *
DWY    006.046.001.009
PFY    006.046.001.010
ZHO    006.046.001.028
RJY    006.046.001.029
GZL    006.046.001.030
HEH    006.046.001.034
HEH002     --"--
CAU    006.046.001.046
NZH21  006.046.001.052 *
VJL    006.046.001.054

ZAPCA
ZAPCG
ZAPCK
ZAPCH *
ZNTCH *
ZRTBC
ZRTBD
ZXPBC
ZXPBD
ZXPBG
ZXPCK
ZXPDA *
ZXPDK *

* new ones


[read all the posts about this topic]
 

5 October 2017

Logs


04215.5  IDR: Italian Navy S. Rosa Rome, I 1555 (cf) FSK 75Bd/850 CARBs "IDR04I(0)/IDR23 /IDR22 /IDR03I(0)/IDR02I(0)/IDR21/" (24Sep17) (AAI)
05398.2: ---: Unid 2000 USB GMSK/PSK-2 2380Bd hybrid modem using burst waveform (23Sep17) (AAI)
06208.5: YSG: Unid 0618 USB 188-141A call ISB, AMD "QTCP" (29Sep17) (AAI)
06248.0: ---: Unid 0555 USB PSK-2 4800Bd modem, 6 KHz bandwidth burst waveform (29Sep17) (AAI)
06303.0: ---: USB 2004 USB 3G-HF 2-way FLSU handshake / LDL32, sending 139-byte Harris "Citadel" encrypted file (22Sep17) (AAI)
06329.0: OSY: Sailmail Brugge, BEL 0641 USB Pactor-IV 1800Bd traffic (20Sep17) (AAI)
06335.0: 8DV9: Bolivarian National Armada of Venezuela (Navy) Vessel "Los Llanos", VEN 0535 LSB 188-141A handshake 2KZ9 / 188-110A Serial (29Sep17) (AAI)
06336.0: ---: Unid 0849 USB 188-110A App.B OFDM 39-tone tfc, link terminated by HARRIS Autolink I (18Sep17) (AAI)
06348.0: FUE: French Navy Brest, F 0745 USB STANAG-4585 600bps/L "DE FUE FUJB BONNE JOURNEE" (02Oct17) (AAI)
06510.0: Z1V: Slovakian Air Force Zvolen, SVK 0723 USB 188-141A handshake S1L Sliak / 188-110A Serial, sending encrypted email using STANAG-5066 and Harris BFTP protocol (29Sep17) (AAI)
06516.0: MedNet: Mediterranean Cruiser Net 0611 J3E/USB English lang. male working cruising vessels (27Sep17) (AAI)
06670.0: CAMP: Unid 1507 USB USB 188-141A handshake OUTPOST / proprietary HF modem using modified 188-110A Serial & STANAG-4539 waveforms, 128-bit secondary protocol, prob. 88-bit key encoded (02Oct17) (AAI)
06715.0: ---: Unid 0709 USB 3G-HF 2-way FLSU handshake / LDL448 transfer, sending 1291-byte encrypted file (20Sep17) (AAI)
06728.0: 810001: Unid 0725 USB 188-141A sounding (04Oct17) (AAI)
06801.0: D20: NPRD Net Dubrovnik, HRV 0824 USB 188-141A sounding (03Oct17) (AAI)
06803.0: OG00: Austrian Military, AUT 0700 USB 188-141A handshake PO00 / 188-110 App.B OFDM 39-tones, LPC10 ANDVT (04Oct17) (AAI)
06831.0: P34: NPRD Net, HRV 0701 USB 188-141A sounding (20Sep17) (AAI)
06836.5: B22: (Netherlands Military?) 0723 USB 188-141A rptd 2-way handshakes with B21, no follow-up (03Oct17) (AAI)
06846.0: SVK: Unid 0758 USB 188-141A call DHJ (04Oct17) (AAI)
06964.0: ---: Unid 0734 ISB LINK-11 CLEW traffic (02Oct17) (AAI)
07509.0: ---: Unid 0746 USB 3G-HF MDL transfer using LDL512, sending 29KB 'Citadel' encrypted file (27Sep17) (AAI)
07656.2: XLA: French MoD, F 1355 USB 188-141A handshake XLB / THALES HFXL modem tests (handshake on the upper channel) (03Oct17) (AAI)
07685.0: NX50: Unid 2052 USB USB 188-141A call ZM64 (02Oct17) (AAI)
07685.0: NX50: Unid 2053 USB USB 188-141A call ZM60 (02Oct17) (AAI)
07685.0: ZM41: Unid 2056 USB USB 188-141A call NX50 (02Oct17) (AAI)
07739.0: 3127: Sonatrach, ALG 0741 USB 188-141A sounding (20Sep17) (AAI)
07775.0: DU6: Polish Military, POL 0636 USB 188-141A call OS5 (23Sep17) (AAI)
07775.0: DU6: Polish Military, POL 0732 USB 188-141A call FO7 (16Sep17) (AAI)
07813.0: X44: Moroccan Army, MRC 0632 USB 188-141A sounding (23Sep17) (AAI)
07830.0: ZD02: Algerian Military, ALG 0826 USB 188-141A call AT01 (27Sep17) (AAI)
07838.0: A98: Chinese net, CHN 2100 USB USB 188-141A call D78 (02Oct17) (AAI)
07885.0: SHARK25: Unid presumed Egyptian Net, EGY 0638 USB 188-141A call HQ2 (18Sep17) (AAI)
07924.0: HOWBATNET035: Unid 0829 USB 188-141A call MDBNGCMNET035 (03Oct17) (AAI)
07942.2: BYN21: Swedish Armed Forces, S 2027 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, Circuit Mode tfc to NZH21 using STANAG-5066 unid UDOP client (22Sep17) (AAI)
07964.0: ZM65: Unid 1955 USB USB 188-141A call NX50 (02Oct17) (AAI)
08000.5: HBLZDRD1: Roumenian Military, ROU 0706 USB 188-141A call HFJCDRD1 (15Sep17) (AAI)
08040.0: TWLC1: Guardia Civil Santander, E 1959 USB 188-141A call TXFA5 (02Oct17) (AAI)
08054.0: FN05: Algerian Military, ALG 1337 USB 188-141A call to FN03 (21Sep17) (AAI)
08054.0: FN05: Algerian Military, ALG 1339 USB 188-141A handshake FN01 / 188-110A Serial (21Sep17) (AAI)
08054.0: IU02: Algerian Military, ALG 0835 USB USB 188-141A handshake IU01 / 188-110A Serial, sending data prob. using FED-1052-D (27Sep17) (AAI)
08060.0: ---: Unid 0610 USB 3G-HF LDL512 transfer, sending 14KB 'Citadel' encrypted file (29Sep17) (AAI)
08182.0: XDV: DHFCS station, UK 2019 USB 188-141A 2-way handshake XSS, no data transfer (22Sep17) (AAI)
08389.0: ---: Unid 1145 (cf + 1500Hz) Sitor-A "TEST" (27Sep17) (AAI)
10311.0: ---: Unid 1442 USB 3G-HF FLSU handshake / HDL+ transfer (21Sep17) (AAI)
10356.0: ---: Unid 1734 USB 3G-HF FLSU asynchronous call, no reply (21Sep17) (AAI)
10387.0: ---: RUssian Diplo/Mil, RUS 1515 USB CIS.45 33.33Bd selCall-WakeUp / CIS-60 35.5 Bd -> CIS-45 40Bd, same physical modem  (21Sep17) (AAI)
10425.0: ---: Unid 0743 USB 2-way FLSU handshake / Circuit Mode service using 188-110A serial (20Sep17) (AAI)
10425.0: ---: Unid 1000 USB 3G-HF FLSU asynchronous call, no reply (20Sep17) (AAI)
10425.0: ---: Unid 1740 USB 3G-HF FLSU handshake / LDL512, 27KB file transfer (21Sep17) (AAI)
10425.0: JAI: Unid 0911 USB 188-141A call OJ6 (20Sep17) (AAI)
10425.0: XPU: UK DHFCS? 0749 USB 188-141A call SRX (20Sep17) (AAI)
10429.0: 2157: Unid 1358 USB 188-141A call to 2159 (21Sep17) (AAI)
10447.0: R03: Roumenian MAECT Bucharest #3, ROU Unid 0814 USB 188-141A handshake MOG Athens Embassy / 188-110A Serial, sending email using STANAG-5066 with fictious Addresses (20Sep17) (AAI)
10482.0: CENTR2: Roumenian MAECT Bucharest #2, ROU 0832 USB 188-141A handshake YPM31 / 188-110A Serial, sending encrypted email using STANAG-5066 and Harris BFTP protocol (25Sep17) (AAI)
10580.0: ---: Unid 0942 USB 3G-HF FLSU asynchronous call, no reply (20Sep17) (AAI)
10719.0: ---: Russian Intel/Mil, RUS 1130 USB CIS-45 HDR modem v1, OFDM 45-tone 33.33Bd PSK-2, two bursts series (26Sep17) (AAI)
10737.7: ---: prob. Finnish Defence Forces 1238 (cf) Panasonic CF-U1 (Nokia M/90), Adaptive MSG-Terminal FSK 301Bd/151Bd 780Hz shift (29Sep17) (AAI)
10785.0: SAO: Unid Spanish Net 0944 USB 188-141A calling all stations (@@?) (20Sep17) (AAI) [1]
10785.0: SAO: Unid Spanish Net 1002 USB 188-141A calling any station (@?@), informing "in position" [FRM][SAO][CMD AMD][EN POSICION ] (20Sep17) (AAI) [1]
10785.0: SARRIOCERLER: Unid Spanish Net 0925 USB 188-141A call AMARILOCERLER, no reply (several calls) (20Sep17) (AAI) [1]
10796.0: RAA: M32a Russian Navy HQ St. Petersburg, RUS 0837 CW simplex w/ RCRE "RCRE DE RAA", "RAA DE RCRE K", "RAA QRR3 QDW 10540 K", "RCRE OK QRR3 QDW 10540 k", "RAA K" (20Sep17) (AAI)
10950.0: TYLEC79CAL65: Polish Military, POL 0805 USB 188-141A call HR6 (19Sep17) (AAI)
11059.0: TU4: Polish Military, POL 0757 USB 188-141A call SZ1 (28Sep17) (AAI)
11217.0: UKE304: RAF E3D AWACS 1205 USB 188-141A handshake XSS / METARs request & reply (27Sep17) (AAI)
11220.0: ---: Unid 2145 USB TE-204/USC-11 MFSK-4 HF modem 75Bd, in-band frequency and time diversity mode (21Sep17) (AAI)
11403.0: PEGASO: EVA (Escuadrón Vigilancia Aérea) Spanish AF Torrejón de Ardoz, S 0802 J3E/USB, warns the network to switch to the secondary feq. (25Sep17) (AAI)
11544.0: ---: Russian Intel/Mil, RUS 0803 USB CIS-3000 PSK-8 3000Bd followed by CIS MFSK-64 (32+32) (28Sep17) (AAI)
12193.0: ---: Russian Mil/Gov, RUS 1348 USB CIS-112 OFDM 112-tone 22.22Bd BPSK modem (14Sep17) (AAI)
12380.0: ---: Unid 1346 USB 3G-HF 2-way FLSU handshake / HDL6 transfer (25Sep17) (AAI)
12681.0: ---: Turkish Military, TUR 1200 USB FSK 200Bd/800Hz with KG-84C encryption followed by voice-comms, then short 188-110A Serial 75bps (19Sep17) (AAI)
13146.0: ---: Russian Navy, RUS 1411 (cf) CIS Navy "Akula", FSK 500Bd/1000 (29Sep17) (AAI)
13391.0: ---: Russian Intel/Mil, RUS 0700 USB CIS FTM-4, MFSK-4 150Bd (effective 37.5:Bd) 4000Hz modem (tones at: -6, -2, +2, +6 KHz) 8 mins lasting (26Sep17) (AAI)
14570.0: ---: Unid, prob. Ukrainian Net, 0654 USB 6 x 100Bd/120Hz VFT, 1 out of 6 (27Sep17) (AAI)
16619.5: ---: Unid 1303 USB 4800Bd BPSK modem, 6 KHz bandwidth burst waveform, 120ms ACF (21Sep17) (AAI)
17453.1: N57: Chinese Military, 1400 USB 188-141A calling A99 (25Sep17) (AAI)

3 October 2017

MS-110A & S-4539 adaptive HF modem


Interesting proprietary adaptive HF modem spotted on 6670.0 KHz/USB. The modem uses a set of modified waveforms from 188-110A and STANAG-4539 and switches from 300bps (MS-110A) up to M4800 modes (S-4539) with constant modulation rate of 2400 symbols/sec. Note the presence of the four initial tones in each transmission which are non provided in the mentioned standards.
The link between the caller/called nodes "CAMP" and "OUTPOST" is established and terminated using 2G-ALE MS-141A. Both these callsigns are unknown to me, since their literal meaning they could probably belong to a military-like organized staff, probably Swiss Army or Swiss Emergency, but so far there is no confirmation about.

Fig. 1 - a MS-110A transmission
Fig. 2 - a S-4539 (MS-110B) transmission
Me and KarapuZ investigated the bitstream after the removal of the overheads due to the bearer HF waveforms and found a 128-bit period protocol which exhibits the constant 40-bit sequence 
1111111110111111111111101111011111110110
in the preamble of each transmission (no matter if MS110-A or S-4539).

Fig. 3
After synched the stream on that (supposed) sync sequence, we found  four times repeated 88-bit structures that look like a 88-bit key encoder: probably the (4-times repeated) 80-bit sequences act in the same way of the initialization vectors in KG-84 encrypted data blocks.

Fig. 4





30 September 2017

Chinese PSK-2 ...and errors in its baud rate measurement

Some days ago I had a talk (...email exchange) with my friend KarapuZ about the way to get correct measurements of the baud rate in noisy signals or in uncommon waveforms. I always relied on the tools provided by SA program as the "Auto define param" and mostly the amplitude detectors, but KarapuZ warned me that sometimes they may fail and notably the "Auto define param" tool fails in case of strictly filtered or weak signals.
As a test, KarapuZ sent me a sample (the "x-Bd" wav file in Figure 1) without specify its baudarate and asking me to measure it.

Fig. 1
I used the "Auto define" tool and the modified amplitude detector searching for the lower more bright line and got a baud rate of 1000 symbols/sec in both their outputs (Fig. 2).
 
Fig. 2
KarapuZ replied: "The speed line of manipulation is 1500 baud unchanged in the preamble! This is a Chinese PSK-2 modem". 
Indeed, in my measurement I simply took in consideration the lower line - as usual - and did not put attention to the discontinuity in the 1000 Hz (999.44) line between preamble and data segments (Figs. 3,4). Really a my hasty measurement (I already had this signal but I forgot).

Fig. 3
Fig. 4
KarapuZ also drawn my attention on the "raster" of the signal that clearly exhibits 15 bits within 10 msec, ie a speed of 1500 baud (Fig. 5)

Fig. 5
Apart from my error in the evaluation of the amplitude detector, why the SA "Auto define param" failed so clumsily?
Quoting KarapuZ "it can be assumed that in the transmitting equipment, filters are used at the output of the signal formation which in some circumstances may influence the determination of the speed of the manipulation of the SA program." So, in order to demonstrate the influence of the filtering in the Chinese PSK-2 signal, KarapuZ synthesized an absolute PSK-2 modulation at 1500 baud with the same 3-bit structure of the Chinese waveform and sent me that file (Fig. 6)

Fig. 6
Then I measured the manipulation speed of the syntesized signal just using the "Auto define param" and it works like a charm.

Fig. 7
 The influences of the filtering is thus well quantifiable (other than visible)

Fig. 8
Things are even more worse since the bitstream  has a relative form and a three-bit structure, visible in raster, which generates many harmonics in the power spectrum! This is China, they love such tricks :)

Fig. 9
Fig.10
Thanks to KarapuZ for the great lesson!

Nokia M/90 (Panasonic CF-U1): FSK 301-151Bd 780Hz shift

I reported Nokia M/90 / Panasonic CF-U1 301-401Bd/780Hz in this post, this time I copied the 301-151Bd waveform on 10737.7 KHz (cf) around 1235 UTC. In this sample the initial 301Bd burst seems to be used with a different functionality (fig. 1).
Sanomalaite M/90 (SANLA) (Literally "Message device M/90") is a digital, portable and encrypted text-based communications device developed by Nokia and used by all branches of Finnish Defence Forces. From 2013 onward, these devices are being replaced with Panasonic CF-U1 Toughbook.
 
Fig. 1
Note that also in this case, the preamble is always modulated at 301Bd (fig. 2).
 
Fig. 2
For what concerns the characteristics of the demodulated stream, refer to the mentioned post.



https://yadi.sk/d/DhKXi9ga3NLzFg