20 February 2018

6670.0 KHz, modified 188-110A Serial waveform

A confirm of the modified 188-110A Serial waveform, already heard on 6670 KHz and reported here. The change mainly consists of an added preamble consisting of 4 unmodulated tones at 500, 1500, 1700 and 2600 KHz as shown in Figure 1; the frequencies are comptated considering the calibration error of my SDR in this band.

Fig. 1
Data are sent using the standard 188-110A Serial waveform. It's worth noting the evidence of the 160-symbols scrambler that causes proununced 66.66 msecs ACF spikes: indeed, at slow data rates the lenght of the frame is 40 symbols (20 U + 20 UK) ie an integer submultiple of the lenght of the scrambler. The scrambler length is also highlighted by the 010101 trailer sequences sent at the end of each messages (Figure 2).

Fig. 2
 Each data block has the same initial 40-bit string repeated five times:
0000000001000000000010110000100000001001
and once synched the blocks to that string the resulting stream exhibits 4 x 88-bit strings in each data block, this may be due to the use of a 88-bit length key (Fig. 3)

Fig. 3
The data transfer follows a 188-141A handshake between the ALE calls "CAMP" and "HORBEN", possibly a German or Swiss net (still there is not a positive identification).


16 February 2018

OFDM 30-tones PSK-2 40Bd


Yet another unid (to me) OFDM transmission spotted by ANgazu on 4 MHz band by using a remote Kiwi SDR in Sweden (SM2BYC).
The waveform uses OFDM technology for 30 channels, 50 Hz spaced, modulation is PSK-2 in each channel with a symbol rate of 40Bd. The occupied bandwidth is about 1500 Hz. Speed and modulation are confirmed by analyzing the whole signal and also a single channel (Figs 1,2). A short preamble consisting of FSK-2 40Bd/320 bursts precedes the OFDM (Fig. 3).
The same signal was spotted by KarapuZ on may 2015, here his post in radioscanner:

Fig. 1
Fig. 2
Fig. 3
 

15 February 2018

A duble [5N2]N1 framing?

In case of an encrypted Async transmission the start bit and the n-stop bits that wrap the text are no more recognizable at the crypto device output, or - at  receive side - just after the removal of the HF waveform overhead (Figure 1).
 
Fig. 1
Well, actually this does not happen in case of the Swedish Army 8-bit text transmissions [1]. Indeed, looking at the bitstreams obtained after the 110A removal (regardless their different formats) we see clear 8N1 framings that wrap encrypted texts (Figure 2): as per above, we should not see those start/stop bits but only blocks of chipertext.

Fig. 2

I tend to think that it depends on the flowchart depicted in Figure 4:

Fig.4
Most likely the message is produced by an Async 5N2 system (ACP-127, other MHS,...), then the message is encrypted. The third block, downstream the encryptor block, processes the whole flow adding the header bytes and the so-called Z-string (see the above link). This is an Async 8-bit application/terminal that uses 1 start bit and 1 stop bit framing (8N1) so that the resulting stream sent to the 100A modem is a 10-bit framed stream: ie, a sort of a "5N2 in its turn framed into 8N1" schema.

One could say that the first three functional blocks could be accomplished with a single physical device (the dashed rectangle in Figure 4). In this regard, it's interesting to know that the Swedish Defence Materiel Administration (FMV) and the Swedish Armed Forces, in a joint project with Tutus Data, developed an off-line file encryption and decryption application for Windows called "Filkrypto PGBI" [3]: its typical usage is the secure transfer of sensitive or classified information. This way, the headers and Z-strings could be added by the encryptor block.

Quoting my friend J-S4538, who helps in this work, in the end, we don't know what data they transmit, if it is ACP-127, tactical data or other. It looks like they use two kind of modems or transmission systems, one uses the {}-protocol and STANAG-5066, the other one an old-school 8N1 terminal. Maybe one is for point-to-point the other one for broadcast. Or it is related to two different groups of stations.

