Testing a FDMDV Modem

A key use for Codec 2 is digital voice over HF and VHF radio. A few months ago I figured we needed to get Codec 2 on the air. With a PC, codec and modem software, two sounds cards, and a Single Sideband (SSB) radio it is possible to send and receive Digital Voice (DV) signals over HF radio.

This requires a HF modem optimised for digital speech, in particular fast sync, no multi-second training sequences, the ability to recover quickly after a fade, and no automatic re-transmit of “bad” packets. FDMDV was a working system for HF Digital Voice from a few years ago, so seemed like a good starting point. It embodies a lot of experience from Digital Voice pioneers like Mel Whitten.

FDMDV stands for Frequency Division Multiplexed Digital Voice. A FDM modem is a basically a bunch of slow modems running in parallel. For example FDMDV has 14 carriers spaced 75 Hz apart, each running at 50 symbols/second. Due to multipath problems on HF this approach works better than one carrier running at 14×50 = 700 symbols/second. On each symbol is encoded two bits using differential QPSK, so the bit rate is 1400 bit/s.

A few months ago I started experimenting with GNU Octave simulations of parts of the FDMDV modem. One thing led to another and I ended up writing an open source version of the FDMDV modem, based on the FDMDV spec.

I am in the final stages of the C version of that modem, currently writing command line demo programs. I am not sure what the “best” HF DV system would look like (Codec/FEC/protocol/modem) but I feel the best way to find out is build something and iterate on it. Rather than concentrating on the Codec alone I wanted to get some real world HF DV experience to tune and evolve the system as a whole.

The cool thing about open source is it attracts the best in the field. I have been in regular contact with HF modem gurus like Peter Martinez G3PLX (PSK31), and Rick Muething KN6KB (WINMOR) who have been very helpful with suggestions and support as I re-implemented the FDMDV modem. Rick also has some great ideas for more advanced modulation schemes (trellis coded PSK) that would be nice to try later. I have also had some great help from Bill Cowley, who has 25 years of PSK modem experience.

Testing the Modem

After developing the modem algorithms for about two months using GNU Octave I was ready to test over a real HF channel. So a few days ago I sent a wave file of the modem signal to Mel and Tony (K2MO). They kindly played the tones over a 925 mile HF channel and sent me a recording of the received signal.

I ran the files through my FDMDV modem code. On the first pass the scatter diagram was a mess and the Bit Error Rate (BER) was about 10% – suspiciously high.

Then I noticed the timing offset was changing very quickly, as you can see in the plot below:

The demod estimates the best time to sample the received symbols. This is known as the “timing offset”. In the real world the sample clocks used at the transmitter and receiver tend to be a little different, for example 8000 and 8001Hz. In our case the sample clocks are in the sound device hardware used to play and record the modem signals. So we expect the timing offset to drift a little. I had been simulating just such problems during the modem development, for example testing clock differences of up to 2000 ppm (16Hz at an 8000 Hz sample rate).

Now the demod code keeps an eye on the drift in the timing estimate, and reshuffles buffers every now and again to keep them from overflowing. Hence the saw-tooth effect.

If we count how many “teeth per second” in the saw-tooth, we can estimate the difference in the transmit and receive sample clock. I estimated about 2.5, of 40 samples each. So in every second that’s 2.5×40 = 100 samples, or a 100Hz difference, or 12500ppm! It’s like the PC playing the signal was at 8000Hz and the sample rate of the PC receiving the signal was at 8100Hz.

I re-sampled the signal to correct the large sample clock offset using Sox:
sox -r 8100 -s -2 for_david.raw -s -2 for_david_8000hz.raw rate -h 8000

and the results were perfect – 0 bit errors except for when there was SSB interference across the signal! This was very exciting for me – the first verification that my modem actually worked over real HF channels.

Turns out some sound cards can’t accurately sample at 8000Hz. This was something I had been warned of by my HF modem brains trust. The solution is to use the 48000Hz sound card rate, which most soundcards seem to be better at.

FDM Modem in Action

Here are samples of the first 5 seconds of the transmit and receive modem signal. Now look at the spectrogram of the received signal:

Time is along the x axis, frequency along the y axis. The “hotter” the colour, the stronger the signal. Our FDM signal is the parallel red lines between 600 and 1700Hz. Above the modem signal is some analog SSB. You can hear this as the high frequency “Donald Duck” sound in the received signal. Now around 2.5 and 3.3 seconds there are strong bursts of SSB right on top of our signal, in the 0 to 1100 Hz range.

So how does our modem do? The “Bit errors for test frames” and “Test Frame Sync” plots below tells the story:

Look at the centre plot, it is a measure of bit errors for each test frame received by the demod. Between 2.5 and 3.5 seconds you can see several error bursts. However the demod recovered quickly after the SSB interference. The BPSK sync and test Frame sync plots are unbroken, indicating our demo didn’t “lose it” during the interfering burst. If this was Codec (digital voice) data we would hear some degraded speech, but the system would soldier on between interfering analog SSB bursts. Just what we want.

This sample also shows some of the accumulated wisdom that went into the FDMDV system design. It is a narrow signal (just 1100Hz), so less sensitive to interference to adjacent users on the busy HF bands compared to a system using a full SSB bandwidth of say 2400Hz. Narrow band means we can pack more energy into fewer carriers. The signal to noise ratio is relatively high, and the BER due to gaussian type channel noise (AWGN) practically zero. Rather bit errors come from adjacent users and mutipath fading effects (the latter not illustrated here).

Next steps are to integrate the Codec and Modem into an easy to use GUI program for Windows and Linux. This will help us obtain some real world experience which we can use to tune and further develop the entire system.