29 April 2016

MS188-110: probe designation symbols D1-D2 and 200ms ACF

in a previous post I already talked about the way MS188-110 scrambler length affects the value of the ACF at certain data rates. Now I want verify the typical 200ms ACF  of a 2400 bps data rate (short interleaver): as seen in the above post, this ACF value is also met at other data rates along with the 66ms value.  Summarizing:
  • In case of low data rates (from 150 up to 1200 bps) four groups of the pairs probe+data count 160 symbols (4 x 40) and they are just in sync with the scrambler length (160 symbols) causing the strong 66.67mS ACF.
  • In case of the lowest speed (75bps data rate) the channel probes are not sent so the 66.67mS ACF is just due to the scrambler length (160 symbols).
  • In case of 2400 bps the pair probe+data counts 48 symbols (32 symbols for data +16 symbols for probe) and this value is not correlated to the the scrambler length, so the "visible" ACF in this wavfeorm, and in 4800 uncoded, is the known 200 mS or 480 symbols.
pic. 1

(Since we are talking about MS188-110 Serial Tone, I refer to "symbols" as over-the-air PSK-8 symbols).
But, why the 480 symbols ACF rather than the expected 48?

pic. 2 - strong 200ms ACF spikes in a MS188-110 signal
The short interleaver matrix dimension consists of 40 rows and 72 columns (= 2880 bit room) and is loaded in 600 ms. Indeed, for the 2400 bps data rate the FEC encoder results in 4800 bps coded rate, and so (4800 x 600)/1000 = 2880 are the bits transferred into the interleaver matrix during the 600ms short interleave load. At 2400 bps data rate the bits fetched from the interleaver matrix are grouped together as three bit entities that will be referred to as channel symbols and processed by the Modified-Gray Decoder (MGD). Then, the Symbol Formation function maps the three bit channel symbols from the MGD output into tribit numbers compatible with transmission using an 8-ary modulation scheme.
This means that from the short interleaver matrix we get 960 symbols that in turn will be transmitted into 30 data-blocks (unknown-data) each of 32 symbols (pic. 1). According to the framing table (pic. 1), each data-block is followed by a 16 known symbols sequence (probe). That said, the lenght of a interlever block will be 1440 channel symbols or 30 x (32+16).

The period of this waveform (pic.3) exibiths a 1440 bit lenght (not symbols!), or else 1/3 of the interlever block length: just ten data+probe frames, which are well visible in the bistream. Looking closely at the patterns of the last two probes (yellow circled in the picture) is visible a sort of discontinuity that is not present in the patterns of the middle probes.

pic. 3 - 1440-bit (or 480 symbols) period
The reason is the way those two probe patterns are formed (pic. 4):
 
MIL-STD 188-110 - 5.3.2.3.7.1.2 Known data”
During the periods where known (channel probe) symbols are to be transmitted, the channel symbol formation output shall be set to 0 (000) except for the two known symbol patterns preceding the transmission of each new interleaved block. When the two known symbol patterns preceding the transmission of each new interleaver block are transmitted, the 16 tribit symbols of these two known symbol patterns shall be set to D1 and D2, respectively, as defined in table XV of 5.3.2.3.7.2.1 and table XVII of 5.3.2.3.7.2.2. The two known symbol patterns are repeated twice rather than four times as they are in table XVII to produce a pattern of 16 tribit numbers.
(The three bit values of D1 and D2 also designate the bit rate and interleave setting of the transmitting modem during the Sync preamble sequence)
 
pic. 4
This is more clear when looking at the the probe patterns in the middle positions of each interleaver block (pic. 5)

pic.5 - middle probe patterns
and at the last two probe patterns P(n-1) and P(n) preceeding the transmission of one interleaver block. In pic. 6 these two probe patterns are shown as isolated.