Fig.5

11 February 2018

OFDM 20 out of 26 tones modem (possibly a Chinese waveform?)

The transmission has been spotted by ANgazu on 4102.0 KHz/USB by using a remote Kiwi SDR in Sweden. The signals consists of 4500 msec bursts, sent contiguously, and occupies a bandwidth of 2000 Hz (Figure 1).

Fig. 1
The waveform uses OFDM technology for 26 channels although 20 of these are used, ie the six tones 5,8,9,13,18,23 are off (at least in this sample). Modulation is PSK-2 in each channel with a symbol rate of 60Bd. Speed and modulation are confirmed by analyzing the whole signal and also a single channel (Figs 2,3).

Fig. 2 - analysis of the full OFDM spectrum
Fig. 3 - analysis of a single OFDM tone
KarapuZ suggets that it's likely a Chinese waveform, in this case the signal should be tuned on LSB. On my side I tried to synthetize a similar waveform although the results obtained (bandwidth and speed) are slightly different as shown in Figure 4.

Fig. 4 -synthetized OFDM 20-of-26 waveform
In another recording I also found bursts with 24 out of 34 tones up and PSK-2 modulation at 50 Bd (Fig. 5) , these short bursts are in between the groups of 20/26 bursts.

Fig. 5
A distinctive feature of the 20/26 waveform is its period that is formed by 14040 bits (Fig. 6): thanks to KarapuZ for the demodulated bitstream.

Fig. 6 - 14040 bits period


9 February 2018

unid FSK 400Bd/800 system


Unid FSK system heard around 1005z on 8800 KHz (cf +1200Hz) running at 400 Baud and 800 Hz shift (Figure 1). Unfortunately I went late on the signal so I missed the initial part of the transmission which could have provided more details useful for identification  (at least the encryption, if any).
Running the cross-correlation function, KarapuZ noted spikes at ~4007 msecs (Figure 2) that could mean a period of about 1600-1608 bits length. Hope to catch a complete transfer, but it will not esay.

Fig. 1



update
@Priyom.org sent me an interesting coment on my twitter account, I'm happy to share here in the blog, thanks my friend:
Hi, this 400Bd/800Hz system is likely yet another Polish Intel development. It is obviously different from their ACF=896 FSK's. It sends Mon/Thu 1000/1005z on 8800u. Here is a complete recording from yesterday:







6 February 2018

Logs (10 Jan - 05 Feb, 2018)

