16 July 2018

LINK-11 CLEW, conventional waveform


The 16 tone frequencies used by CLEW are 605 Hz (used for Doppler correction), 2915 Hz (used for data and synchronization) and 935, 1045, 1155, 1265, 1375, 1485, 1705, 1815, 1925, 2035, 2145, 2255, and 2365 Hz. All information is conveyed by DQPSK modulation at symbol rate of 75 or 45.45 Baud of the 15 data subcarriers tones (Doppler tone remains unmodulated), each of the tone represents 2 data bits and then resulting in a total of 30 data bits consisting of Control Code frames and Data Message frames(M-series messages). The tone at 935 Hz corresponds to bit locations 0 and 1, last tone at 2915 corresponds to bit locations 28 and 29.
Sometimes you may see CLEW using simultaneously the USB and LSB (ISB): indeed, identical signals are transmitted on in ISB and at the receiver both the sidebands will be separately and independently deodulated.  A means is provided to allow operator selection of USB, LSB or the diversity operation (DIV) modes:
  • DIV: data words derived from the diversity combination of the USB and LSB will be provided to the tactical computer. This mode of operation is used to help combat multipath interference.
  • Automatic: the receiving station automatically selects the version that represents the best information available from the USB, LSB or DIV version of the received data word.
When the criteria do not establish a clear choice, the DIV version is selected.  

The three control codes which are used to operate a Link-11 net are the Start Code, Stop Code, and Address Code, each consisting of two encoded 30-bit frames. The Start Code is the first two frames of the transmitted data message while the two frames Stop Code immediately follows the last message frame to signify the end of the data. There are two stop codes according to the transmitting station: Control Stop Code (transmission from the data net control station, or DNCS) is a 2 frames consisting of all "zeros", and Picket Stop Code (transmission from a picket station) which consists of a 2 frames consisting of all "ones". 
The Start Code is the first two frames of the transmitted data message while the two frames Stop Code immediately follows the last message frame to signify the end of the data. There are two unique stop codes according to the transmitting station:
  • Control Stop Code (transmission from the data net control station, or DNCS) is a 2 frames consisting of all "zeros",
  • Picket Stop Code (transmission from a picket station) is a 2 frames consisting of all "ones".
Each net partecipating unit is identified by the Address Code which immediately follows the Control Stop Code if the DNCS transmits data.

Fig. 1 - Link-11 data segment
I have a problem about the statement of page 19 in 188-203-1A: they say that Start and Address codes "...are equivalent to 60-bit portions of the maximun length shift register sequence with generator polynomial G(x) =  x^5+x+1" but a fifth grade polinomyal has a maximum length of 31! Actually  I found the polymonial: x^6+x+1 for both start and address codes. I wonder if there is a typo in this MIL-STD.

The Data Message frames (Figure 2) follow the Start Code and contain tactical information. Each Data Message frame consists of 30 bits composed of a 24-bit word provided by the tactical computer and 6 Hamming parity bits (bit locations 24 through 29) provided by the modem. The Hamming parity bits are used by the receiver modem for error detection and correction, for this reason they are also refferred to as EDAC bits. Only Data Messages contain Hamming parity bits: Start, Stop, and Address codes are not Hamming parity encoded.
Notice that the 24-bit words may be optionally encrypted using KG-40 crypto device which just sits in midlle between tactical computer and modem. 

Fig. 2 - Link-11 Data Message frames
The six EDAC bits are encoded as follows:
  • Bit 29 is set such that when added to bits locations in 11 through 23, the number of ones will be an odd number;
  • Bit 28 is set such that when added to bits locations in 4 through 10 and 18 through 23, the number of ones will be an odd number;
  • Bit 27 is set such that when added to bits in locations 1,2,3,7,8,9,10,14,15,16,17,22, and 23, the number of ones will be an odd number;
  • Bit 26 is set such that when added to bits in locations 0,2,3,5,6,9,10,12,13,16,17,20, and 21, the number of ones will be an odd number;
  • Bit 25 is set such that when added to bits in locations 0,1,3,4,6,8,10,11,13,15,17,19,21, and 23,the number of ones will be an odd number;
  • Bit 24 is set such that when all the bits of the frame are added, the number of ones will be an odd number. Bit 24 is called the overall parity bit. 
Figure 3 shows a check of the first six 30-bit frames of the Data Message in Fig.2

