20 August 2017

Rohde & Schwarz ALIS (RS-ARQ): pool size and frame length

Like in other ALE systems, during an ALIS call [1] the caller station transmits a defined number of "calling" frames so that the called station could have enough time to scan the frequencies of the current pool and, in case of late entry, could ever receive at least three frames for synchronization and data acquisition (Fig. 1).
Fig. 1 - ALIS late entry support to facilitate data acquisition
Thus, the number of the transmitted frames during an ALIS call is not fixed but depends on the size of the current pool of frequencies: roughly it is = (3 x number of pool frequencies) + 1. Don't know what is the maximum of frequencies for each pool and the maximum of different pools which are allowed by the ALIS processor.
I had a look at some ALIS calls and surprisingly found different ACF results, eg (Fig. 2): 

~358.6 ms for a pool size = 6
~376.1 ms for a pool size = 8
~402.2 ms for a pool size = 9
~402.8 ms for a pool size = 10
~415.5 ms for a pool size = 11
(although there are some decoder indecisions about pool sizes 9 and 10).

Fig. 2 - pool sizes and ACFs
Since the system operates at constant speed (228.6 symbols/sec), the higher is ACF and the greater the number of transmitted symbols; this means that also the length of the frames is not fixed but it depends on the number of the frames to be transmitted, and ultimately on the pool size.
This dependence is even more neat looking at the demodulated stream in Figure 3, in which you can highlight a fixed 61-bit data block, following a variable length block consisting of a single field (here termed as "FC").

Fig. 3 - pool sizes and frame lengths
82-bit period for a pool size = 6
86-bit period for a pool size = 8
95-bit period for a pool size = 11

It's easy to note that the extra-lenght (period length - 61) matches the number of the frames to be transmitted for each pool size, according to the relation:
number of frames ~ (3 x pool size) + 1

Figure 4 shows the "vertical" comparison of the 61-bit block for three different pool sizes (6,8,11) and a my rough reading of their structure; the decoder outputs in the right boxes help to identify values and differences.
It's easy to see that the first 15-bit field (0-14) is the address of the called station, while the 23-bit last field (38-60) is probably transmitted for sync/correlation since this field exhibits the same pattern in all the 3 frames; if so, the rightmost bit should be the first to be transmitted. The 23-bit middle field (15-38) is the "status" of the caller station (FSK, voice, data, ARQ, adaptive reaction, fixed operation on a single frequency, frequency hopping mode, message key for frequency hopping mode, ...).
It's worth noting that, despite other ALE waveforms, the caller address is never transmitted.