04362.0:---: Unid (poss. Italian GdF) 1823 USB R&S GM-2100 modem, proprietary HF waveform (PSK-8 2400Bd) carrying R&S X.25-like protocol (05Feb18) (AAI)
04494.0: OZ7: Polish Military, POL 1742 USB 188-141A sounding (05Feb18) (AAI)
04540.0: Unid (Russian Mil/Gov?) 1755 (cf) FSK system 75Bd/200, ACF=0 (11Jan18) (AAI)
05157.0: L: MX Beacon 0215 CW Morse ".-.." (25Jan18) (AAI)
06407.0: FN04: Algerian Military, ALG 0922 USB 188-141A calling XS02 (25Jan18) (AAI)
06467.5: JBT03D: Unid (French Navy?) 1444 USB 188-141A handshake LFY02D / STANAG-4539 3200bps bursts (01Feb18) (AAI)
06715.0: ADWSPR HF-GCS SIPR-net Andrews, US 2207 USB 188-141A sounding (04Feb18) (AAI)
06715.0: CROSPR HF-GCS SIPR-net Croughton, GBR 2334 USB 188-141A sounding (04Feb18) (AAI)
06715.0: HAWSPR HF-GCS SIPR-net Ascension Island, ASC 2228 USB 188-141A sounding (04Feb18) (AAI)
06715.0: JDGSPR HF-GCS SIPR-net Diego Garcia Island, DGA 2208 USB 188-141A sounding (04Feb18) (AAI)
06715.0: JNRSPR HF-GCS SIPR-net Salinas Puerto Rico, PTR 2220 USB 188-141A sounding (04Feb18) (AAI)
06715.0: JTYSPR HF-GCS SIPR-net Yokota Japan, JAP 2226 USB 188-141A sounding (04Feb18) (AAI)
06715.0: OFFSPR HF-GCS SIPR-net Offut, US 2257 USB 188-141A sounding (04Feb18) (AAI)
06715.0: PLASPR HF-GCS SIPR-net Lajes Field, AZR 2137 USB 188-141A sounding (04Feb18) (AAI)
07188.5: A02: Dutch Military, HOL 0838 USB 188-141A calling A14 (31Jan18) (AAI)
07461.5: ---: Unid 0945 USB 188-141A LP mode handshake / 188-110A Serial, sending Harris Citadel encrypted files (18Jan18) (AAI)
07602.0: TWBH6: Guardia Civil Huesca, E 1500 USB 188-141A sounding (13Jan18) (AAI)
07628.0: PI: (FPI) ARCN St. Assise French Navy, F 1435 J3E/USB wkg vessel 2BV, female voice-comms in French / RATT 75/850 KG-84 encrypted messages (13Jan18) (AAI)
07659.0: BS110A: Unid (Algerian net?) 0933 USB 188-141A calling BS110B (18Jan18) (AAI)
07714.2: SNB2: Unid 2157 USB USB 188-141A calling SNB1, AMD "GOOD COMMS ON THIS END. ALL GREEN." (05Feb18) (AAI)
07830.0: TZ01: Algerian Military, ALG 1005 USB 188-141A calling NX01 (25Jan18) (AAI)
07840.0: JAI: Saudi Air Force, ARS 0926 USB 188-141A calling SRX (05Feb18) (AAI)
07885.0: SHARK15: Unid (presumed Egyptian Net, EGY) 1346 USB 188-141A calling HQ2 (27Jan18) (AAI)
07973.0: Unid 0936 USB MFSK-11 125Bd/250, first tone at 650Hz, 792msec ACF = 99 quadribit symbols frame (11Jan18) (AAI)
08054.0: CP01: Algerian Military, ALG 0937 USB 188-141A calling NX01 (11Jan18) (AAI)
08054.0: MDN: Algerian Military, ALG 0941 USB 188-141A calling NX01 (11Jan18) (AAI)
08054.0: PG01: Algerian Military, ALG 0939 USB 188-141A calling NX01 (11Jan18) (AAI)
08058.6: KWT50: UD Diplo embassy 1134 USB 188-141A calling KWX90 / voice comms in English (10Jan18) (AAI)
09018.3: AOT: Iraqi Navy TOC Khawr al-Amaya Oil Terminal, IRQ 1519 USB 188-141A calling BOT (12Jan18) (AAI)
09018.3: BOT: Iraqi Navy TOC Al Basrah Oil Terminal, IRQ 1518 USB 188-141A calling NAVYNAT Iraqi Navy collective call (12Jan18) (AAI)
09018.3: NAVY2: Iraqi Navy HQ Umm Qasr, IRQ 1520 USB 188-141A calling BOT (12Jan18) (AAI)
10207.7: ---: Unid 1420 USB 3G-HF FLSU Async call (17Jan18) (AAI)
10272.5: 049117: German Red Cross, D 1358 LSB 188-141A sounding (12Jan18) (AAI)
10425.0: SDR: Unid 0927 USB 188-141A calling SRR (30Jan18) (AAI)
10433.0: ---: Russian Military, RUS 1338 FSK/MORSE flash message "XXX XXX WEGI WEGI 71988 09147 U*IBOHALL 6029 8105 K" (17Jan18) (AAI)
10755.0: 975: Unid (M14 variant?) 1408 CW, each group rptd twice "975 975 ... 975 975 8T6 8T6 23 23 = = 57231 57231 64T2T 64TTT 51763 51763 54253 54253 T1962 T1962 ... 5T312 5T312 = = 8T6 8T6 23 23 T T T T T" (17Jan18) (AAI)
10893.5: XDV: UK DHFCS station, G 1447 USB 188-141A handshake XSS / 188-110A Serial, 600-bit period protocol (17Jan18) (AAI)
11050.0: YA01: Algerian Military, ALG 1411 USB 188-141A handshake XV01 / 188-110A Serial (05Feb18) (AAI)
11130.0: X44: Moroccan Military, MRC 1025 USB 188-141A sounding (10Jan18) (AAI)
11135.0: HQ4: Unid (presumed Egyptian net, EGY) 1414 USB 188-141A handshake GANOB3 / CLOVER-2000 62.5Bd PSK2/PSK-4/PSK-8/2APSK-8 adaptive modem HAL "2020 Binary Transfer Protocol" sending email from BASE41 to ABORAMA1 (27Jan18) (AAI)
11161.0: ---: Unid 0930 USB 3G-HF 2-way FLSU handshake / 188-110A Serial, Circuit Mode service (05Feb18) (AAI)
11186.0: ---: Unid 0940 USB 3G-HF 2-way FLSU handshake / LDL512 transfer, sending 30KB Citadel encrypted file (10Jan18) (AAI)
11215.0: 400013: Unid Mauretanian net, MRT 0905 USB 188-141A calling 400001 (01Feb18) (AAI)
11217.0: UKE304: RAF E3D AWACS 1452 USB 188-141A handshake XSS / METAR TAF request & reply for EGXW (RAF ADDINGTON, England), EGVN (RAF Brize Norton, England), LEAB (Albacete, Spain), LEVC (Valencia, Spain) (05Feb18) (AAI)
11270.0: CENTR4: MAECT Bucharest centrala #4, ROU 0834 USB 188-141A calling OPZ unid Embassy (30Jan18) (AAI)
11396.0: ---: Unid 1558 USB STANAG-4197 ANDVT modem (04Feb18) (AAI)
11400.5: B99: Unid (possibly US Army Bio Unit ???) 1758 USB 188-141A sounding  (03Feb18) (AAI) [1]
11403.0: PEGASO: EVA (Escuadrón Vigilancia Aérea) Spanish AF Torrejón de Ardoz, S 0903 J3E/USB, daily radio-checks with EVA's stations (05Feb18) (AAI)
11424.0: ---: Russian Mil/Gov, RUS 0920 USB CIS-45 HDR modem V1 33.3Bd 62.5Hz BPSK (05Feb18) (AAI)
11426.5: ---: Unid 0903 USB 3G-HF 2-way FLSU handshake / LDL32, sending clear-text message (!) in Arabish (01Feb18) (AAI)
11430.0: ---: Unid 0945 USB 3G-HF 2-way FLSU handshake / HDL+ transfer using MIL 188-110C App. D HF waveform (10Jan18) (AAI)
11430.0: ---: Unid 1742 USB 3G-HF FLSU handshake / HDL+ transfer using 188-110C App.D HF waveform (03Feb18) (AAI)
11468.0  RDL: Russian Strategic Mil Bcast 1336 FSK/Morse flash msg "XXX XXX RDL RDL 33788 12440 OBODOWOIN 6866 5717 K" (31Jan18) (AAI)
12164.0: ---: Russian Gov/Mil, RUS 1010 CIS-45, OFDM 45-tone 40Bd BPSK HDR v2 modem (23Jan18) (AAI)
13499.5: ---: Russian Gov/Mil, RUS 0720 RUS-ARQ 100Bd/2000 (25Jan18) (AAI)
13877.0: ---: Russian Mil/Gov, RUS 0900 USB CIS-45 HDR modem v21 OFDM 45-tone 33.3Bd BPSK (31Jan18) (AAI)
14620.0: ---: MFA Cairo, EGY 1129 USB Codan 16 x 75Bd QPSK waveform (05Feb18) (AAI)


