23 May 2018

French Navy Broadcast, FSK 50Bd/850

Following the previous post, I decided to analyze the French FSK 50Bd/850 in order to replicate the results obtained by my friend Christoph Mayer in his blog: happy to say that the results coincide.


French-Ny FSK 50Bd/850 has a characteristic 21-bit period and, in a way similar to STANAG-5065, two/three sub-frames which are delimited by the bits of two LFSR markers M1 M2 and a logical "1" value bit (1-bit). The sequences for the two markers are generated by the polynomials x^6+x^5+1 and x^7+x^6+1.
Since the missing of an initial sync in the recording, the 1-bit can occur in any position within the 21-bit frame therefore markers' positions are reported as relative to the 1-bit. A possible more significative layout shows 2 possible sub-frames (5 and 13 bits length).



 
Obviously, the length of the markers' patterns match the length of the respective generator polynomials.

 

22 May 2018

Exploring FSK 50Bd/850 transmissions for STANAG-5065 and KW-46 encryption

Although STANAG-5065 indicates the standards required for naval LF shore-to-ship broadcast with KW-46 encryption devices [1], some implementations of this standards can also be found in HF waveforms such as the FSK 50Bd/850. I came up with the idea to depeen after reading an interesting Christoph Mayer' post (by the way, a next post will deal with French Navy 21-bit period FSK-50Bd/850).

Quoting STANAG-5065 Annex A, BASEBAND PROCESSING [2]: 
"Encryption and decryption sall be provided by KW-46 interoperable cryptographic equipment operating in the 6.0 Stepped Digital mode. Encryption by the KW-46 equipment sall be coded in the 7-0 unit SART-TOP ITA2 alphabet. Encryption by the KW-46 equipment will result in bits 1 through 6 being encrypted and bit 7 (STOP) being replaced with an unencrypted and deterministic Fibonacci bit", where "Fibonacci bits = Deterministic unencrypted bits used by the KW-46 interoperable cryptographic equipment to provide synchronization defined by the polynomial x^31+x^3+1."


7-bit frame delimited by KW-46 sync bit
x x x x x x KW-46
1 2 3 4 5 6 7

The goal was to arrange the demodulated bits (courtesy of Christoph) into a 7-bit format stream and then process each column of the stream in order to find a descrambler polynomial - if any - that was the same as the one indicated in STANAG-5065 standard. As expected, only the bit-7 column can be successfully descrambled using the polynomial x^31+x^3+1.


As seen,  STANAG-5065 and KW-46 can be meet also in HF secured naval broadcasts with the commonly used FSK waveform 50Bd/850Hz. For what concerns the users, such signals were recorded on 4905, 4985, 7455 and 16123 Khz (all CFs) using KiwiSDRs located at DF0KL and at Newport,OR: user is probably US Navy.



 [1] In the late 1980's, the KW-46 simplex cryptosystem was introduced in order to provide communications security (COMSEC) for naval broadcasts to naval fleets (Fleet Broadcast). Formally, this equipment is called "Fleet Broadcast Security Equipment, TSEC/KW-46". The  KW-46 consists of the KWT-46 transmitter and the KWR-46 receiver (code name Vallor).

[2] STANAG-5065 Annex A

 

16 May 2018

MIL 188-220 Appendix D, standards for COMSEC transmissions

A recent post in radioscanner (my nickname is "ansanto" there), and some interesting discussions with a friend of mine, gave me the opportunity to study that signal and deepen the theme that is dealt with by MIL 188-220. In particular, the signal in question (courtesy by KarapuZ) concerns a transmission with link encryption provided by external COMSEC devices, in accordance with what is reported in the Appendix D of the cited standard, ie "transmission frame structure in either external and embedded COMSEC modes".

In short, in external COMSEC transmission frame the clear-text (not encrypted) part of the transmission frame is the "COMSEC Preamble", depicted below, which consists of the subfields: 
a. COMSEC Bit Synchronization
b. COMSEC Frame Synchronization
c. Message Indicator (MI)