Fig. 3

For who loves GNU Octave,  my friend Christoph wrote a macro just to check Hamming parity in Link-11 Data Message frames:

## -*- octave -*-
function a=check_link11(fn)
  fid = fopen(fn);
  s=[];
  try
    i=1;
    while true
      s(i++,:)=fgetl(fid);
    end
  end
  fclose(fid);

  a = s=='1';
  ## reverse order
  a = a(:, end:-1:1);

  ## constraints
  k{1} = [1:30];
  k{2} = [1 2 4 5 7 9 11 12 14 16 18 20 22 24 26];
  k{3} = [1 3 4 6 7 10 11 13 14 17 18 21 22 27];
  k{4} = [2:4 8:11 15:18 23 24 28];
  k{5} = [5:11 19:24 29];
  k{6} = [12:24 30];

  for i=1:6
    x(i,1) = sum(mod(sum(a(:,k{i})'),2) == 1);
  end
  x /= size(a,1);

  printf('success: %d %.2f%%\n', [[1:6]' 100*x]');
endfunction

12 July 2018

MFSK-32 & OFDM 60-tone, a new "Serdolik" waveform ?


Interesting transmissions centered on 7659.0 KHz (7657.0/usb as tuning frequency) and picked up with a  KiwiSDR located in Northen Norway (Kongsdr).
Transmissions consist of MFSK-32 87Bd/97Hz and OFDM 60-tone 40Bd BPSK bursts, start and initial bursts likely act as  SOM/EOM and use a QPSK/PSK-8 2400 Bd modulation with 20ms ACF (ie 48 symbols). Both MFSK and OFDM bursts  are separated by 1900 ms and last 6000ms; the occupied bandwidth is about 3200Hz.
The OFDM bursts use the same MFSK-32 waveform as preamble and exhibit a clear 100ms CCF. Note the lack  of the usual 3300 Hz pilot tone. 
Likely it's a new waveform belonging to "Serdolik" family.

Fig. 1- MFSK-32 burts
Fig. 2 - OFDM 60-tone bursts
Fig. 3 - initial/final burst (SOM/EOM?)

Run a TDoA multilateration which showed Moscow area as the origin.

Fig. 6


11 July 2018

110A & S4539 data transfers

06690.0/usb 0627z: two unid stations in simplex exchanging KG-84 encrypted msgs using 188-110A  and S4539 waveforms. The exchanges were repeated several times during the morning w/out ALE handshake neither voice-comms before the init of transfers.

Fig. 1
Fig. 2
Probably a modems set-up like the one in Figure 3 was used

Fig. 3

9 July 2018

CIS-12 & CIS Selcall FSK 150Bd/200 ("Vishnya")


Interesting and quite rare CIS-12 & CIS Selcall FSK 150Bd/200 - aka "Vishnya" - picked up by my friend AngazU using northern Europe KiwiSDRs in the 5 MHz band. Also thanks to friends cryptomaster and KarapuZ for pointing  out the name of the FSK signal and some interesting links: actually I met only single CIS "Vishnya" selcalls some months ago (November 2017) but I forgot it
http://i56578-swl.blogspot.com/2017/11/cis-selcall-vishnya-fsk-150bd200.html
CIS selcall is mentioned here in radioscanner:
http://signals.radioscanner.ru/base/signal106/
http://signals.radioscanner.ru/base/signal251/

It's notice that:
a) before the moment of transfer of CIS-12 signal, the equipment correctly stops transmission and also correctly restarts it after transferring the selcall;
b) since CIS-12 has a pilot tone at 3300Hz, the FSK insertions are centered on the suppressed carrier (zero offset from the nominal frequency);
c) after demodulation, CIS selcall exhibits a 45-bit period.

Fig. 1
Fig. 2
Fig. 3
UTE listeners frequently refer to a waveform using the name of the source equipment: in this case the nickname "Vishnya" comes from R-016V "Вишня" equipment, or R-016V "Vishnya" using the latin alphabet, which stands for the English "Cherry"  (Fig. 4).

Fig. 4 - R-016V "Вишня"

6 July 2018

Link-11 SLEW, KG-40A encryption (tentative)

TADIL-A/Link-11 SLEW half-duplex transmissions spotted on 8223.5/usb (July, 3). Demodulated stream has a 252-bit period that likely is due to KG-40A, a crypto device which is just used to provide cryptographic security for Link 11 communications. If so, the structure of the COMSEC preamble should consist of 7 x 252-bit encoded Message Indicator followed by 96-bit sequence of "10" (phasing or time to load the key).

 
Link-11 SLEW 252-bit period

The KG-40A interfaces between a computer and a data terminal, and operates in accordance with control signals from those two units. The KG-40A can be wired two different ways for use in Naval Tactical Data Systems (NTDS) and Airborne Tactical Data System (ATDS) systems. The KG-40AR is a "form, fit and function" replacement for the now obsolete KG-40A cryptographic equipment.
http://dtic.mil/dtic/tr/fulltext/u2/a252766.pdf

typical Link-11 system

Link-11 functions as a computer-to-computer communications link to exchange information between shipboard, airborne and land based tactical data systems. SLEW is the more recent Link-11 development but unfortunately it is not interoperable with CLEW. Consequently, a Link-11 net can only be operated on one of them. If less capable stations need to be in the net then only CLEW waveform may be used.
Link-11 SLEW waveform is discussed here:
http://i56578-swl.blogspot.com/.../link-11-slew-scrambler.html 

Link-11 SLEW waveform period

4 July 2018

TDoA howto (tested on Ubuntu Linux 12.04)

howto compute TDoA maps with GPS enabled KiwiSDR servers around the world using Christoph Mayer TDoA scripts and his forked "kiwiclient" python stuff https://github.com/hcab14/TDoA
00=00
prerequisites:
GNU Octave (>= 4.2.2)  https://www.gnu.org/software/octave/download.html
python 2.x (mine is version 2.7.3)
git

After downloaded/installed octave and git, use git to clone TDoA repository
#cd <your_octave_directory>
#git clone --recursive https://github.com/hcab14/TDoA.git
#git pull --recurse-submodules


make a copy of TDoA procedure and symlink to kiwiSDRs positions:
#cd TDoA
#cp proc_tdoa_DCF77.m proc_tdoa.m
#cd kiwiclient
#ln -s ../gnss_pos/ gnss_pos


in kiwiclient subdirectory there should be the file read_kiwi_iq_wav.oc, if not tryto compile:
#mkoctfile kiwiclient/read_kiwi_iq_wav.cc
check if read_kiwi_iq_wav.oc has been produced then leave the directory and back home:
#cd

run octave from <your_octave_directory>:
#cd <your_octave_directory>
#octave --no-gui


install some needed packages

>pkg install -forge control;
>pkg install -forge signal;


and run the example:

>cd TDoA
>[tdoa,input]=proc_tdoa_DCF77;

this should produce two files in the png and pdf subdirectories
exit from octave:
>exit

== now you are ready==

From kiwiSDR map https://sdr.hu/map select the better SDRs for your target ( >=3 SDRs), check if they receive the target and if they are GPS'ed. Write down their URL (without the port 8073 indication) and their station-name, eg:
hsouthwest.ddns.net G8JNJ
sdr.telcosol.gr SV3EXP
sm2byc.ddns.net SM2BYC
(you have to give each station a name, I just use the KiwiDSDR name).
Also write down the central frequency in KHz of the target signal, eg: 5200.20

Now cd to kiwiclient and run the command to start the IQ recorders
the command has the format:
python kiwirecorder.py -s sdr1,sdr2,...,sdrn -f fc -w --station= A1,S2,...,Sn --log_level info -m iq -L -f1 -H f2
where:
sdr<n> = URL of the KiwiSDR #<n>
fc = central frequency of the target signal
S<n> = station name of KiwiSDR #<n>
f1 =  lower limit of the bandwidth to record in KHz
f2 =  upper limit of the bandwidth to record in Khz

so in our example, using 10 KHz badwidth (center 5200.20 KHz):

#cd <your_octave_directory>/TDoA/kiwiclient
#python kiwirecorder.py -s hsouthwest.ddns.net,sdr.telcosol.gr,sm2byc.ddns.net \
-f 5200.20 -w --station= G8JNJ,SV3EXP,SM2BYC --log_level info -m iq -L -5000 -H 5000


Stop the n-recorders using CTRL-C (it should be enough to record 30sec to 2 min). You will get three wav files (as the number of the used KiwiSDRs) with different filenames which you have to move to the 'iq/' folder !!! and three new files in 'gnss_pos/' folder which contain the coordinates of the used KiwiSDRs.

Now you have to edit the TDoA/proc_tdoa.m file and change the filenames to process, eg:
  ...
  ...
  input(1).fn    = 'iq/20180703T074355Z_8022000_G8JNJ_iq.wav';
  input(2).fn    = 'iq/20180703T074355Z_8022000_SV3EXP_iq.wav';
  input(3).fn    = 'iq/20180703T074356Z_8022000_SM2BYC_iq.wav';
if you used five KiwiSDRs you will add new lines as:
  input(4).fn    = 'iq/..._iq.wav';
  input(5).fn    = 'iq/..._iq.wav';

then edit the titles of the plots (title) and jpg/pdf output files (plotname), as well as the limits of the maps and a known-location coordinates:
  ...
  ...
  plot_info = struct('lat', [ 30:0.05:70],
                     'lon', [ -5:0.05:70],
                     'plotname', 'TDoA_8020',
                     'title', '8020 kHz 20180703T072736Z',
                     'known_location', struct('coord', [55.751244 37.618423],
                                              'name',  'MOSCOW')
                    );

save the edited file and run it in octave (as the example above):
#cd <your_octave_directory>
#octave --no-gui

>cd TDoA
>[tdoa,input]=proc_tdoa;


if everything went well you will have results files in the png and pdf subdirectories, exit from octave and browse the results.
>exit
Repeat from == now you are ready== for a new TDoA multilateration.


You might also try hf_linkz directTDoA, a python GUI interface to TDoA
http://81.93.247.141/~linkz/directTDoA/

 Have fun!

1 July 2018

unid FSK 75Bd/250

Unusual noncoherent FSK 75Bd/250 system spotted on 14116.0 (CF), apparently coming from North-West Russia, with a 14-bit period bitstream. It's not sourced from T-107 equipment neither successfully descrambled but certainly encrypted.

 

https://yadi.sk/d/lVWPp5sY3Ye7LN

28 June 2018

COMSEC transmissions using a S4285 variant (poss. Croatian-Mil)

Encrypted transmissions on 6931.0/usb which use a slightly modified 4285 waveform with 4 preamble tones and running 600bps/Short sub-mode. Transmissions are between two stations in simplex, are quite frequent during the daytime and are not preceded by ALE or voice calls: probably it's not a network but rather a PtP link where peers are tuned on the same frequency.
 
Fig. 1
The COMSEC preamble in some way resembles 188-220D, it has a period of 128 bits and in my guess it consists of 3 parts:

A) 60-bit Frame Sync (110000100000111000101111001011011101101001001011111010101100)
B) 5 x 128-bit encoded Message Indicator
C) 64-bit idling sequence (time to load the key?)