pic. 6 - the two last probe patterns
The three rows, each of 1440 bit, identify one interleaver  block of 1440 channel symbols: the last two probe patterns are clearly visible (pic.7).
In my opinion the patterns of the last two probes of each interleaver block - or better the Designation Symbols D1, D2 - cause the 1400-bit/200ms ACF and they act as a sort of autocorrelation sequence.
 
pic. 7
Its worth noting that the 66.67ms ACF visible at lower data rates, and due to the scrambler length, corresponds to 480 bits and this value is a submultiple, exactly 1/3, of the 1440 bit period (200ms) that is due to the Designation Symbols D1,D2 in the last two probe patterns of the interleaver blocks. These two matters concurr to the two ACF spikes visible, for example, in the 150bps data rate waveform (pics. 8,9).

pic. 8
pic. 9
The Find Period function, running at the same level, prints out one unique 1440 bit value for the 2400bps waveform (pic. 10)

pic. 10

25 April 2016

playing with MARS-ALE v3.00 and FS-1052 DLP messaging


MARS-ALE is a Personal Computer based 2G-ALE Modem and Controller that in conjunction with a supported computer controllable HF SSB transceiver allows for HF ALE communications. MARS-ALE also provides an implementation of FED-STD 1052 (FS-1052) Appendix B, DLP Data Link Protocol, running over the integral software defined MS188-110A modem on the PC Sound Device. The latest MARS-ALE v3.00 and MS-DMT (MIL-STD Data Modem Terminal) versions can be downloaded from here: 

When used in conjunction with other programs such as Audacity, Signals Analyzer, MS-DMT and BEE (a bitstream editor), MARS-ALE is a great tool for practicing with MS188-110 ST and FS-1052 DLP waveforms: digital signal enthusiasts can prepare clear and clean waveforms for study, analysis and comparisons with real-world signals. Below is a  short FS-1052 DLP messaging example just to show and understand the educational possibilities offered by MARS-ALE.

Modem Type and Data Mode settings are configured as follows (pic. 1,2)

Pic. 1 - MS188-110 messaging settings
Pic. 2 -FS-1052 DLP messaging settings
As expected, since the overhead added by FS-1052 DLP the lasting of this transmission is longer than MS-188-110 SYNC sending the same message and at the same data rate (pic. 3)
 
Pic. 3 - lasting of the two transmissions
 
In pictures 4,5 I run two MARS-ALE sessions, acting as the transmitting an receiving modems,  linked by a virtual cable: since FS-1052 DLP is a Data Terminal protocol, no portions of the message are printed until the entire message is received error free.

Pic. 4 - entering the message to be sent via MS188-110 + FS-1052 DLP
Pic. 5 - transmitting and receiving modems
For the same reason, it's very interesting to note that a plain MS188-110 receiving modem, as for example MS-DMT modem, does not print any message in its output screen unless the HEX string "5C 5C 5C D3 00 00 00 00 00 00 00 00" (pic. 6) and that is just the frame sync pattern used to mark DLP processed traffic.

Pic. 6 - MS-DMT modem facing a FS-1052 DLP transmission
From FED-STD 1052 App.B "50.1.1.1 Frame sync pattern":  Each new transmission over the physical channel shall begin with a three byte (24-bit) frame synchronization pattern to identify the following traffic as DLP processed traffic. The frame synchronization sequence in hexadecimal format, shall be "5C5C5C". The sync pattern shall be transmitted such that the first eight bits in order of transmission are "00111010". Note: As shown here in transmission sequence, the left-most bits are the LSBs.


The FS-1052 DLP frame sync pattern can be easily seen by processing the ASCII-bits file obtained from the output of a common MS188-110 decoder as Sorcerer used in this example (pics 7,8): this way we get the bistream after removed the MS188-110 stuff

Pic. 7 - bistream after MS188-110 removal
Pic. 8 - FS-1052 DLP frame sync pattern
If a transmission contains more than one frame, a two-byte sync sequence shall be inserted between each pair of adjacent frames: this pattern (hexadecimal) is "5C5C" (pic. 9)

