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)

26 July 2017

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

Just a small update to notice that from recent copies it seems that they returned to using 10 bytes for the length of the timestamp element:

Note that only the format is changed since the start epoch time is still the same:

So far, these are the S5066 Addresses that have been found:

[006.046.000.zzz] block

[006.046.001.zzz] block
HEH002     --"--

and these the "magic string" values:




21 July 2017

playing with psk-Sounder and Stanag-4285

I used the word "play" because this post does not claim to be a scientific treatment or a in-depth study on propagation mechanisms. HF propagation is not a sort of "deterministic machine" with a certain set of known rules to apply, is not so immediate as a multiplication table, but rather it's a very complex science which involves several disciplines; there is a lot of things to know and a lot of still not clear things... and something unpredictable. Almost casually I found the psk-Sounder software and decided to have just a close look at it: the results are shown in this "cheap and cheerful" post. I want to thanks Murray Greenman, a great expert on HF propagation (20 years experience) and co-developer of psk-sounder, for the precious help and clarifications.

STANAG-4285 is basically a 2400 baud PSK-8 signal, transmitted in frames of 256 symbols in a frame. The intersting thing is an 80-symbol section of this frame which contains a repeated 31-bit pseudo-random binary sequence (PN). PSK-Sounder uses frames of the same length and its cross-correlator allows to locate each frame exactly in time. Since a PN sequence is transmitted every 256/2400 secs, by comparing the time of the frame with a clock in the computer, we can also measure changes in the propagation delay of the received signal over time and plot such measures in the so-termed Correlogram.
The Correlogram is then a representation of propagation delay (vertically), elapsed time (horizontally) and correlation significance (relative signal strength of each ray) as brightness. You can use the mouse to read off the delay between responses.

Fig. 1 - psk-Sounder monitoring a STANAG-4285 transmission on 17MHz from CTA Monsanto (Portugal)
"As an example, imagine we are receiving a signal from a station some distance away, which is providing both ground wave and F-layer ionospheric signals - the classic NVIS situation. The ground wave will be delayed by just a millisecond or two (300km per millisecond at the speed of light), while the F-layer signal, travelling a further 300km up to the ionosphere and another 300km back, will be delayed an extra 2ms. Both these signals arrive at the receiver, and the cross-correlator has to work with the combined signal. So, it will in fact find two peaks, about 2ms apart, and we can display or plot this information, and measure the delay. Very often the propagation is even more complex, especially at greater distances, and of course very often the ground wave signal is not received at all." 
PSK-Sounder, along with documentation, instructions and examples, can be downloaded from:

1) a serious approach requires the monitoring of several stations and frequencies for long periods, say one year at least, so to observe the changes in propagation in different seasons and in different hours of the day per each station/frequency (...the sun is not a light bulb). For my scope, I monitored only two S4285 stations at fixed times (for about a 5-minutes period) during the day:

- 5215.6 KHz French Navy Toulon F, 445 Km West from my QTH
- 8698.2 KHz Norwegian Navy Bodo NOR, 2721 Km North from my QTH

It's important to note that in the case of Toulon the path is in large part over the sea (83.5%).
Fig. 2 - the "monitored" STANAG-4285 stations
2) There are empty areas in some of the following correlograms which are due the lack of S4285 sync. It's always difficult to achieve really long monitoring times with PSK Sounder, as something inevitably disrupts the bitstream and consequently the synchronization with the incoming S4285 signal is lost. Obviously, real modems resynchronise to the PN sequence instantly, but PSK-Sounder is not locked at all and simply observes where the PN sequence is! (as said above).

3) I have no stations within ground wave range (say 50 km at 5 MHz, 100 at most), the closest is IDR  Italian Navy from Santa Rosa (Rome), so the lowest 0 seconds fligth-time track in Correlograms (that would be the ground wave) is here the E layer response, ie the region about 30-50 km up from earth. This means that the delays are not the real ones but are related to E responses, when present, or at least to the lower one.

4) Combined Correlograms (Toulon/Bodo) would be very interesting but unfortunately I do not have a such tool at my disposal.