Fig. 4 - 61-bit block structure
As you see, no field contains informations for the pool size (the middle field can't store the pool size because the first two frames have diffrent pool sizes and same value for this field!).  

Given the above, the fact that the decoder prints out the size of the selected pool of frequencies (as in Fig. 1), means that this information is obtained from the "parsing" of the variable lenght block (FC block) of the frame. I just wrote "parsing" because in this block, rather than a numeric value, they adopted a "positional" rapresentation by using the lenght of the block and the position of the 1-value bit, which is right-shifted in each received frame (Fig. 5).

Fig. 5 - FC blocks
One could say that the FC block looks like a function table of a n-bit shift register, in which each received frame acts as a transition of the clock input. 
Besides enumerate and identifiy the received frames, and consequently the pool size, the implementation of the FC block could also be used as a timing logic for re-sync the receive modem. But that's just a my opinion.

Please note that I do not own professional analysis tool so the numbers could be a bit inaccurate or different, anyway I think the underlaying reasoning remains valid. Who knows? maybe someone from R&S will read and comment... 

[1] quoting Hoka Electronic: "Some people call RS-ARQ (Rohde & Schwarz simplex ARQ) as ALIS but strictly speaking, ALIS is only the automatic link processor and frequency management system. It is not responsible for generating the traffic. ALIS is therefore somewhat of a misnomer. The modems generating the traffic are the GM857 and GM2000. Our suggestion is to stick with RS-ARQ as the system name."

16 August 2017

unid 3-of-6 multitone system (tentative)

Recently I copied an interesting multitone signal on 14642.0 KHz and 16114.0 KHz on USB. The signal uses 6 tones, 400Hz spaced, starting from 650Hz, and it sounds just like a frog. Tranmissions do not have a preamble, last for a few minutes (the longer I heard last up to 16 minutes) and consists of 820ms blocks: 500ms data block followed by 320ms interval (Fig. 1)

Fig. 1
Transmissions end with the sending of the 6 carriers in a special sequence (Fig. 2)

Fig. 2
Three of the six tones are used to form the code symbols, ie they are sent simultaneously (Fig. 3): since given six tones there are twenty combinations of three that can be drawn without repetitions, this system use a 20 symbols alphabet set. It's important to note in Fig. 3 that each data block always consists of the ordered sequence of all the possible symbols (!) that makes a speed of 40 symbols/sec that is - in some way - coherent with the used shift (40Bd/400hz).

Fig. 3

Many "exotic" coding could be derived from this set (as 123=A,124=B,... or 123=0,124=1,...) and a 6-bit representation is one of these: e.g. using the lower tone as the LSB we get the sequences:

000111 001011 010011 100011 001101 010101 100101 011001 101001 110001 
001110 010110 100110 011010 101010 110010 011100 101100 110100 111000

Fig. 4
(you may play around it inverting the order, changing polarity, differential decoding,...)

I don't know who they are and where the signals come from, anyway the fact of sending all the alphabet symbols leads to think that it could be a test of a new system, maybe aimed to Intel/Diplo services... but it's only a my supposition and - if that is the case - we should wait for further transmissions from the "production" frog-modem.


13 August 2017

BPOL R&S X.25 packet radio network on HF

Bundespolizei See (here simply termed "BPOL") is the maritime component of the Federal Police and is responsible for the border protection of the German state on the maritime border of the North Sea and Baltic Sea (Schengen external border). Since July 1994, BPOL has been part of the "Coast Guard", a coordinating organization of the executive forces of the Federation at sea, which includes customs, water and shipping administration and fishery protection. Since January 2007, BPOL is also represented as a security partner in the joint location center (GLZ-See) of the maritime safety center (MSZ) in Cuxhaven [1].
I consulted the UDXF logs (a collection of logs since year 2008) and for more than one week I watched one of their HF channels (8132.0 KHz/USB): with the exception of rare and sporadic transmissions between ships, all the traffic is structured in a star-shaped HF network in which the coastal HQ is the net control station (Fig. 1).

Fig. 1 - BPOL star-shaped network
ALE Address - name (HF node name)
BPLEZSEE Operations Center HQ Cuxhaven (BPOLBPLEZSEE_HF)
BP21 - patrol vessel "Bredstedt" (BPOLBP21_HF)
BP24 - patrol vessel "Bad Bramstedt" (BPOLBP24_HF)

BP25 - patrol vessel "Bayreuth" (BPOLBP25_HF)
BP26 - patrol vessel "Eschwege" (BPOLBP26_HF)

(*) patrol vessels BP22 "Neustrelitz" and BP23 "Bad Düben" are out of service since 28 June 2017 [2]. Just a curiosity: BP22 and BP23 are also known from the ZDF Television series "Küstenwache", where they were alternated under the name "Albatros II" [3] .

The way they operate these HF channels (8132, 5258, 4618, 3850,... KHz/USB)  is based on link establishment, using MIL 188-141A 2G-ALE, followed by data transfer, using a Rohde&Schwarz proprietary PSK-8 2400Bd waveform  and GM2100/GM2200 serial HF modem (Fig. 2a); anyway, the most large part of the heard transmissions consists of routine ALE scanning calls. 

Fig. 2a
The most interesting aspect is that data exchange is performed by means of RSX.25 ARQ protocol (Fig. 2b), a Rohde&Schwarz adaptation of the wired X.25 packet protocol to the HF radio channel. 
Fig. 2b

Quoting R&S papers: "The RSX.25 protocol is a modified AX.25 packet radio protocol. RSX.25 organizes the data to be transmitted in packets, which are successively transferred to the data modem. The packets contain a variable number  of  frames, the number perpacket depending on radio-link quality and being adapted at regular intervals.
The data transmitted in a packet are distributed among the frames. The length of the frame data is variable and also depends on radio-link quality: in channels of very good quality, a frame contains up to 250 data  bytes, in strongly disturbed channels 4 bytes. The HF Modem GM2100 is integrated in an optimized RSX.25 protocol that controls modulation and redundancy adaptation. With 8PSK the net data rate of the serial modem is 5400 bit/s. Errors are at first corrected by FEC, which reduces net data rate to 2700 bit/s. Errors escaping FEC are eliminated by the ARQ procedure of the RSX.25 protocol."

Fig. 3 - RSX.25 data after GM2100 removal
Fig. 3b - the same data synched on 0x7E (01111110) flag (AX.25)

A second interesting point is that each 188-141A three-way handshake always includes the command User Unique Function (UUF) in the message section [7]:


UUFs are for special uses, as coordinated with specific users or manufacturers, which use 188-141A in conjunction with non-ALE purposes. There are 16384 specific types of UUF codes available, as indicated by a 14-bit (or two-character) Unique Index (UI) which is always included in UUF when sent (Fig. 4); in this case they always use the index "00000000000111" and most likely it's closely related to the upper RSX.25 protocol:

(to)BPLEZS (cmd)|[nul][bel] (tis)BP24
1111100 00000000000111 

Fig. 4 - User unique functions structure

Unfortunately, linking handshakes & following RSX.25 exchanges are not as frequent as the great amount of scanning calls, indeed data exchanges are few and not all are carried by good signals: probably because of the varying propagation and the distances from my QTH, or maybe because links are performed in other channels and I do not own a scanner. 
Probably there is also another reason due to the use of HF only when a vessel exceeds the V/UHF range of coastal HQ, or exceeds the area covered by their TETRA "BOSNet" network infrastructure (the German nationwide TETRA radio system), assuming that these vessels already have this technology.  

Given the above, what is the nature of the RSX.25 exchanged data? Here is where things get a bit difficult.
As said, RSX.25 is a packet radio protocol and is meant to share tactical information and short messages. It has a typical period of 8 bits and may convey BZIP compressed files (eml, txt and others...) as well as IP frames.

Fig. 5
Email files (.eml BZIP compressed) are just simple messages and consist of "position reports", as the transmission logged on August 10 at 0806 in which vessel Bayreuth (PB25), comunicates its coordinates at 0737 and 0757 (all times in CEST). Emails are probably managed by R&S Postman software running at upper layer.

2017-08-10 07:37:48+02,BPOLBP25,54.023927,10.800935
2017-08-10 07:57:47+02,BPOLBP25,54.023125,10.800987

The transmitted coordinates can be easily imported into Google Earth using klm files (Fig. 6a).

Fig. 6a
Moreover, using web sites such as: vesselfinder or marinetraffic you could verify a received position report or just "track" the calls as in Fig. 6b.

Fig. 6b - tracking ALE calls

Back to captures, looking at txt files (Fig. 7) there are some interesting sequences that are easily recognizable (maybe related to a protocol built on top of packets?) as well as messages like "login, connected, closed" which are exchanged between the nodes. Also note that sometimes 188-141A links are terminated by the called station rather than the caller. 
What is even more interesting is the sending of one or more text strings in the format:

[yyyy-mm-dd] [hh:mm:ss UTC-offset], [vessel name]

where vessel name usually is not the one which sends the message (except when an email is also sent) and date-time is always before the transmission time. These kind of "announcing lists" are separated by semicolons and seem enclosed in <MPL></MPL> tags when sent by a vessel, and in <SPL></SPL> tags when sent by BPLEZSEE. It may also happen that these lists are empty, in this case only the tags are transmitted e.g. <MPL></MPL>.

Fig. 7
One could say that, in some way, these strings resemble the DX-Cluster spots, while the vessel positions reported in emails resemble APRS (Automatic Packet Reporting System); anyway, such messages seem related to situational awareness purposes. 

Probably this is one of the few existing packet-radio networks in HF and, the way things are these days, will be soon replaced by TETRA/SatCom systems.

9 August 2017

crowd funded experiment for HAARP

This is an amateur's approach to a science experiment. It may not be in a typical fashion one would see from a physics student or a scientist. Even if my experiment doesn't provide any insightful information, as happens quite often in real scientific experiments - it will be a great opportunity to test a hypothesis! I hope this will have a positive effect of inspiring and motivating others to pursue their interests in science!
You're help is greatly appreciated. I can't do it without you!

Jeff, KL4IU

3 August 2017

short bit-analysis of a STANAG-4538 LDLn transfer (BW3 bursts)

Each LDLn transfer consists of a TX Frame consisting of one data packet; A data packet is defined as a fixed-length sequence of n-byte data segment (n = 32,64,96,...,512) followed by a 17-bit Sequence Number plus an 8-bit Control Field (presently unused), both added by the LDL protocol. Each TX Frame is sent using burst waveform BW3.
During the construction of BW3, a 32-bit Cyclic Redundancy Check (CRC) value is computed across the  data bits of each data packet (8n+25 bits) and is then appended to the data packet. Then, 7 flush bits having the value 0 are appended to the data packet with CRC (8n+57 bits) to ensure that the encoder is in the all-zero state upon encoding the last flush bit. 
That said, we can go back to the original datagram by inspecting the last 64 bits (17-bit Sequence Number + 8-bit Control Field + 32-bit CRC + 7 flush bits) of the ten BW3 bursts  (Fig. 1):

Fig. 1
 Some aspects must be first considered:

a) the 8-bit reserved field is added after the CRC field and not after the Sequence Number, as specified in Annex C to STANAG-4538; I don't know if it's the modus operandi of the decoder;
b)  following the last bit of the Payload field-value, the bits of the Sequence Number field are transmitted starting with the least significant bit (bit 0) rather than the most significant bit (bit 16). Most likely it's the modus operandi of the decoder, as above;
c) as in the Sequence Number of HDL Tx frames (see the previous post), the bits 14-6 of the first packet in datagram contain the number of user bytes in packet -1 and this contrasts what specified in Table; it depends on the particular STANAG-4538 implementation?