Pic. 9 - two-byte sync sequence between frames

The sync sequences, along with other control bits and CRC, are also visible looking at the output of the ASCII parser of the bitstream editor: note the lack of such bits in a plain MS188-110 transmission (pic. 10)

Pic. 10
From FED-STD 1052 App.B "50.1.1.5 CRC error control checksum": a 32-bit CRC following the Frame Headers and Data field shall conclude each protocol frame. After initially setting all 32 bits to one, the CRC shall be calculated using all bits of the frame starting with the Sync Mismatch bit and ending with the last bit of the Frame Headers and Data field. The generator polynomial for the CRC calculation shall be:

 x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1

After removed the sync patterns out from the bitstream, I tried to find all the possible 32-bit polynomial which match with the data length and CRC bits.. but it's a long time consuming procedure and I stopped it just after the first results (pic. 11)

Pic. 11 - find the CRC polynomial

Another interesting MARS-ALE tool is the TRACING dialogue (pic. 12). This feature provides seven check boxes to enable/disable the display of data related to Received (RX) Words, Transmitted (TX) Words, program States, program Events, program Commands, program Timers and FS-1052 parameters as shown in pic. 13.

Pic. 12 - the "tracing" dialogue
Pic. 13 - tracing FS-1052 DLP at work

FS-1052 DLP is typically implemented in computer software applications and not in the hardware modem, however some tactical radios do implement an embedded 1052 ARQ and Broadcast capability. 
Historically, in MIL-STD-187-721C, “Interface and Performance Standard for Automated Control Applique for HF Radio,” Appendix A (USAISEC TECHNICAL REPORT “ HFDLP HF DATA LINK PROTOCOL”) is provided which specifies HFDLP for use with MS188-110A.

23 April 2016

logs