The COMSEC Frame Synchronization subfield is used to provide a framing signal indicating the start of the encoded MI to the receiving station. This subfield is 465 bits long, consisting of 31 Phi-encoded bits. The Phi patterns are a method of redundantly encoding data bits. The logical data bits 1 and 0 are encoded as shown in figure. 


The Message Indicator subfield (MI) contains the COMSEC-provided MI, a stream of random bits that are redundantly encoded using Phi patterns.

Alternatively, in the embedded COMSEC transmission frame the clear-text part, depicted below, is composed of the following components:
a. Phasing
b. Frame synchronization (Standard Frame Sync or Robust Frame Sync)
c. Robust Frame Format (RCP only)
d. Message Indicator (MI)
 


Back to the signal, it was heard by KarapuZ in the 33 MHz band and it is a GFSK modulation at a rate of 16000 Baud that can be easily processed using SA (Fig. 1).

Fig. 1
Once demodulated it turns out to be a transmission with link encryption provided by external COMSEC: indeed, the COMSEC Preamble can be easily identified as well as the three subfields Bit Synchronization, Frame Synchronization and Message Indicator (Fig. 2).

Fig. 2 - COMSEC Preamble
The use of the redundant 15-bit encoding is shown in Figure 3

Fig. 3
Since 188-220 is based on the VINSON algorithm, the used encryption is presumably KY-57 and taking into account the band where it was listened... everything points to the SINCGARS radio (Single Channel Ground and Airborne Radio System) [1]. By the way, a dear friend of mine sent me a 188-220 recording but once demodulated it uses 16 bits encoding patterns frames instead of 15 bits ones (Fig. 4). "I guess it is some modern crypto using a backwards compatibility mode, the clue is that it could be KY-99 that is the replacement for KY-57 in SINCGARS, but that point is unconfirmed. More signals and work will be necessary to clarify these points", my friend says. 

Fig. 4
It is interesting to see how NATO KG-84 encryption relates to 188-220 Appendix D (Fig. 5).
KG-84 is similar to the emebedded COMSEC transmission frame, although the 64-bit pattern of KG-84 Standard Frame sync 
1111101111001110101100001011100011011010010001001100101010000001
is different from the patterns reported in Appendix D for Standard and Robust Frame sync. Moreover, the Message Indicator is not encoded using the Phi 15 bits, although it is redundantly encoded. That's probably ok since KG-84 is based on SAVILLE algorithm and 188-220 is VINSON based. Note as in some KG-84 "detectors" the Standard Frame sync is termed as "SYNC" and the MI data as "Initialization vectors".

Fig. 5 - NATO KG-84 encryption and 188-220 embedded COMSEC
The Turkish-Mil FSK, also using KG-84, deserves aside consideration (Fig. 6). Perhaps they encode the Mesage Indicator field using Golay and do not use redundant n-bit encoding, but it's only IMO. However "the encoding with Phi patterns is used for backward compatibility", 188-220 says.

Fig. 6 - Turkish-Mil FSK and 188-220 embedded COMSEC
As a final note, the Russian waveform Makhovik has many similarities with the transmission frames described in 188-220.
(to be continued)

[1] http://www.cryptomuseum.com/radio/sincgars/

12 May 2018

unid PSK-8 bursts systems (heard recently)

8040.0/usb 0755z 188-110A Serial, long sequence of 1200ms bursts (noise by adiacent Northwood HF-fax) bearing the same sequence




https://yadi.sk/d/WcrZVwFU3VkzfT 

11072.0 CF PSK-8 2800Bd, two stations exchanging 700ms bursts. The waveform fas a period of 140 symbols, most likely 40 symbols are used for mini-probes and 100 symbols for data. Bursts start and end with a short 2500Hz tone.



 

7 May 2018

Telsy/Q-MAC MPSK 30+1 48.8Bd 60Hz
i56578, DF3LZ,KarapuZ


Radio-check bewteen voice callsigns GAMMA 130 and ROSTRO 530 (respectively It-GdF shore station and patrol-boat) followed by short MPSK blocks, most likely digital voice.  
The MPSK signal occupies a bandwidth of ~2280Hz and has a FSK-2 600Hz shift preamble lasting 150ms (Fig. 1). Except for the 1st block, the FSK preambles of the following 3 blocks are similar. The 30 tones are 60Hz spaced: in the lower group of 20 tones the π/4-DQPSK modulation at 48.8Bd is used; in the upper group of 10 tones, a mix of modulations (MFSK, DBPSK and π/4-DQPSK) at same 48,8Bd speed is used (Fig. 2).