3 February 2018

STANAG-4538, LDL32 transfer bearing a clear-text message


The transmission was heard at 0904z on 11426.5 KHz USB (01 Feb 2018) and it's the first time I meet a clear-text message sent using a 3G-HF xDL protocol, in this case the LDL (Low-Latency Data Link) protocol.

In this transfer each LDL_DATA PDU carries a single data packet composed of 32 bytes of user data (LDL32 mode) followed by a 17-bit sequence number and an 8-bit control field (presently unused) added by the LDL protocol: this way the LDL32 PDUs are composed of 256+25 = 281 bits. The Burst Waveform 3 (BW3) is used for transfers of traffic data by the LDL protocol; BW3 computes and adds a 32-bit Cyclic Redundancy Check (CRC) to the LDL data packet plus 7 flush bits having the value 0, so the total length of an LDL32 BW3 is 281+32+7 = 320 bits (Figure 1).

Fig. 1 - LDL32 BW3 structure
As indicated in Figure 1, in order to get the user-data stream we have first to remove the first packet since it is sent twice, then remove the 64-bit LDL32 and BW3 overhead from each of the remaining 3 packets.  The result, 3 x 32-byte user data segments, is shown in Figure 2.

Fig. 2 - 3x32 byte user data segments
As you see the stream exhibits a 8-bit period and consists of a clear-text (not encrypted!) message composed using the  "Arabic chat alphabet" also known as Arabish:


KI YALHAG GHAZALI 3ANDKOM YAHBAT M3AH 5

"The Arabic chat alphabet is used to communicate in Arabic over the Internet or for sending messages via cellular phones. It is a character encoding of Arabic to the Latin script and the Arabic numerals.  Regional variations in the pronunciation of an Arabic letter can also produce some variation in its transliteration (e.g. ﺝ might be transliterated as j by a speaker of the Levantine dialect, or as g by a speaker of the Egyptian dialect)." [1] 
Since there are different transliterations depending on the region, and considering possible receive errors, the right English translation of the message is difficult. I tried to translate the received text directly into Arabic using the on-line google translator but got a bit poor meaning text ("So that you may go down with me") so I twitted a brief analysis hoping to have some useful comments... and I had them from my friends Guido (aka Decode_Signals) and - naturally - from KarapuZ.
Guido confirmed my opinion about the Arabish and advised the above link to wikipedia, while KarapuZ suggested another transliteration that probably makes a better sense: "(so that) he will come to Gaza with him" (Figure 3).

Fig.3 - the transliteration proposed by KarapuZ
I do not know who run the 11426.5 KHz frequency, AFAIK S-4538 is used in military environment, neither if the received text is a test message o a real message: maybe other messages (useful to understand the context) were sent just before and I did not hear them, anyway that frequency deserves to be monitored. 
I post the analysis for the same reason: anyone have some other comments or can shed a light on the meaning of the message?

[1] https://en.wikipedia.org/wiki/Arabic_chat_alphabet


1 February 2018

Baudot encoding with 1.5 stop bits (NATO maritime)

All NATO maritime transmissions (BCST, Ship to Shore and MRL) as well as being encrypted, use the standard 5 N 1.5 (1 start bit, 5 ITA2 data bits, and 1.5 stop bits), clearly a not synchronous standard (modem side). In particular on the BCST, by its nature, the clock is not fixed but varies from time to time according to certain algo. Synchronous transport (ie the cipher-modem chain) is used to recover it.
Although a single 7.5 bits length frame is quite easy to see in the time-domain,  its bit-oriented view is impossible at least in the tools at my disposal (unless to aggregate two consecutive frames and then get an integer number of 15 consecutive bits).
This difficulty about the representation of 7.5 bits frames may lead to misinterpretation and erros, as I did it (!) using SA/Bee to analyze what seemed a 150bps/500 Hz FSK burst transmission copied on 16155.0 Khz (cf). Speed was misured using the AM detector tool (Fig. 1)