In this sample the values of the Packet Number fields are: 0,0,1,1,2,2,3,3,4,4: maybe the destination station requested a retransmissions or, most likely, each TX Frame is sent twice so to improve the reliability of the transfer (also note the values of the CRC fields). Correspondly, the Packet Byte Count fileds are: 128,128,...,67,67, this means it's a LDL128 transfer.
Note that the bytes contained in the packet #4 is less than 128 bytes because it includes the last data byte of the original datagram (the remaining 128-67 bytes are filled with "0" value bytes). That said, the original datagram of this sample is composed of the single packet numbers 0,1,2,3,4 (ie BW3 #0, #2, #4, #6, #8) and its length is (128 x 4) + 67 = 579 bytes (Fig. 2); the receive station shall discard the duplicated packet numbers.

It's worth noting that in this sample there are no BW4 ACK bursts returned back: it could be an MDL (Multicast Data Link protocol) transmission or maybe I did not heard these bursts!

Fig. 2
Back to the whole bitstream, once structured in a 1088-bit period ((8 x 128) + 64), the original datagram can be extracted by isolating the firts 4 rows and removing the overhead bytes: the resulting is an HARRIS "Citadel" encrypted file (Fig. 3).
Fig. 3
The ten LDL128 bursts, the retransmitted packets, and the "0" value bytes fillers can be noted looking at the whole bitstream in Figure 4.