preamble is then followed by the encrypted block (D) which ends with "01" sequences (E).
 
Fig. 2
Fig. 3
All the TDoA multilaterations I've done indicate the region of Split in Croatia, also this post  suggests the same source. Unfortunately it was not possible to use TDoA more effectively: the signals have mostly short airtime and there are no close GPS'ed SDRs to both the west and east.

Fig. 4
It's worth noting that the same add of the 4 initial tones is also visible in the 110A waveform recorded on October,2 2017; in that recording the same 128-bit protocol was detected:

Fig. 5

22 June 2018

redefining T-207 checksums

T-207 is a multiplexed two channels "system" and can be connected to several modems therefore it can be found in several FSK waveforms. Since the lack of official documentation it's difficult to say much more about the (former Soviet) T-207: guys from radioscanner talk about "equipment" as a in-line ciphering device, ex DDR STASI archives refer to T-207 as an encryption algorithm; probably the name of the algorithm has been used to indicate the system that implements it, altough its characteristic "checksums" are also recognizable in clear text transmissions.

AFAIK, T-207 has two frame formats:  
14 bits: 2 x 6 bits + 2 parity bits
28 bits: 2 x (2 x 6 bits + 2 parity bits)

Using the 14-bit frame format, the two channels A and B may be splitted as:
1A 2A 3A 4A 5A 6A 1B 2B 3B 4B 5B 6B PP (47.5, 50, 84.21, 94 Baud waveforms) 
or interleaved
1A 1B 2A 2B 3A 3B 4A 4B 5A 5B 6A 6B PP (100 Bd waveforms and CIS-14)
 