05320.0 ---: Unid 0621 USB STANAG-4197 (08Apr16) (AAI)
07102.0 9A0MIL: Global ALE HF Network Zagreb, HRV 0613 USB MIL 188-141 2G-ALE sounding (15Apr16) (AAI)
08010.0 ---: Ukraine Mil, UKR 0620 (cf) MFSK-4 (double FSK) 100Bd 500Hz, (tones at -750, -250, +250, +750 Hz) (19Apr16) (AAI)
08132.0 BP21: German Police vessel Bredstedt, D 0632 USB MIL 188-141 2G-ALE calling BPLEZS (19Apr16) (AAI)
08132.0 BP25: German Police vessel Bayreuth, D 0634 USB MIL 188-141 2G-ALE calling BPLEZS (19Apr16) (AAI)
09239.8 ---: Unid 0815 (cf) FSK 100Bd/1000 not sending data (08Apr16) (AAI)
10170.0 OCI: Slovakian Mil, SVK 0643 USB MIL 188-141 2G-ALE calling SIP (13Apr16) (AAI)
10226.8 ---: Unid (prob Finnish Intel) 0814 (cf) Nokia MSG-Terminal FSK 301Bd/780 (13Apr16) (AAI)
10246.0 F11: Polish intel, POL 0700 USB  POL-FSK 100Bd/740 (22Apr16) (AAI)
10275.0 4236: Sonatrach, ALG 0730 LSB MIL 188-141 2G-ALE sounding (13Apr16) (AAI)
10315.0 ---: MAECT Bucuresti, ROM 0756 USB MIL 188-110 serial carrying zipped test email via STANAG-5066 HBFTP client (18Apr16) (AAI)
10315.0 ---: Unid (prob. NATO station) 0650 USB MIL 188-110 Serial carrying KG-84 encrypted data (13Apr16) (AAI)
10333.0 RCI: Saudi Air Force, ARS 1622 ISB MIL 188-141 2G-ALE calling NAI (13Apr16) (AAI)
10417.5 B10: Ukrainian x10 net, UKR 1353 USB MIL 188-141 2G-ALE sounding (13Apr16) (AAI)
10417.5 C10: Ukrainian x10 net, UKR 1601 USB MIL 188-141 2G-ALE sounding (13Apr16) (AAI)
10417.5 J10: Ukrainian x10 net, UKR 1623 USB MIL 188-141 2G-ALE sounding (13Apr16) (AAI)
10569.7 RFAL4: Unid net 1611 USB MIL 188-141 2G-ALE calling RFAL2 (13Apr16) (AAI)
10658.0 4017: Turkish red crescent TUR 0701  USB MIL 188-141 2G-ALE calling 3010 (22Apr16) (AAI)
10668.0 ---: Unid 0702 USB Arcotel MAHRS-2400 ALE burst (22Apr16) (AAI)
10677.0 RHI: Saudi Air Force, ARS 1628 ISB MIL 188-141 2G-ALE calling AAI (13Apr16) (AAI)
10724.0 ---: Iranian net, IRN 1557 (cf) Iranian-QPSK 468.75Bd (13Apr16) (AAI)
10729.0 ---: Unid (prob. V22) 1230 (cf) PSK-2 62.5Bd, 3 mins lasting (20Apr16) (AAI)
10750.0 GANOB1: GMRA net, LYB 1614 USB MIL 188-141 2G-ALE calling HQ1 (13Apr16) (AAI)
10750.0 GANOB10: GMRA net, LYB 1614 USB MIL 188-141 2G-ALE calling HQ1 (13Apr16) (AAI)
10786.0 ---: Unid 1545 USB STANAG-4197 modem (13Apr16) (AAI)
10790.0 152: Unid net 1615 USB MIL 188-141 2G-ALE sounding (13Apr16) (AAI)
10888.0 ---: Russian Navy, RUS 0705 (cf) CIS-Akula FSK 500Bd/1000 bursts (22Apr16) (AAI)
10980.0 ---: Chinese Mil, CHN 1617 LSB Chinese OFDM 30-tone bursts (13Apr16) (AAI)
11010.0 ---: Unid 0810 USB Arcotel MAHRS-2400 ALE burst (22Apr16) (AAI)
12394.0 ---: Unid 0746 USB Arcotel MAHRS-2400 ALE burst (22Apr16) (AAI)
12736.0 ---: Unid (prob Russian AF) 0620 (cf) FSK 100Bd/800 not sending data (13Apr16) (AAI)
12935.0 HLG: Seoul Radio, KOR 1455 CW "CQ de HLG QSX 12 MHz K" (09Apr16) (AAI)
13499.0 1114: Unid (prob. Moroccan Civil Protection, MRC) 1433 USB MIL 188-141 2G-ALE sounding (09Apr16) (AAI)
13514.0 ---: Israeli Navy, ISR 1440 USB hybrid HF modem (09Apr16) (AAI)
13538.0 ---: Russian Mil, RUS 0640 USB CIS-45 OFDM HDR modem_v2 40Bd BPSK (19Apr16) (AAI)
14421.0 BAL: Algerian AF, ALG 0823 USB MIL 188-141 2G-ALE calling CM3 (21Apr16) (AAI)
14489.5 ---: Unid (prob Russian Gov.) 0615 (cf) FSK 100Bd/2000 (13Apr16) (AAI)
14590.0 ---: Unid 0915 USB Arcotel MAHRS-2400 ALE burst (09Apr16) (AAI)
14672.0 ---: Russian Navy, RUS 0803 USB AT-3004D modem + CW opchat on 2^ channel "QRJ ? K" "QJB3 K" (09Apr16) (AAI)
14925.0 ANK: Finland MFA (prob. Embassy Ankara, TUR) 1147 USB MIL 188-141 2G-ALE calling HKI2 Helsinki (14Apr16) (AAI)
14925.0 HKI2: Finland MFA Helsinki, FNL 1143 USB MIL 188-141 2G-ALE calling ANK (prob. Embassy Ankara) (14Apr16) (AAI)
14925.0 HKI3: Finland MFA Helsinki, FNL 1209 USB MIL 188-141 2G-ALE calling ANK (prob. Embassy Ankara) flwd by SKY-OFDM 22-tone data (14Apr16) (AAI)
16161.0 5601:  Iranian AF, IRN 0936 USB MIL 188-141 2G-ALE calling 20001 (15Apr16) (AAI)
16175.0 ---: Russian AF, RUS 0700 USB VFT 3 x 100Bd/1450 + extra tone at ~3440Hz (pilot?) (19Apr16) (AAI)
16230.0 ---: Russian Intel, RUS 0830 (cf) CIS FTM-4, MFSK-4 150Bd (effective 37.5Bd) 4000Hz (tones at: -6, -2, +2, +6 KHz) 8 minutes lasting (22Apr16) (AAI)
16240.0 1326: Unid (prob.  Moroccan Civil Protection, MRC) 0811 USB MIL 188-141 2G-ALE sounding (21Apr16) (AAI)
16283.6 KVX53: US Dept of State station 0802 USB MIL 188-141 2G-ALE calling KVX51 (21Apr16) (AAI)
16283.6 KVX53: US Dept of State station 0818 USB MIL 188-141 2G-ALE calling KVX99 (21Apr16) (AAI)
16468.1 PHR: Unid network 0717 USB MIL 188-141 2G-ALE calling SHL (21Apr16) (AAI)
16468.1 PHR: Unid network 0725 USB MIL 188-141 2G-ALE calling GUN (21Apr16) (AAI)
16468.2 GUC: Unid network 1559 USB MIL 188-141 2G-ALE calling SHL (15Apr16) (AAI)
16468.2 GUN: Unid network 1304 USB MIL 188-141 2G-ALE calling SHL (15Apr16) (AAI)
16468.2 GUN: Unid network 1310 USB MIL 188-141 2G-ALE calling PHR (15Apr16) (AAI)
16468.2 PHR: Unid network 1313 USB MIL 188-141 2G-ALE calling GUN (15Apr16) (AAI)
16766.5 ---: Unid 1340 (cf +1500Hz USB) SiTOR-A 100Bd/170 "538678 STRN XTEST+ TST+TEST" (17Apr16) (AAI)
17415.0 ---: MFA Cairo, EGY 1325 USB (cf +1700 USB) SiTOR-A 100Bd/170 calling IPTX Havana (08Apr16) (AAI)
17912.0 014: ARINC Krasnoyarsk, RUS 1209 USB HFDL, working flight UP0003 (10Apr16) (AAI)
18350.0 LEB: Unid network 0702 USB MIL 188-141 2G-ALE calling KUL (15Apr16) (AAI)