One could say that similar tests do not make a great sense (and that's right), anyway, although the above limitations, some interesting observations can be noted.

Correlograms - Bodø (8698.2 KHz - 2721 Km North - 20 July)

Fig. 2a

Fig. 2b
Fig. 2c
Fig. 2d

I am not in a position to correctly describe the above scenarios, but I can give a rough description of what I see. While around 1000Z (Fig. 2b) the reception is sustained by E layer, around 1400Z (Fig. 2c) the propagation is mostly due to F layers: you can see the different heights (ie delays) of the thickest black line. Pobably, at that time (1420Z) the absorbing D layer is disappeared, signals have a greater strength and can penetrate E layer and reach the upper F region.

Correlograms - Toulon (5215.6 KHz - 445 Km West - 20 July)

Fig. 3a
Fig. 3b
Fig. 3c
Fig. 3d
In the morning (Fig. 3a) are visible two well distinct paths reception due to the refractions by E and F layers. In the central part of the day, the E response line is a less pronunciated line and delayed responses up to 4-5 msec begin to be visible (Figs. 3b, 3c); it's very interesting the short duration scatter in Figure 3c which causes a cloud of delay responses > 5 msec.
As said, I am not in a position to give an explanation to this, I asked Murray and I quote here the reply he sent me (it's worth reading it): "[...] It's very difficult to say from just the Correlogram. If you consider a triangle with a base of 450 km (the station's distance from you), which is a flight time of 1.5 ms, and a total 'distance' of the two sides of 4.5 ms (the delay added by the path you are interested in), then you can construct an isosceles triangle which will have the refractive point at the peak. The sides will each be 2.25 ms, and the vertical height to the peak can be calculated to be 4.44 ms, or a height of 1332 km above the base.
We know that the F layers are 200 - 300 km in altitude, so clearly the scenario I just described is not correct. There are two factors involved: (1) the possibility that the signal bounced around (is scatter); and (2) that the speed of light is much reduced at the refractive layer, since the refractive index is high here. So therefore the path is not a simple triangle, but has an area of multiple refractions with reduced propagation speed.
So the complicated answer is that I consider that area to be one of multiple scatter, the signal bouncing around between layers (probably F1 and F2) for some time before returning to earth. It is probably not a small  'cloud' as such, but a wide layer which was briefly in the right place for you to see the effect.
Another point to consider is that the ground wave range on 5 MHz is about 50 km, 100 at most, so what looks like the ground wave is most likely the E layer response, the layer about 30 - 50 km up. [...]". Anyway, bounces between sky and sea are also probable.
Around 2000Z (Fig. 3d) the E response returns to be preminent along with the lower F layer, probably still many bounces cause delayed responses up to 5msec. 

Final note
HF propagation is a fascinating part of our hobby but things get very complicated if one want to deepen his knowledge about it. Unlike what it may seem from reading some websites, propagation is not summarizable in a few simple rules but there are a lot of things to study ...and "The trouble is that this sort of study raises more questions than we have answers for!", as Murray Greenman says.

14 July 2017

short bit-analysis of a STANAG-4538 HDLn transfer (BW2 bursts)


Each HDLn transfer consists of n TX Frames (n = 24, 12, 6, or 3) each consisting of n data packets; each data packet consists of 233-byte data segment plus a 17-bit Sequence Number. Each TX Frame is sent using burst waveform BW2.
During the construction of BW2, a 32-bit Cyclic Redundancy Check (CRC) value is computed across the 1881 payload data bits of each data packet (233 bytes of user data, plus the 17-bit of Sequence Number) and is then appended to the data packet. Then, seven encoder flush bits with values of zero (Flush) are appended to produce an Extended Data packet of 1920 bit length,ie: 233 data bytes + 7 overhead bytes (17-bit sequence number + 32-bit CRC + 7-bit flush). See this post about the formation of a BW2 burst.

Fig. 1 - BW2 formation
That said, we can go back to the original datagram by inspecting the last 56 bits of the Extended Data packets in the two BW2 bursts (Fig. 2a).
The value of the Packet Number fields varies from 0 to 5, this means that it's a 2 x HDL6 transfer; looking carefully at CRC fields we note that the two HDL6 bursts carry exactly the same datagram: maybe the destination station requested a retransmission (the first BW1 ACK burst) or the datagram is sent twice so to improve the reliability of the transfer (Fig. 2a):

Fig. 2a
That said, we can focus on the Extended Data packets (below termed only "packets") of a single BW2 burst (Fig. 2b).
The values of the six Packet Number fields are: 0,1,2,3,0,1. If TxDatagram buffer is not completely emptied the remaining packet positions are filled with repetitions of packets already residing in other positions of TxFrame buffer. The HDL transmitter is at liberty to select packets from the current datagram to repeat as it pleases (the HDL receiver shall inspect the sequence number of each packet received without errors,and use this information to discard duplicate packets).
The original datagram, in this sample, is then composed of the packets #0 #1 #2 #3.

Fig. 2b
Looking at the Packet Byte Count fields in the first four packets (Fig. 2c) we see that the firts three packets carry 233 bytes of user data (as expected, since HDL) and the last packet carries 224 bytes of user data (the remaining 9 bytes are filled with "0" value bytes).
Thus, the length of the original datagram is (233 x 3 ) + 224 = 923 bytes. 

Fig. 2c
Back to the whole bitstream, once structured in a 1920-bit period (the Extended Data packet length), 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 of 923 bytes length (Fig. 3).

Fig. 3
The duplicated HDL6 burst (A,B), the retransmitted packets (C,D) and the "0" value bytes filling a single packet can be noted looking at the whole bitstream in Figure 4. 
Please note as the bitstream is misleading: at a superficial glance, one could think to four "Citadel" encrypted files!

Fig. 4

13 July 2017

a burst ARQ mixed system (MS110 & S4539)

transmission was spotted only once on 7906.0 KHz from 0603 UTC (tune time) until 0639 (signal off). It's a burst ARQ system in which one station uses STANAG-4539 and the other one uses MIL 188-110A, both running at fixed data rates (respectively4800 and 2400 bps) and carrying STANAG-5066 frames. 
Difficult to say who sends data and who send ACKs. Only the Stanag-4539 bursts have a relative good quality for their analysis (Figs. 1,2): these bursts in large part carry STANAG-5066 DTS control frames (D_PDU type 6) so the station that uses 188-110A could be the data sender, although their duration is very short. Most likely it's a test transmission.

Fig. 1 - frame structure of STANAG-4539 bursts
Fig. 2 - 287 symbols period of STANAG-4539 bursts
Since the different framings of MS110A and S4539, the two stations could use a "special" adhoc configuration or a sort of two-demodulation requirement so to discriminate the incoming signals.

It's worth noting that in many D_PDUs (S4539 bursts) the address of the destination node belongs to the block assigned to France (006.014.yyy.zzz) while the source address belongs to a reserved block (015.xxx.yyy.zzz).

Fig. 3

7 July 2017

STANAG-4538, optimized Asynchronous FLSU call ?

I copied these 3G-HF transmissions very often and, since the "extended" duration of the first burst, I always thinked to Asynchronous FLSU calls; but, apart from the un-expected ending BW5 burst, a careful examination of the first burst in some cases may reserve an interesting aspect as in the present sample.

Asynchronous FLSU calls consist of a sequence of Async_FLSU_Req PDUs sent consecutively on the channel: FLSU protocol use burst waveform 5 so an Async FLSU call can be easily detected in the ACF output screen just thanks to the BW5 spikes (Figs. 1,2).

Fig. 1 - BW5 timing
Fig. 2 - ACF output of an asynchronous FLSU request
Analyzing the recording in question, my analysis tool reveals only one initial BW5 burst, instead of the expected n-bursts (!), which is then followed by a block consisting of 2400Bd PSK-8 modulated symbols. I had a look at the on-air symbols and found that they have a 768-bit period length which corresponds to 256 PSK-8 symbols (Fig. 3).

Fig. 3
BW5 uses a Psuedo Noise spreading sequence that is generated using a table that just contains 256 values [S-4538 #13.9.6] thus the whole first burst match the BW5 waveform (also note the repeated patterns that characterize the bitstream).

Looking at the BW5 timing (Figure 1) and the ACF output screen of the signal (Fig. 4), it seems that the TLC (Transmit Level Control) section is sent only in the first BW5 burst while the following bursts are a bit shorter and consist only of the preamble and data sections, as shown in Figure 5.

Fig. 4
Fig. 5 - the Async FLSU request in question
This is in contrast with what I seen so far in Async FLSU requests in which the BW5 bursts are contiguously transmitted, each with its own TLC section (Figs. 2,6) 
Fig. 6 - ASsync FLSU request as depicted in STANAG-4538
Indeed, STANAG-4538 does not specify this point "The Asynchronous call begins with the LBT (for at least one dwell period), followed by the transmission of about 1.35N Async_FLSU_Request PDUs on the requested link frequency, where N is the number of channels in the scan list, and 1.35 is the duration of each dwell (in seconds)." [STANAG-4538 #5.1.3].

The initial TLC section is used for transmitter level control and receiver AGC settling [1], thus sending TLC sections in contiguous BWn bursts make a poor sense: it's my guess that probably the removal of the redundant TLCs is an optimized implementation adopted by this manufacturer.
By the way, my analysis tool fails because most likely uses a burst-duration approach in order to identify the waveform.

[1] Johnson, Koski, Furman, Jorgenson, "Third Generation and Wideband HF Radio Communications"
Existing HF radios were generally not designed with burst waveforms in mind. For example, MIL-STD- 188-141 military radios are allowed 25 ms to reach full transmit power after keying. While the transmitter radio frequency stages are ramping up, the input audio signal level is adjusted by a transmit level control (TLC) loop so that it fully modulates the transmit power. At the receiver, an automatic gain control (AGC) loop must also adjust to a new receive signal. To accommodate these characteristics of existing radios, the 3G burst waveforms begin with a TLC section of “throwaway” 8-ary PSK symbols that are passed through the system while the transmitter’s and receiver’s level control loops stabilize.