Fig. 4

31 July 2017

Arecibo ionosphere HF campaign, 24-31 July 2017

31 July
As announced by Chris Fallen on twitter "Arecicbo campaign finale with SSTV transmission at 0815 Z"... but really poor chances to receive images in Italy (at least in my QTH):

  As expected, too weak signal at 0815Z (just crumbs of signals):

30 July
stepped-tones patterns sent fom Arecibo (14 Khz bandwidth only)


25 July
Copied the O-mode CW/Pulse session on 5125.0 Khz (yesterday 5095.0 KHz was the working frequency). From about 2055Z, I start to hear a serie of ticks: as twitted by Chis Fallen "My exp. uses 60s ON / 60s pulse 10ms w/ 1s inter pulse period (IPP)".

24 July

quoting from Chris Fallen KL3WX  "If you are reading this then another radio event of possible interest is the upcoming Arecibo ionosphere HF heating campaign during 24 to 31 July 2017. The new Arecibo ionosphere HF heater nominally transmits 600 kilowatts net power (100 to 200 megawatts effective radiated power) and has a unique Cassegrain dual-array antenna design that increases gain of three crossed dipoles for each band using the signature 1000 ft spherical dish reflector.[...]. During the upcoming campaign, the Arecibo HF transmitter is limited to two frequencies, 5.125 and 8.175 MHz. Campaign HF transmissions will start at approximately 1600 hours UTC and be active approximately 24 hours per day, with some occasional downtime for maintenance and other activities lasting one or more hours. Generally, the 8.175 MHz transmissions will occur in the daytime when foF2 is expected to exceed that value, between approximately 1830 and 2230 hours UTC. Otherwise the HF transmissions will occur at 5.125 MHz.
These transmissions will be in the vertical direction so this is an excellent opportunity to observe NVIS from a powerful transmitter in Puerto Rico."