20 April 2016

email over HF using STANAG-5066 DTS: a more interesting example


This recording is another example of sending compressed e-mail file using STANAG-5066 DTS and the MS188-110A serial waveform as "carrier" at physical layer: while the previous recording was relative to Polish Military, the present one concerns a BFTP transfer over HF link between two peers of Romanian MAECT - Minister of Foreign Affairs (...which surely use Harris hardware/software equipments). The transfer was heard on 10315.0 KHz/USB on 18 Apr, starting from 0756 UTC.

STANAG 5066 (Profile for HF Radio Data Communication) is a NATO protocol stack definition operated over HF modem/radio equipment. S5066 provides standard clients over SIS (Subnetwork Interface Sublayer) and an IP mapping/adaptation in order to make use of conventional IP applications over HF radio band in a transparent way. There exist three editions of S5066 specification. Edition 1, and Edition 2 radios do not attempt to transmit when it is known that another radio is transmitting. It means that the data exchange is node to node and no more than two peers may communicate at the same time. With the release of S5066 Edition 3, this problem was resolved by using CSMA and HFTRP methods. The DTS (Data Transfer Sublayer) are same for Edition 1 and 2, the  CSMA and HFTRP new features was added to DTS layer of Edition 3 maintaing backward compatibility with the 1,2 editions. 