Fig. 1
Fig. 2 - upper group of 10 tones (credits to KarapuZ)
The tone in between the two groups is modulated using DBPSK2 at 48.8Bd (same speed as above) and is used for for synch purposes. The 3 blocks have the same sequences transmitted in the sync channel (Fig. 3). 

Fig. 3


This signal is similar to the Q-MAC HF modem waveform reported by radioscanner, except for the presence of the FSK preamble (Fig. 4). Indeed, a DXer from UDXF suggested the  Telsy TCH01c  rather than Q-MAC modem. Quoting form Telsy documentation [1]: "The TCH01c – Telsy Crypto Handset – is a unique and sophisticated encryption unit, combining an encryption module, a vocoder and a modem in a single handset."  Well, in August 2009 Barrett Communications has announced its acquisition of Q-MAC Electronics:
http://www.barrettcommunications.com.au/.../
and it's interesting to note that Barrett recommends the Telsy TCH01c crypto handset for some of their transceivers:
http://www.italponti.it/_files/download/allegati/2090.pdf
That said, perhaps Telsy embeds the modem in their handset using a Q-MAC/Barret EOM license? I emailed Telsy but I did not have any reply.
 
Fig. 4 - signal by radioscanner (upper) and the signal being analyzed

It's also interesting to note that the digital signal was preceded by the following comms:
GAMMA 160: let's have a try with a 'passage' in red, I'll take you
ROSTRO 530: yes go ahead, take me up
usually "red" stands for not encrypted transmissions so it seems that they used a clear-text transmission for the modem check.


2 May 2018

188-110C/D Appendix D, waveform Id 0 (ortogonal Walsh modulation)

9213.0/usb: 188-110C/D Appendix D waveform Id 0 (WID0) using ortogonal Walsh modulation in preamble section and in data blocks. The use of this waveform leads to think to poor channel conditions...




Symbols are scrambled to appear as PSK-8 on-air, symbol-rate 2400Bd.




audio recording (wav): https://yadi.sk/d/N9979JiT3VAbtW
binary stream after PSK-8 demodulation: https://yadi.sk/d/iwgDYrr73VAcCj 

26 April 2018

UUCP protocol 'conversations' over HF (BPOL)

This post is intended to complete some previous analysis of the protocols used by the German BPOL for their HF ship-shore communications which are based on the R&S implementation of the X.25 protocol and the proprietary R&S GM-2100 modem signal format: the scenario is shown in Figure 1:
- the HF layer protocol (GM-2100 modem) was discussed here
-  RS X.25 protocol and HF link establishment was discussed here
UUCP protocol, who sits on top of RS X.25 , is discussed in this post thanks to a friend of mine who pointed my attention on the upper application layer and gave a big help and contribution in UUCP protocol analysis. 

Fig. 1
UUCP (Unix-to-Unix copy) [1] suite is a set of computer programs and protocols that allow for the remote execution of commands and the transfer of email and files between computers, in this scenario it is used over X.25 and HF-link. The UUCP bitstream (uucp-over-hf.bin)  is obtained after the removal of X.25 overhead and it's edited using the XVI32 hex editor [2]: a XVI32 screenshot is shown in Figure 2.

Fig.2 - XVI32 editor
A UUCP session (termed "conversation") consists of three parts: an initial handshake, a series of file transfer requests, and a final handshake. Before the initial handshake, the caller will usually have logged in the called machine and somehow started the UUCP there: since they use the UUF Index "00000000000111" during the 2G-ALE handshake, most likely UUCP is started at the "dial in" stage by means of the command User Unique Function in the 188-141A message section [3]:

(to)BPLEZS (cmd)|[nul][bel] (tis)BP23
1111100 0000000 0000111
 
The initial part concerns the "login", probably the tags  <MPL></MPL> and <SPL></SPL> are XML markers.