Fig. 1
and once demodulated, each burst exhibits a 15-bit period (Fig. 2)

Fig. 2

But the ACF tells a different story: the signal  is structured in 7.5 bits lenght frames each consisting of 1 start bit, 5 data bit and 1.5 stop bits and duration of ~100 msec (Fig. 3). This means ITA-2 coding, commonly referred to as Baudot, and a speed of 75 bps!

Fig. 3
As said, the impossibility to represent an "half bit" makes that two consecutive frames are considered and then either the speed and the period are misrepresented!
The transmission can be decoded using a common Baudot decoder and setting the right speed (75bps) and shift (500Hz): it consists of ten groups of 5 figures per burst, as shown in Fig. 4. Removing the five extra-bits (start e stop bits) from the 15-bit period stream we just get the 61 ITA2 5-bit characters of each burst.

Fig. 4
It's worth noting that things are worse trying to force the speed to 75 bps: one bit is lost  (Figs 5,6)

Fig. 5
Fig.6
By the way, the 1.5 bit lenght of the stop signal is derived from the design of early teletype machines, which was designed this way because the electromechanical technology of its day was not precise enough for synchronous operation: thus the systems needed to be re-synchronized at the start of each character while the stop duration gave the system time to recover before the next start signal.

28 January 2018

CLOVER-2000 ARQ mode


This is a full transfer session recorded on 11135.0/USB 1414z between stations HQ4 and GANOB3 (supposedly belonging to an Egyptian network). Link is established and terminated using 2G-ALE  188-141A  and data are sent using a CLOVER-2000 HF modem.
Quoting from wikipedia "CLOVER is the name of a series of modem waveforms specifically designed for use over HF radio systems: CLOVER-II was the first CLOVER waveform  developed by Ray Petit, W7GHM, and HAL Communications in 1990-92.  CLOVER-2000 (aka XCLOVER or 8 Tone CLOVER) is a higher-rate and wider bandwidth version of CLOVER developed in 1995. CLOVER-400 is a special 400 Hz wide waveform that was developed for Globe Wireless"
CLOVER-2000 uses eight tone pulses spaced at 250-Hz centers, contained within a 2 kHz bandwidth between 500 and 2,500 Hz (Figure 1)

Fig. 1 - CLOVER-2000 spectrum
The eight tone pulses are sequential, with only one tone being present at any instant and each tone lasting 2 ms. Each frame consists of eight tone pulses lasting a total of 16 ms, so the base modulation rate of a CLOVER-2000 signal is always 62.5 symbols per second regardless of the type of modulation being used (Figure 2).

Fig. 2
In ARQ mode, all CLOVER Control Blocks use BPSK modulation and data (structured in 255-byte blocks) may be sent using five different types of modulation: BPSK, QPSK, PSK-8, 2APSK-8 (PSK-8 + 2-level Amplitude Shift Modulation), and 4APSK-16 (PSK-16 plus 4 ASM). The FEC broadcast mode of CLOVER-2000 is usually disabled although special formats are available for specific applications.
Since CLOVER-2000 is an adaptive system, you may find different modulations in the same transfer, as confirmed by the analysis of the heard trasnmission: in the following Figures I analyzed the tone #4 in different data blocks:

Fig. 3 - PSK-2
Fig. 4 - PSK-4
Fig. 5 - PSK-8
Fig. 6 -2APSK-8
An example of 4APSK-16 modulation, from a different recording, is shown in Figure 7: you may note the 4  levels of amplitude modulation. The recording is from radioscanner.ru