I used k500 decoder to demodulate the heard transmissions and then passed to the analysis of the obtained bitstream, once removed the 188-110 overhead.

188-110 over-the-air symbols
 Since S5066 is a "protocol stack", it has up to eight different Packet Data Units (PDUs) available and then analyzing a S-5066 transfer we could face different packet lenghts as in a wireshark capture example in pic. 1
 
Pic. 1 - some S5066_DTS PDU types

Although the DATA_ONLY PDU (222 byte, or 1776 bit period) is the more often met, this sample is interesting since exhibits pronounced 29 byte (or 232 bit) period mostly due to the EXP_NON_ARQ_DATA PDUs in the last two 2400bps/L 188-110 messages (pic. 2).  The DATA_ONLY (1776 bit) is clearly visible analyzing the PDU in the first 1200bps/short 188-110 message (pic. 3).
 
Pic. 2 - 29 byte = 232 bit period mostly due to  PDU type 8: EXP_NON_ARQ_DATA

Pic. 3 - 222 byte = DTS PDU type 0: DATA_ONLY
 It's interesting to note in pic. 4 that all the four S5066 PDUs have the same pattern:

Pic. 4
I just focused on the first 1200bps/S 188-110 message since it's the one that just contains a valid DATA_ONLY PDU.
The presence of the file HBFTP--1.gz  into the bitstream after S5066 PDU-0 removal (pic. 5), reveals that the data transfer is performed using a compressed file and Basic File Transfer Protocol (BFTP): in this case the used protocol is HBFTP that stands for Harris BFTP.


Pic. 5 - the compressed file HBFTP--1
The Basic File Transfer Protocol (BFTP) is a very simple protocol (based on the ZMODEM protocol) and is not designed to be especially robust. It's used in conjunction with CFTP (and obviously S5066) to forward e-mails over HF links. Messages produced by an e-mail application are  compressed in CFTP, segmented in the S5066 Basic File Transfer Protocol (BFTP), and passed to the S5066 DTS. At the receiving node, this process is reversed, and the uncompressed e-mail message is delivered to the receiving e-mail application for delivery or forwarding (pic. 6)

Pic. 6 - S5066 as a "connecting link" between wired and HF networks

It's worth noting that S5066 may use two top protocols named RCOP (Reliable Connection Oriented Protocol) and UDOP (Unreliable Datagram-Oriented Protocol) which are the HF equivalents of the well-known TCP and UDP protocols used in wired (inter)networks. In a few words, S5066 is a sort of "Middle-Earth" between wired and HF network... but that's another story.

Back to the received BFTP file, once decompressed we get the original e-mail message (pic 7,8): it's a simple and nice test message that in my opinion can be safely shown because it's a not a "suepr secret" message  but just a simple e-mail "chat" between operators (I only obscured part of the involved addresses): they know what are doing when send clear text.

Pic. 7
Pic. 8
For nosey people, it's also possible to understand that "HARRIS2" uses HP computer (look at "...Received: from hp3254104...").

15 April 2016

MIL 188-110C App.D: BW3 KHz, SR2400 Bd, WALSH and PSK-8


Both the two signals A and B have the same duration and both have a long preamble-segment followed by the data-segment. The signals spread ~3KHz bandwidth and consist of a 1800Hz carrier with PSK-8 modulation at 2400 symbols/sec.

synchronization preamble segment
From MS188-110C App.D "The synchronization preamble is used for rapid initial synchronization and provides time and frequency alignment. The synchronization preamble shall consist of two main sections, a transmitter level control (TLC) settling time section, and a synchronization section containing a repeated preamble super-frame. The preamble super-frame consists of three distinct subsections, one with a fixed (known) modulation, one to convey a downcount, and one to convey waveform identification." The superframe shall be repeated M times. The Synchronization section shall be immediately followed by the modulated data (pic 1).