0A 0D 0A 6C 6F 67 69 6E 3A 20 55 42 50 4F 4C 42 50 4C 45 5A 53 45 45 5F 48 46 0A
. . . login: U BPOLBPLEZSEE_HF .
3C 4D 50 4C 3E 32 30 31 36 2D 31 31 2D 32 38 20 31 35 3A 34 39 3A 35 32 2B 30 31 2C 42 50 4F 4C 42 50 32 33 3B
<MPL> 2016-11-28 15:49:52+01,BPOLBP23;
32 30 31 36 2D 31 31 2D 42 50 4F 4C 42 50 4C 45 5A 53 45 45 5F 48 46 0A 0D 20 31 35 3A 34 39 3A
2016-11-BPOLBPLE ZSEE_HF .. 15:49:
35 32 2B 30 31 2C 42 50 4F 4C 42 50 32 33 3B
52+01,BPOLBP23;
32 30 31 36 2D 31 31 2D 32 38 20 31 35 3A 34 37 3A 34 35 2B 30 31 2C 42 50 4F 4C 42 50 32 36 3C 2F 4D 50 4C 3E 0A
2016-11-28 15:47: 45+01,BPOLBP26</MPL> .
42 50 4F 4C 42 50 4C 45 5A 53 45 45 5F 48 46 0A 0D
BPOLBPLEZSE E_HF ..
20 31 35 3A 34 39 3A 35 32 2B 30 31 2C 42 50 4F 4C 42 50 32 33 3B
15:49:52+01,BPOLBP23;
32 30 31 36 2D 31 31 2D 3C 53 50 4C 3E 32 30 31 36 2D 31 31 2D 32 38 20 31 35 3A 34 37 3A 34 35 2B 30 31 2C
2016-11-<SPL>2016-11-28 15:47:45+01,
42 50 4F 4C 42 50 32 36 3C 2F 53 50 4C 3E 0A
BPOLBP26</SPL> .
43 6F 6E 6E 65 63 74 65 64 0A
Connected .

All messages in the initial handshake begin with a `^P' (a byte with the octal value \020, hex  0x10) and end with a null byte (octal \000, hex 0x00) and it is begun by the called machine. The session can be parsed according to: 

10 53 68 65 72 65 3D 42 50 4F 4C 42 50 32 33 5F 48 46 00
10 – UUCP initial handshake message start
Shere = – called hostname = BPOLBP23_HF
00 – UUCP initial handshake message end

10 53 42 50 4F 4C 42 50 4C 45 5A 53 45 45 5F 48 46 20 2D 70 7A 20 2D 76 67 72 61 64 65 3D 7A 20 2D 52 20 2D 4E 30 37 00
10 – UUCP initial handshake message start
S – calling hostname = BPOLBPLEZSEE_HF
-pz - requests the called system to only transfer files of the specified grade or higher = z
-vgrade=z - requests the called system to only transfer files of the specified grade or higher = z (grades in UUCP links means 'priorities')
-R - calling UUCP understands how to restart failed file transmissions. Supported only by System V Release 4 UUCP, so this is a System V release.
- N07 - calling UUCP understands the Taylor UUCP size negotiation extension (only for UUPlus, so this is UUPlus)
07 = 000111 – options (in octal)
xxxxx1 – UUCP support size negotiation
xxxx1x – UUCP supports file restart
xxx1xx – UUCP supports ‘E’ command
00 – UUCP initial handshake message end

10 52 4F 4B 4E 30 37 00
10 – UUCP initial handshake message start
ROKN07 – called station acknowledgement of ‘R’ options. The calling UUCP is acceptable, it specified `-N', and the called UUCP also understands the Taylor UUCP size limiting extensions
00 – UUCP initial handshake message end

10 50 79 69 65 00
10 – UUCP initial handshake message start
50 – P = called station supports the following UUCP protocols y, i, e
00 – UUCP initial handshake message end

10 55 79 00
10 – UUCP initial handshake message start
55 – U = The calling UUCP selects which protocol to use out of the protocols offered by the called UUCP
in this case calling station supports the UUCP protocol 'y' (0x79)
00 – UUCP initial handshake message end

 UUCP ‘y’ protocol (uucico Zmodem protocol) starts here, first packet with pkt number = 0 is a ‘sync’ packet
 
