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:
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.
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