Pic. 1
Both the two sync preamble segments have the same lenght (~ 5 seconds) and the same ACF structure: 239.98 ms frame that makes 576 symbols or 1728 bits
From the 188-110C App.D documentation, the orthogonal Walsh modulation is used in the synchronization section of the preamble and the length of the super-frame is 18 channel-symbols, ie: 
9 (fixed) + 4 (downcount) + 5 (waveform identification)  
Since in 3KHz bandwidth waveforms the preamble channel-symbol is 32 symbol length (pic. 2), the length of each repeated superframe is: 18 (channel-symbols) x 32 (length of one channel-symbol) that makes the measured 576 symbols or 1728 bits (pic. 3). 

Pic. 2
Pic. 3
That's ok in pic.4, where the synchronization section of the two preambles exhibits a clear 1728 bit period length.

Pic. 4
data segment
The data segments have the same lenghts but different frame structures (pic. 5).
 
Pic. 5 - over-the-air bitstreams after removed the sync preamble

The frame structure for the signal-A waveform is the one shown in figure D-7 of Appendix D: the initial synchronization preamble is followed by frames of alternating data (unknown-data) and probe symbols (known-data):
 
After demodulating the signal the bistream analysis reveals a 288 symbols (or 864 bits) length frame, consisting of 256 unknown-data + 32 known-data (96 bits probe). This signal  meet the waveform ID-7 of the 3KHz bandwidth set (pic. 6)

Pic. 6a - WID-7 frame structure

Pic. 6b - WID-7 32 known-data (96 bits probe)

The signal-B waveform does not exhibit a data+probe structure but rather strong 853.4ms ACF spikes (pic. 7) that makes 2048 symbols/sec at 2400Bd speed or 6144 bits.  This signal meet the waveform ID-0, which uses a different structure after the synchronization preamble. Data “frames” are 32-symbol Walsh sequences (channel symbols), each corresponding to a single unknown (data) bit.

Pic. 7 - 2048 symbols ACF (~853.4ms) for the signal B

As shown in pic. 8 (after demodulating the signal-B) mini-probes are not sent in waveform 0, Walsh-coded data symbols are sent continuously after the initial synchronization preamble and the 2048 symbols (6144 bit) period is due to the scrambler lenght. For this waveform the data scrambling implementation just generates 256 x 8 or 2048 values and the scrambling sequences are continuously wrapped around the 2048 symbol boundary. Athough data are modulated using Walsh ortogonal modulation, they are scrambled to appear, on-air, as an 8PSK constellation.

Pic. 8 - WID-0 6144 bit period caused by the scrambler lenght

12 April 2016

odd CRC error (in a good signal)

Some days ago, just to spend some time, I was listening to  loud and clear HFDL messages exchanged between the ARINC ground station of Al Muharraq and some aircrafts. No problems for decoding all the messages but one of these failed due to a CRC error. Fortunately I was recording the IQ signal so I decided to undertand the reason of that CRC error, since the received signals were very good indeed.
Once isolated and demodulated the error burst I opened the resulting bitstream in order to verify the HFDL Physical layer protocol (PPDU) structure and it was ok. As expected: 25ms frame length corresponding to a 45 symbols frame for the data-segment, thirty of which are information-carrying (user data) symbols and fifteen are known 2-PSK probe symbols. I also detected the "T" string (000 100 110 101 111 repeated 9 times) closing the  preamble-segment (pics 1,2).

pic. 1 - PPDU structure
pic. 2 - bistream of the error burst after demodulation
From a certain point onwards the bistream shows a repeated regular pattern in the data field (pic. 3). The length of this repeated pattern is 120 bit: just as the legth of the PPDU scrambler (pic. 4). This could mean that there is no phase changes in the user-data or no data at input and in this situation the FEC decoder reveals errors in CRC computing.

Pic. 3
Pic. 4