The 28-bit frame format is used in 200 Baud waveforms and supports up to 4 channels, splitted as:
1A 1C 2A 2C 3A 3C 4A 4C 5A 5C 6A 6C PP 1B 1D 2B 2D 3B 3D 4B 4D 5B 5D 6B 6D PP

As said in the previous posts, T-207 detection had to be manually spotted by processing the demodulated bitstream and checking if it matches the criteria described in this post in radioscanner forum: you have to count the number of "1" bits in the first 12 columns then check if the 13-14 bits have a value among the expected ones.
The Octave script shown here has been improved and now it detects the presence of T-207 checksums in a given bit stream and for each permutation of the checksum bits. I run the script against several waveforms and the results are very interesting.
So far, I found two checksum modes termed "3" and "20":
  

and three waveforms (50Bd/1000, 100Bd/500, VFT 6x100Bd/120)  that can be coded with both the two checksums:


It's worth noting a CIS-14 96Bd/500 transmission which transposrts data only in channel B: it's probably a test since data are in clear-text mode



The Octave script T202_detect.m can be downloaded from:
https://github.com/hcab14/.../T207_detect.m

20 June 2018

(few) logs 23 Apr - 19 Jun


04538.0: ---: Russian Navy, RUS 2044 (CF) FSK 500Bd/1000 "Akula" (30Apr18) (AAI)
04553.5: ZLST: Zoll Leitstelle Cuxhaven, D 2049 USB 188-141A calling ZPRI Zollboot Priwall (30Apr18) (AAI)
06298.7: ---: Unid 1927 USB STANAG-4285 600bpsL modem, sending KG84 encrypted file (01May18) (AAI)
06377.7: ---: Unid 2015 CF, 4481-F 75Bd/850 encrypted tfc (16May18) (AAI)
06562.0: 121303: Unid 1915 USB 188-141A sounding (01May18) (AAI)
06820.0: HN02: Algerian Mil, ALG 2054 USB MIL 188-110 App.B waveform, OFDM 39-tone (25May18) (AAI)
07559.0: ---: Unid 0633 USB 3G-HF 2-way FLSU handshake / HDL+ transfer (29May18) (AAI)
07605.0: 811001: Unid 0753 USB 188-141A sounding (19Jun18) (AA)
07813.0: ANOUAL2: Moroccan Mil, MRC 2005 USB 188-141A, sounding (22May18) (AAI)
08008.0: AK0: Chinese net, CHN 2136 USB 188-141A calling DD3 / propr. MFSK-8 waveform (10May18) (AAI)
08008.0: DD3: Chinese net, CHN 2133 USB 188-141A, calling AK0 (10May18) (AAI)
08054.0: SP0: (should be SP01) Algerian Mil, ALG 0801 USB 188-141A calling FN01 (02May18) (AAI)
08132.0: BP26: Bundespolizei Küstenwache Patrol Vessel 'Bredstedt', D 2143 USB 188-141A handshake BPLEZS flwd by R&S GM-2100 HF modem, adding vessel GPS position to central database using uucp session and R&S X.25 packet connection (06Jun18) (AAI)
08146.0: JBR: Unid 2000 USB 188-141A sounding (07May18) (AAI)
08146.0: MFQ: Unid 1931 USB 188-141A sounding (07May18) (AAI)
08408.2: PBB: Dutch-Ny Den Helder, HOL 1105 USB STANAG-4285 600bps/L, NATO naval broadcast, secured with KW-46 encryption (24May18) (AAI)
08453.0: FUO: French-Ny, F 0927 USB STANAG-4285 600bpsL Async 5N2, "FP DE FUO QSL R 040742Z MAI 18 TIME 0927Z K", "FP DE FUO MERCI BON QUART AR" (03May18) (AAI)
08458.0: DC4: Unid (short for DC418P) 1027 USB 188-141A, calling KC1 (short for KC118P) (09May18) (AAI)
08458.0: KC118P: Unid 0809 USB 188-141A handshake DC418P / 188-110A Serial (08May18) (AAI)
08677.2: EBA: Spanish-Ny 2110 USB STANAG-4285 600BPSL, sending KG84 encrypted msg (10May18) (AAI)
08847.0: DD2: Israeli AF, ISR 1952 USB 188-141A sounding (15Jun18) (AA)
08870.2: ---: Unid 2158 USB STANAG-4285 600BPSL, sending KG84 encrypted msg (10May18) (AAI)
09057.7: A89: Chinese net, CHN USB 188-141A, calling E55 (10May18) (AAI)
09091.0: TAO: (=TAngO) Unid 0835 USB 188-141A, calling PAA (=PApA). Also heard on 8810.0 (14May18) (AAI)
10323.0: HNT: Unid (poss. NATO) 0718 USB 188-141A handshaking ZRO (=ZeRO) / 188-110A Serial follow (17May18) (AAI)
10333.0: RCI: Saudi Air Force Riyadh, ARS 1654 USB 188-141A calling NAI (22Apr18) (AAI)
10333.0: RCP: Saudi Air Force Riyadh, ARS 1612 USB 188-141A calling NAP (22Apr18) (AAI)
10832.8: 1247: Unid (Bulgarian net?) 1544 (CF) CCIR 493-4, calling 1246 (09May18) (AAI)
10935.0: ---: Ukr-Mil, UKR 0845 (CF) F7B mode 100Bd/500Hz in idling & traffic mode (08May18) (AAI)
11050.0: AK01: Algerian Mil, ALG 0801 USB 188-141A calling BW01 (08May18) (AAI)
11173.0: 757: Algerian AF, ALG 0724 USB 188-141A, calling CM6 (21May18) (AAI)
11325.0: ---: Unid 1930 LSB Chinese MFSK-64 10Bd flwd by 4+4 p/4 DQPSK 75Bd, strong reception (29May18) (AAI)
11413.0: JBR: Unid 0800 USB 188-141A sounding (17May18) (AAI)
11413.0: MFQ: Unid 0801 USB 188-141A sounding (17May18) (AAI)
12168.0: ---: Rus-Ny, RUS 1027 (CF) FSK 500Bd/1000 "Akula" (03May18) (AAI)
12410.7: ---: Unid 0817 USB STANAG-4285 600BPSL, sending KG84 encrypted msg (17May18) (AAI)
12460.0: ---: Unid (poss. KLN-Network tests) 1407 USB BPSK 2400Bd bursts, 288 symbols frame (14May18) (AAI)
12595.0: TAO: (=TAngO) Unid net 1011 USB 188-141A handshake OSR (=OScaR) / 188-110A Serial sending Harris 'Citadel' encrypted files (03May18) (AAI) [1]
13419.8: ---: Unid prob. French-Ny 0745 (CF) FSK 50Bd/850 continuous bcast, KW-46 encryption (31May18) (AAI)
13900.0: ---: Ukr-Mil, UKR 0650 (CF) F7B mode 100Bd/1000Hz, tones at -1500, -500, +500, +1500 (29May18) (AAI)
13909.5: ---: Rus-Mil/Gov 0701 (CF) T-207 FSK 100Bd/2000, s/off 0720 (07Jun18) (AAI)
13910.0: ---: Rus-Mil/Gov 0535 USB T-207 6x100Bd/120 VFT system,active channels:1-2-4 (06Jun18) (AAI)
14452.0: LAG: Algerian Air Force Laghaout, Alg 0825 USB 188-141A handshake CM4 flwd by 188-110A Serial (17Jun18) (AA)
14548.2: ---: Unid, prob. UK MoD from Akrotiri Cyprus 0850 USB STANAG-4285 1200bps/L, 1536-bit protocol (17Jun18)
14570.0: ---: Ukr-Mil, UKR 0605 USB 6x100Bd/120 VFT, channels 1,2,3,4,6 in stdby, 5 active, T207 encryption (30May18) (AAI)
14694.7: ---: Unid prob. Finnish Defence Forces 1316 (CF) Panasonic CF-U1 (Nokia M/90), Adaptive MSG-Terminal FSK 301Bd/151Bd 780Hz shift (31May18) (AAI)
15876.0: ---: Unid 0945 (CF) FSK 300Bd/500 blocks, 360-bit period (24May18) (AAI)
16520.0: JAY: Unid 0918 USB 188-141A, calling ZH5. Other heard callsigns: UYS,CMR (13May18) (AAI)
16607.7: ---: Unid 1222 USB STANAG-4285 600BPSL, sending KG84 encrypted msg (20May18) (AAI)