Notice that 5125 and 8175 KHz, depending on local foF2, are just estimates and the actual transmitted frequency may be adjusted slightly from those values for various reasons.
I copied one of their transmission on 5095 KHz around 2145 Z on 24 July: the working frequency was comunicated by Chris Fallen in his twitter account: https://twitter.com/ctfallen (follow him if you want tune such these transmission from Arecibo). Although at a first glance the signal appears as "carrier", it consists of O-mode or X-mode polarized CW pulses (Fig. 1):

Fig. 1 - the received signal
These transmissions leave the earth in the vertical direction so this is an excellent opportunity to observe NVIS from a powerful transmitter in Puerto Rico: signals in Europe are probably heard thanks to secondary radiation lobes at 5 MHz (Fig. 2), as depicted in: 

Fig. 2

29 July 2017

Russian MFSK-17 125Bd/125Hz burst system (selcall waveform?)

Unid MFSK-17 burst system heard on 11090 KHz/USB, modulation speed 125 symbols/sec and separation between tones is 125 Hz (Figs. 1,2)

Fig. 1
Fig. 2
The waveform-1 seems to have some LMF components and a curious tones format (Fig. 3) maybe used to wake-up receiving modems or  matching a certain known tone-sequence. Waveform-1 is then followed by a Russian male operator calling the other station: "first calling twentieth" (thanks my friend KarapuZ who translated the voice comm).

Fig. 3
Bursts have a duration of ~1080 msec and sent each 4000msec in waveform-2.
The same signal, more precisely the here-termed waveform-1, was reported about one year ago in radioscanner.ru forum. "Sometimes a multi-frequency transmission with spreading has been observed" my friend KarapuZ say.


27 July 2017


