Codec 2 HF Data Modes Part 3

It works! I’ve spent the last few weeks building automated tests for the new HF data modes. All three modes are working well over real world 40m/20m channels at distances between 100km and 3000km. My goals were:

  • Transfer a total 1 Mbyte of data – that’s quite a bit for HF.
  • Find some fast fading and long delay spread channels. Hence the 100km (NVIS) tests.
  • Run the tests over a week to experience a range of HF conditions.
  • Look for any corner cases that break the modems.
  • Collect a bunch of real world samples to support further development.

I ended up with 649 off air samples, that I can inspect by browsing the spectograms:

Here is a histogram of the SNRs tested:

The data modes work fine in simulation down to -4dB, so I’m pleased to see the same is true on real world channels. Curiously I didn’t get any really high SNRs, perhaps my station is too modest (IC7200 into a dipole). At some stage I will need to find a high SNR path to test QAM modes.

I did find a fast fading example (with bonus co-channel SSB):

The spectrogram of this sample shows the “barber pole” lines moving quickly as the notch sweeps through the modem spectrum:

Each test logs some data: in this case 5 good frames from 5 transmitted, despite the fast fading and SSB.

sdr.ironstonerange.com
datac3
waiting for KiwiSDR .
Tx data signal
Stopping KiwiSDR
Process receiver sample
modembufs:    183 bytes:   630 Frms.:     5 SNRAv:  3.66
BER......: 0.0354 Tbits: 10240 Terrs:   363
Coded BER: 0.0000 Tbits:  5120 Terrs:     0
Coded FER: 0.0000 Tfrms:     5 Tfers:     0
FrmGd FrmDt Bytes SNRAv RawBER    Pre  Post UWfails
    5     5   630  3.66 0.0354      5     0       0

Unfortunately I didn’t collect any large delay spread examples – these would show up as closely spaced notches in the spectrogram. In this example the notches are 700Hz apart:

… which means 1/700=1.4ms of delay spread. The worst case sample had notches spaced by 500 Hz (2ms delay spread). The modes I tested are designed to handle up to 6ms so they didn’t get much of a work out. I might need some help from friends in high latitudes….

Running a test

Each test is controlled by the ota_test.sh script, for example:

./ota_test.sh kiwisdr.areg.org.au

This records the received signal from the KiwiSDR while transmitting data frames using my HF radio. After the transmission is complete, the received wave file is run through the demodulator. The received frames are checked and we log some statistics. There are set-up instructions at the top of the script, and even some help:

./ota_test.sh

Automated Over The Air (OTA) data test for FreeDV OFDM HF data modems

  usage ./ota_test.sh [-d] [-f freq_kHz] [-t] [-n Nbursts] [-o model] [-p port] kiwi_url

    -d        debug mode; trace script execution
    -o model  select radio model number ('rigctl -l' to list)
    -m mode   datac0|datac1|datac3
    -t        Tx only, useful for manually observing SDRs which block multiple sessions from one IP

I also wrote scripts to automate the tests via cron, and to summarise results.

Looking at the data over time, I learnt a bit about HF propogation, e.g. I could see 100km NVIS falling over at sunset, but could still send packets 800km away for a few more hours (although with reduced performance). In the morning it was the reverse, I could see SNRs from a 800km path reducing, and NVIS SNRs building up.

I can think of a few improvements to my test system:

  • Rx from multiple KiwiSDRs at the same time, to collect data faster from multiple paths.
  • Add an option to pre-pend a wavefile with SSB for periodic station ID.
  • The system could be used to test voice modes: send a SSB signal, then a FreeDV voice mode signal, to compare them over the same channel. The samples could be normalised to the same peak power.

The tests also reminded me I haven’t tuned the compression (PAPR) of the data modes to get maximum performance out of them for a given peak power. Will work on that next.

Links
README_data – Codec 2 data mode documentation (HF OFDM raw data section)
HF OFDM Data testing – GitHub PR where I’m developing the automated tests.
Codec 2 HF Data Modes Part 1
Codec 2 HF Data Modes Part 2

6 thoughts on “Codec 2 HF Data Modes Part 3”

  1. Great stuff David
    one of the challenges of NVIS is in the morning when the optimal frequencies are changing fast .

    Beleive it or not- the rate of height rise of the reflection point (due to convection etc) is rapid enough at sunrise to cause several Hz of doppler and trouble for many high carrier count HF OFDM digital modes. …

  2. Hi David,

    (new e-mail address – aa@nhfn.net)

    Most impressive. I wonder what I need to do to setup 2 minimalist nodes that could interwork with what you already have running? Maybe 2-QCXs?

    It seems to me that a ‘direct’ 5351 based transmitter could be a cheap very wide band [0-200mhz] that gives a very clean RF signal.

    A wideband HF receiver could based on the opensource ubitx.

    It seems to me that most of the necessary blocks for an open source design are here!!

    warm regards,
    John NH USA

  3. Glen – thanks.

    John – yes I am also interested in low cost/minimal implementations of HF data terminals. Open source opens quite a few possibilities.

    1. It’s a good question Bill. A signal bouncing off different layers in the ionosphere means we have two signals arriving at the receive antenna with slightly different delays. At certain frequencies, they add in such a way that they cancel each other out. This creates notches in the frequency spectrum, spaced by 1/delay Hz. The ionosphere is constantly evolving, so the position of the notch moves, creating the barber pole effect. Faster fading will lead to the notch moving faster.

  4. Finally there’s a sight of a Pactor 3 replacement. Unfortunately, Pactor 3 was never really openly specified and I am surprised that it is allowed to be used legally in ham radio.

Comments are closed.