00 00 04 00 10 00 01 04 00 00
00 00 – pkt number (little endian) = 0
04 00 – pkt length (little endian) = 4 Bytes
10 00 – check sum (little endian)
01 – version = 1
04 – max pkt size = 32768/4 = 8192 Bytes
00 00 – flags = none defined
/* trailing 0x00 missing */

01 00 03 00 B8 01 48 4E 00
01 00 - pkt number = 1
03 00 – pkt length = 3 Bytes
B8 01 - check sum
48 = ‘H’ hang up command/command response O
4E = ‘N’ = Slave does not agree to hang up
00 – end of pkt
 
02 00 3D 00 19 23 45 20 44 2E 30 35 50 4B 20 44 2E 42 50 4F 4C 42 50 32 43 30 35 50 4B 20 75 75 63 70 20 75 75 63 70 20
02 00 - pkt number = 2
3D 00 – pkt length = 61 Bytes
19 23 - check sum
45 – ‘E’ command
44 2E 30 35 50 4B 20 – file to send = D.05PK
44 2E 42 50 4F 4C 42 50 32 43 30 35 50 4B 20 – file name on slave = D.BPOLBP2C05PK
75 75 63 70 20 – user or application requesting the file transfer = uucp

2D 43 20 44 2E 30 35 50 4B 20 30 36 36 36 20 22 22 20 30 78 36 36 20 72 73 67 70 73 61 64 64 00
2D 43 20 – option: file has been copied to the spool directory = C
44 2E 30 35 50 4B 20 - if the `C' option appears in options, this names the file to be sent = D.05PK
30 36 36 36 20 - mode of file on master; if UUPlus always = 0666 for outgoing files
22 22 20 – notify = "" = notification not enabled
30 78 36 36 20 – file size = 0x66 = 102 Bytes
72 73 67 70 73 61 64 64 – command to be executed = rsgpsadd
(my friend guess is that this is an application on the slave which adds GPS data to a file or data base (rsgpsadd = R&S GPS ADD?) 
00 - end of pkt 
 
02 00 83 21 66 5A 29 76 4C 40 AC 93 34 6D 98 DF D0 7B
/* is this noise or …? */

03 00 66 00 E3 13
03 00 – pkt number = 3
66 00 – pkt length = 0x0066 = 102 Bytes
E3 13 – check sum
/* BZIP’ed data follows */
42 5A 68 39 31 41 59 26 53 59 31 B5 92 5D 00 00
15 DE 00 00 10 40 0F 7F F0 10 04 C0 00 20 00 40
94 44 C9 B4 8D EA 21 A1 40 D3 43 23 26 24 08 8B
AE 1A 62 1D B0 EF 05 4D 67 25 41 08 B0 A8 3D 51
B2 9C 96 C3 74 66 4E AB 06 83 94 21 E4 D1 AB 4D
EF C3 44 66 9E 13 F8 E8 D9 A3 61 F8 BB 92 29 C2
84 81 8D AC 92 E8

04 00 00 00 FF FF
04 00 – pkt number = 4
00 00 – pkt length = 00 00 /* this indicates end of file */
FF FF – check sum /* because no data bytes are present, the checksum is set equal to its initial setting */

16 B0 F9 F5 37 DE DC 29 AE 6D 48 D4 1F 34 B5 D6 5E 00 FF A4
/* is this noise or …? */

05 00 02 00 8E 00 48 00
05 00 – pkt number
02 00 – pkt data length
8E 00 – checksum
48 – ‘H’ command from master to hang up connection
00 – end of command pkt

05 00 03 00 CE 01 48 59 00
05 00 – pkt number
03 00 – pkt data length
CE 01 – checksum
48 59 – ‘H’ command, ‘Y’ = agrees to hang up the connection
00 – end of pkt

06 00 03 00 CE 01 48 59 00
06 00 – pkt number
03 00 – pkt data length
CE 01 – checksum
48 59 – ‘H’ command, ‘Y’ = agrees to hang up the connection
00 – end of pkt

After the protocol has been shut down, the final handshake is performed. This handshake has no real purpose, and some UUCP packages simply drop the connection rather than do it (in fact, some will drop the connection immediately after both sides agree to hangup, without even closing down the protocol). 
In the final handshake, the calling UUCP sends six letter O's and the called UUCP replies with seven letter O's. Some UUCP packages always send six O's.

10 4F 4F 4F 4F 4F 4F 00
10 – UUCP final handshake message start
4F 4F 4F 4F 4F 4F – final handshake caller closing sequence = OOOOOO
00 – end of final handshake message

10 4F 4F 4F 4F 4F 4F 00
10 – UUCP final handshake message start
4F 4F 4F 4F 4F 4F – final handshake caller closing sequence = OOOOOO
00 – end of final handshake message

10 4F 4F 4F 4F 4F 4F 4F 00
10 – UUCP final handshake message start
4F 4F 4F 4F 4F 4F 4F – final handshake called closing sequence = OOOOOOO
00 – end of final handshake message

10 4F 4F 4F 4F 4F 4F 4F 00
10 – UUCP final handshake message start
4F 4F 4F 4F 4F 4F 4F – final handshake called closing sequence = OOOOOOO
00 – end of final handshake message






22 April 2018

Logs, 20 Mar - 22 Apr


04593.0: RDP: Saudi Air Force, ARS 2108 USB 188-141A, calling DAI (23Mar18)
05553.2: ---: Unid 2120 USB STANAG-4285 1200bps/L modem, unid 1536-bit secondary protocol (prob. TDM system) (23Mar18)
06234.0: ---: Unid 2100 STANAG-4285 600bps/L modem, async operation (encrypted ITA2, framing 5N1.5) (31Mar18)
06407.0: WL01: Algerian Military, ALG 1529 USB MIL 188-141A, calling NX01 (10Apr18)
06600.5: HBLZDRD1: Roumenian Military, ROU 0915 USB 188-141A, calling HFJCDRD1 (23Mar18)
06840.0: BOSOX: Unid 1452 USB 188-141A, sounding (29Mar18) (AA)
06840.0: R26452: US Military 92-26452 Sikorsky UH-60L Black Hawk 1445 USB 188-141A, handshake w/ BOSOX, short op-chat (29Mar18) (AA)
06849.5: ---: Unid, prob. Russian Air Force 0650 (cf) FSK 100Bd/2000, idling (10Apr18)
07690.0: 9002: Unid 1709 USB mil 188-141A, calling 9001 (04Apr18)
07703.0: WI2XER: possibly Skycast ERS 2129 USB 30 unmodulated tones, 100Hz spaced, lasting 20.7 secs and followed by Morse ID “WI2XER” (16Mar18)
07732.0: A98: presumed Chinese-Diplo net, CHN 1710 USB MIL 188-141A, calling E56 (04Apr18)
07823.0: GR2ORX: Sonatrach GR2 Pipeline, ALG 1718 USB MIL 188-141A, sounding (10Apr18)
08089.0: HL: Unid 1638 USB Arab voice comms with callsigns AZ, JU, FT / STANAG-4197 ANDVT modem (10Apr18)
08092.0: 362013: Turkish Civil Defence, Erzincan District, TUR 1711 USB MIL 188-141A, calling 304013 Agri District (04Apr18)
08104.75: ---: Unid, prob. Russian Mil/Gov 0805 (cf) FSK 50Bd/1000, idling (27Mar18)
08151.0: TYMT2: Guardia Civil Toledo, E 1711 USB MIL 188-141A, sounding (04Apr18)
08171.0: Russian Intel/Mil, RUS 0910 USB CIS FTM-4, MFSK-4 150Bd (effective 37.5:Bd) 4000Hz modem (tones at: -6, -2, +2, +6 KHz) (28Mar18)
08182.0: XFZ: UK-DHFCS 1331 USB 188-141A calling XNM (22Apr18)
08190.0: INZUCC: Guardia di Finanza Patrol Boat Inzucchi G118, I 1003 188-141A, calling PALERMO (18Apr18)
08707.7: HWK01: Swedish Armed Forces, S 0807 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, Circuit Mode tfc, S5066 unid UDOP client protocol delivering 2 blocks of ciphered text (12Apr18) 
09079.0: ---: Unid 1709 USB 3G-HF 2-way FLSU handshake / HDL24 transfer (28Mar18)
09206.0: ---: Unid USB WBHF MIL 188-110D App.D, 4800Bd 6KHz bursts, scrambled BPSK (WId 2). Linking with 3G ALE extensions for wideband (3GWB) (12Apr18)
09210.0: ---: Unid USB WBHF MIL 188-110D App.D, 7200Bd 9KHz bursts, Walsh modulation (WId 0). Linking with 3G ALE extensions for wideband (3GWB) (12Apr18)
09295.0: TXFA8: Spanish Police, E 1009 USB 188-141A, calling TZCP1 (16Apr18)
09540.0: ---: Russian Gov/Mil (?), RUS 0947 USB "Tandeme" system tests, MFSK-56/23 25/62Bd 2500 msec bursts on 9540, 9584, 9636 KHz. Also noted before CIS-79 OFDM (20Mar18)
09909.0: HA2: Polish Military, POL 1002 USB 188-141A, calling KR4 (28Mar18)
09909.0: HA2: Polish Military, POL 1006 USB 188-141A, handshake w/ TE5, no follow-on (28Mar18)
09909.0: HA2: Polish Military, POL 1010 USB 188-141A, calling TA6 (28Mar18)
09909.0: HA2: Polish Military, POL 1017 USB 188-141A, calling ST8 (28Mar18)
09909.0: TA6: Polish Military, POL 1000 USB 188-141A, calling JU9 (28Mar18)
09909.0: TA6: Polish Military, POL 1002 USB 188-141A, calling JA4 (28Mar18)
10185.0: X44: Moroccan Military, MRC 0820 USB 188-141A, sounding (18Apr18)
10222.0: Unid 1100 USB MFSK-6 (3-out-of-6) 100Bd/400Hz modem, lasting 11 mins (28Mar18)  [1]
10284.9: GR2ORX: 1638 LSB 188-141A, sounding (28Mar18)
10480.0: CENTR2: Rou-MAECT Centrala2 Bucharest, ROU 0825 USB 188-141A handshake KOW (Copenhagen embassy) / 188-110A bearing S5066 HBFTP email (18Apr18)
10576.0: 739: Unid 1547 USB 188-141A calling 195 (22Apr18)
12215.0: ---: Russian Mil/Gov, RUS 0934 USB CIS-45 HDR modem v1, OFDM 45-tone 33.33Bd PSK-2 (23Mar18)
13005.0: ---: Unid 1333 USB 3G-HF 2-way FLSU handshake / HDL+ transfer (05Apr18)
13032.0: ---: Rus Mil, RUS 1240 (cf) FSK/Morse flash message "XXX XXX WEGI WEGI 23327 36051 STOKOBOJ 4724 4957 K" (08Apr18)
13215.0: 538883: Unid  1047 USB MIL 188-141A, sounding (05Apr18)
13371.5: HO32: Russian Mil/AF, RUS 0809 (cf) weird Morse/FSK/1000Hz (100Bd idling) "FD68 DE HO32 QSA? K" (27Mar18)
13446.0: FC1: FEMA NRS (FNARS) Net Region 1, US 1300 USB MIL 188-141A, calling ME1FEM (05Apr18)
13905.5: WI2XER: possibly Skycast ERS 1504 USB 30 unmodulated tones, 100Hz spaced, lasting 20.7 secs and followed by Morse ID “WI2XER” on 13907.2 (05Apr18)
13960.0: ---: Ukrainian Net 1227 (cf) F7B mode system 100Bd/2000, tones at -1500, -500, +500, +1500 (16Apr18)
14445.0: OEB: Algerian Air Force Oum El Bouagh, ALG 0933 USB MIL 188-141A, sounding (09Apr18)
17422.0: ---: Rus Gov/Mil, RUS 1006 USB CIS-112, OFDM 112-tone 22.22Bd BPSK modedm (05Apr18)