Fig. 7
➤ update
The sent message is encrypted BZIP2 compressed since the presence of the BZh11 sequence which marks the start of the compressed file (thanks to J.S4538). The name of the transferred file is in clear text "E_UNKNOWN_807_2701201.txt" in the header of the demodulated stream (thanks to KarapuZ for demodulation).

Fig. 8 - BZIP2 "BZh11" sequence
Fig.9 - file name

My friend J.S4538 also commented that the message is sent using the "2020 Binary Transfer Protocol" developed by HAL COMMUNICATIONS, the stations IDs in the play are ABORAMA1 (GANOB3 in ALE) and BASE41 (HQ4 in ALE).




25 January 2018

STANAG-4538, HDL+ BW7 frame structure


"The HDL+ protocol is used to provide acknowledged point-to-point delivery of datagrams from a transmitting PU to a receiving PU across an already-established HF link, with selective retransmission (ARQ) of data received in error. The datagram passed to the HDL+ entity for delivery is a finite-length ordered sequence of 8-bit data bytes (octets). Because it can adaptively employ a variety of signal constellations and degrees of coding, the HDL+ protocol can deliver datagrams of all sizes with high efficiency, under fair to very good channel conditions [...]"
"In an HDL+ data transfer, the sending PU and the receiving PU alternate transmissions in the manner depicted in Figure 1. Each transmission by the sending PU contains an HDL+ data header PDU (using BW6 waveform), followed immediately by an HDL+ data PDU (using BW7 waveform) containing payload data packets. After receiving each HDL+ header+data combination, the receiving PU transmits an HDL+ ack PDU (using BW6 waveform) containing acknowledgements of the data packets received without errors in the preceding HDL+ data PDU [...]"
 
Fig. 1

The end of a data transfer is reached when the sending PU has transmitted HDL+ data PDUs containing all of the payload data in the delivered datagram, and the receiving PU has received these data without errors and has acknowledged their successful delivery. When the sending PU receives an HDL+ ack PDU indicating that the entire contents of the datagram have been delivered successfully, it sends one or more (up to four) HDL+ EOT PDUs (using BW6 waveform), starting at the time at which it would have otherwise transmitted the next HDL+ data header PDU, to indicate to the receiving PU that the data transfer will be terminated. This scenario is depicted in Figure 2." (quoted from NATO STANAG-4538)

Fig. 2
Continuing to read S-4538 "Because it can use the high-order signal constellations (up to 64-QAM) of the STANAG 4539 High Data Rate waveforms, the HDL+ protocol can achieve very high data throughputs [...]" it may seem that HDL+ uses the waveforms described in S-4539 (or MIL 188-110C App. C) but actually uses a waveform with a frame structure of 288 symbols, as can be seen in Figures 3a and 3b (in this sample a PSK-8 2400 Bd modulation).
 
Fig. 3a - HDL+ frame structure (view)
Fig. 3b
Fig. 3b - HDL+ frame structure (analysis)
The structure of the frame is confirmed by the analysis of the demodulated bitstream in Figure 4: indeed the period consists of 864 bits that just make 288 tribit (PSK-8) symbols.

Fig. 4 - HDL+ demodulated bitstream (864-bit frame)
A frame structure of 288 symbols does not belong to NATO STANAG-4539, or the equivalent MIL 188-110C Appendix C, since all the S-4539 waveforms  - unless the preamble (obsoleted) - have a frame structure of 287 symbols! (Figure 5)

Fig. 5 - STANAG-4539 frame structure (287 symbols)
In terms of frame structure it is more correct to say that HDL+ BW7 PDUs, unless the sync preamble which is formed using BW6,  use the same structure of MIL 188-110C App.D 3 KHz waveforms, ie 288 symbols (Figure 6).

Fig. 6 - MIL 188-110C App.D frame structure
By the way, the analyzed transmission was recorded on 11430.0 KHz/USB at 1045z (Jan, 10).

https://yadi.sk/d/A_kkMKYl3RnEZP