05200.0: ---: (no call) 2100 USB voice comms using Hagelin HC-256 scrambler (06Jul17) (AAI)
05255.0: R4: Unid 2017 USB MIL 188-141A call R7 (06Jul17) (AAI)
05305.0: TC01: Algerian Military, ALG 2045 USB MIL 188-141A handshake NX01 / voice comms using HARIS AVS vocoder (06Jul17) (AAI)
05405.0: JCI: Saudi Air Force, ARS 2042 ISB MIL 188-141A call RFI (06Jul17) (AAI)
05453.0: RHP: Saudi Air Force, ARS 2038 USB MIL 188-141A call AAP (06Jul17) (AAI)
05775.0: XS69: Unid 2031 USB MIL 188-141A call XN40 (06Jul17) (AAI)
06208.4: XLA: French MOD, F 1745 USB USB MIL 188-141A handshake XLB / THALES HF XL modem, upper channel 6393.1 KHz (07Jul17) (AAI)
06362.5: D23: US Customs P-3B Slick, USA 1437 USB MIL 188-141A call A82 UH-60 CPB (09Jul17) (AAI)
06416.5: XSS: DHFCS, UK 1543 USB MIL 188-141A call XDV (09Jul17) (AAI)
06516.0: MedNet: Mediterranean Cruiser Net 0605 J3E/USB lady in English lang. working cruising vessels (06Jul17) (AAI)
06550.0: GRIFFIN: TF Griffin Camp Bondsteel, HRV 0520 USB MIL 188-141A sounding (14Jul17) (AAI)
06715.0: CROSPR: US-GCS Croughton AFB, UK 0509 USB MIL 188-141A call MOBD02DAT (06Jul17) (AAI)
06715.0: OFFSPR: US-GCS Offutt AFB, US 0503 USB MIL 188-141A call MOBD02DAT (06Jul17) (AAI)
06840.0: GRIFFIN: TF Griffin Camp Bondsteel, HRV 0442 USB MIL 188-141A sounding (06Jul17) (AAI)
06938-0: HBLZDRD1: Roumenian Militay, ROU 0709 USB MIL 188-141A handshake HFJCDRD1 / MIL 188-110A Serial (17Jul17) (AAI)
07394.5: KW7: Polish Military, POL 1231 USB MIL 188-141A call SA2 (01Jul17) (AAI)
07401.0: ZBOR: German Customs Patrol Vessel Borkum, D 0626 USB MIL 188-141A, call BMEK (02Jul17) (AAI)
07450.0: ABC7: Croatian Military, HRV 0712  USB MIL 188-141A Handshake / STANAG-4285 1200bps L, email to ABG6 using CROZ STANAG-5066 HMTP (06Jul17) (AAI)
07455.0: NAA: Navy Isabela, PTR 0630 USB (offset +2000) NATO-75 75/850, continuous bcast (02Jul17) (AAI)
07460.0: 24191: Moroccan Civil Protection, MRC 0539 USB MIL 188-141A sounding (13Jul17) (AAI)
07464.0: HWK01: Swedish Armed Forces, S 0737 USB 3G-HF 1-way FLSU call flwd by Circuit Mode MIL 188-110A serial, unid S-5066 UDOP client (05Jul17) (AAI)
07467.0: SL2: Slovakian Military, SVK 0600 USB MIL 188-141A call MC1 (07Jul17) (AAI)
07505.8: XLA: French MoD, F 0858 USB THALES HF XL modem, 12 channels test transmissions to XLB (21Jul17) (AAI)
07530.6: ---: Unid 0620 (cf) Siemens CHX200 F1-modem (CHP-200) FSK 249Bd & 250Bd/170Hz, selcall mode (02Jul17) (AAI)
07568.0: KRAKOW: POL MSWiA net Krakow, POL 0636 USB MIL 188-141A call BYDGOSZCZ (06Jul17) (AAI)
07568.0: POZNAN: POL MSWiA net Poznoan, POL 0710 USB MIL 188-141A call BYDGOSZCZ (06Jul17) (AAI)
07600.0: ---: Unid prob French Military 0739 THALES Skymaster MFSK-8 ALE / THALES proprietary 2400Bd PSK-8 waveform (06Jul17) (AAI)
07615.0: ---: Unid prob French Military 0822 THALES Skymaster MFSK-8 ALE / THALES proprietary 2400Bd PSK-8 waveform (25Jul17) (AAI)
07630.0: ---: Unid 0709 (cf) NATO-75 75/850, KG-84 encrypted message (10Jul17) (AAI)
07677.5: NX40: Algerian Military, ALG 0837 USB USB MIL 188-141A call XS69 (15Jul17) (AAI)
07692.0: CX3: Moroccan Gendarmerie, MRC 0659 USB MIL 188-141A call IC2 (22Jul17) (AAI)
07693.0: ---: Unid 0725 USB THALES Skymaster MFSK-8 ALE (10Jul17) (AAI)
07720.0: ASB01D: French Naval Network, F 0819 USB MIL 188-141A handshake AM103D / MIL 188-110A Serial (26Jul17) (AAI)
07765.0: FQ71: Unid 0845 USB MIL 188-141A call NX80, also heard on 7841.0 and 8023.0 (01Jul17) (AAI)
07788.0: ---: 0541 USB 3G-HF 2-way FLSU handshake / LDL128 tranfser, Harris "citadel" encrypted 451 bytes file (20Jul17) (AAI)
07788.0: ---: Unid 0615 USB 3G-HF 2-way FLSU handshake flwd by LDL128 transfers, switch of data traffic directions (04Jul17) (AAI)
07813.0: GR2: Moroccan Military, MRC 0703 USB MIL 188-141A sounding (24Jul17) (AAI)
07840.0: PC20: Unid (Algerian Military?) USB MIL 188-141A call NX20 (09Jul17) (AAI)
07840.0: XPU: UK-DHFCS, G 0737 USB MIL 188-141A call 1VR (01Jul17) (AAI)
07841.0: ---: Unid 1435 Unid BPSK/62.5Bd (BPSK63F HAM) modem, 31-bit ACF encrypted msg (12Jul17) (AAI)
07875.0: PEGASO: EVA (Escuadrón Vigilancia Aérea) Spanish Air Force Torrejón de Ardoz, S 0800 J3E/USB, radio checks with POLAR (Zaragoza) and SIROCO Lanzarote (26Jul17) (AAI) [I]
07906.0: ---: Unid 0600 USB unid burst ARQ system using STANAG-4539 & MIL-188-110A Serial (11Jul17) (AAI)
07930.0: ---: Unid 0453 USB 3G-HF 2-way FLSU handshake flwd by HDL12 transfer (05Jul17) (AAI)
07978.5: ---: Unid 0627 USB (offset +1500) R&S ALIS 228Bd/170, selcall to 220 (03Jul17) (AAI)
07990.0: ---: Unid: 0630 USB phone comms scrambled using HF CRY-2001 (Sailor-2001) (14Jul17) (AAI)
08016.0: S21: NPRD-Net Split, HRV 0740 USB MIL 188-141A sounding (01Jul17) (AAI)
08016.0: S21: NPRD Network, HRV 0712 USB MIL 188-141A sounding (24Jul17) (AAI)
08016.0: S22: NPRD Network, HRV 0703 USB MIL 188-141A sounding (24Jul17) (AAI) [I]
08021.5: 4KV: Unid 0612 USB MIL 188-141A call 1KV (20Jul17) (AAI)
08054.0: ZD02: Algerian Military, ALG 0825 USB MIL 188-141A call ZD01 (21Jul17) (AAI)
08058.6: ---: Unid 0607 USB (offset + 1600) BELL 103 compatible modem FSK 300Bd/200 in selcall mode (04Jul17) (AAI)
08103.7: HWK01: Swedish Armed Forces, S 0655 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, S-5066 Circuit Mode service, unid RCOP client sending data to VJL (25Jul17) (AAI)
08105.0: CFI: Unid 0550 USB MIL 188-141A call CONRRD19 (09Jul17) (AAI)
08105.0: CFIRRD19: Unid 0534 USB MIL 188-141A call D2IRRD19 (13Jul17) (AAI)
08105.0: CFIRRD19: Unid 0542 USB MIL 188-141A handshake CONRRD19 / MIL 188-110A Serial (13Jul17) (AAI)
08138.0: WAF: ENI/NOC Al Wafa field, LYB 0634 USB MIL 188-141A call MEL Mellitah terminal, short French language male op-chat (04Jul17) (AAI) [1]
08163.0: ---: Unid 0651.0 USB 3G-HF 2-way FLSU handshake / HDL6 tranfser (25Jul17) (AAI)
08168.5: CFIRRD17: Unid 0604 USB USB MIL 188-141A call D2IRRD17 (20Jul17) (AAI)
08190.0: STANISCI: Italian GdF Ship G.1 28 "Vicebrigadiere Stanisci", I 0558 USB MIL 188-141A call MESSINA (24Jul17) (AAI)
08195.0: 10536: Unid 0554 USB MIL 188-141A call 8536 (09Jul17) (AAI)
08234.0: BB1: Israeli Air Force 30th AB, 124 Sqn Palmachim, ISR 0519 USB MIL 188-141A call AAA (05Jul17) (AAI)
08244.5: ---: Unid 0824 USB Arcotel MAHRS-2400 based ARQ system, proprietary 2400Bd PSK-8 burst waveform (17Jul17) (AAI)
08311.0: ABC7: Croatian Military, HRV 0742  USB MIL 188-141A Handshake / voice comms, radio-check w/ABS5 (25Jul17) (AAI)
08327.0: ---: Unid 0709 USB 3G-HF FLSU handshake / LDL160, sending 139 bytes CITADEL encrypted file (10Jul17) (AAI)
08875.0: X44: Unid (prob. Moroccan Military) 0535 USB MIL 188-141A sounding (14Jul17) (AAI)
08992.0: SIGONELLA: US NAS Sigonella, I 2004 J3E/USB test count (06Jul17) (AAI)
10051.0: ---: New York Volmet, USA 0450 J3E/USB Aviational Weather Tampa, Bermuda, West Palm Beach,... (04Jul17) (AAI)
10713.0: SNB813: Polish Military, POL 1335 USB MIL 188-141A sounding (25Jul17) (AAI)
11050.0: ND1: Unid 1016 USB MIL 188-141A handshake FS1 / RFSM8000 serial modem (09Jul17) (AAI)
11056.0: Z01: Croatian NPRD Net Zagreb, HRV 0627 USB MIL 188-141A sounding (07Jul17) (AAI)
11075.0: PEM04D: French Navy, F 0819 USB MIL 188-141A call PEM01D (13Jul17) (AAI)
11111.0: TUD: Tunisian MOI net, TUN 0854 USB MIL 188-141A handshake / PACTOR-II, encrypted email to STAT24 (06Jul17) (AAI)
11186.0: ---: Unid 0517 USB 3G-HF 2-way FLSU handshake flwd by LDL352 sending 699 bytes Citadel encrypted file (04Jul17) (AAI)
11412.0: ---: Unid (Czech Diplo?) 0710 USB (offset +1500) PacTOR-III messages (02Jul17) (AAI)
11490.0: ---: Russian Mil/Intel, RUS 0517 (cf) MOROZ FSK 50Bd/500, reversals (04Jul17) (AAI)
13200.0: ANDREWS: Andrews AFB, USA 0600 J3E/USB test count (12Jul17) (AAI)
13500.0: ---: Unid 0550 USB CIS 6 x 100Bd/120Hz VFT system (12Jul17) (AAI)
14371.0: CENTR2: Roumenian Diplo Bucarest #2, ROU 0723 USB MIL 188-141A handshake / MIL 188-110A Serial, short message to PHG using STANAG-5066 (14Jul17) (AAI)
14550.0: R65: Moroccan Military, MRC 0758 USB MIL 188-141A sounding (14Jul17) (AAI)
14693.5: N64: Unid 0741  USB MIL 188-141A call A85 (14Jul17) (AAI)
14773.5: N64: Unid 0709  USB MIL 188-141A call A85 (14Jul17) (AAI)
14800.0: CVZ: Algerian Air Force, ALG 1228 USB MIL 188-141A call HA2 (24Jul17) (AAI)
16716.0: ---: 0819 USB 3G-HF 2-way FLSU handshake / HDL6 tranfser, Harris "citadel" encrypted 923 bytes file (14Jul17) (AAI)
16964.0. ---. UNID 0640 usb (cf +1800) PacTOR-II FEC (15Jul17) (AAI)
17122.0: ---: Unid 1303 USB HARRIS Autolink-I flwd by MIL 188-110 App.B 39-tone modem sending 5LGs (01Jul17) (AAI)
17127.3: CTA: Potoguese Navy Monstanto, POR 1450 LSB STANAG-4285 600bps/L, Channel Availability for ship-shore "1450Z//CTA02I/CTA08I/CTA12I/CTA14I/CTA16I/CTA19I//" (16Jul17) (AAI)
17398.0: XSQ: Guangzhou Radio, CHN 1506 J3E/USB Navigational warnings (16Jul17) (AAI)