FreeDV 700D Part 3

After a 1 year hiatus, I am back into FreeDV 700D development, working to get the OFDM modem, LDPC FEC, and interleaver algorithms developed last year into real time operation. The aim is to get improved performance on HF channels over FreeDV 700C.

I’ve been doing lots of refactoring, algorithm development, fixing bugs, tuning, and building up layers of C code so we can get 700D on the air.

Steve ported the OFDM modem to C – thanks Steve!

I’m building up the software in the form of command line utilities, some notes, examples and specifications in Codec 2 README_ofdm.txt.

Last week I stayed at the shack of Chris, VK5CP, in a quiet rural location at Younghusband on the river Murray. As well as testing my Solar Boat, Mark (VK5QI) helped me test FreeDV 700D. This was the first time the C code software has been tested over a real HF radio channel.

We transmitted signals from YoungHusband, and received them at a remote SDR in Sydney (about 1300km away), downloading wave files of the received signal for off-line analysis.

After some tweaking, it worked! The frequency offset was a bit off, so I used the cohpsk_ch utility to shift it within the +/- 25Hz acquisition range of the FreeDV 700D demodulator. I also found some level sensitivity issues with the LDPC decoder. After implementing a form of AGC, the number of bit errors dropped by a factor of 10.

The channel had nasty fading of around 1Hz, here is a video of the “sample #32” spectrum bouncing around. This rapid fading is a huge challenge for modems. Note also the spurious birdie off to the left, and the effect of receiver AGC – the noise level rises during fades.

Here is a spectrogram of the same sample 33. The x axis is time in seconds. It’s like a “waterfall” SDR plot on it’s side. Note the heavy “barber pole” fading, which corresponds to the fades sweeping across the spectrum in the video above.

Here is the smoothed SNR estimate. The SNR is moving target for real world HF channels, the SNR moves between 2 and 6dB.

FreeDV 700D was designed to work down to 2dB on HF fading channels so pat on the back for me! Hundreds of hours of careful development and testing meant this thing actually worked when it went on air….

Sample 32 is a longer file that contains test frames instead of coded voice. The QPSK scatter diagram is a messy cross, typical of fading channels, as the amplitude of the signal moves in and out:

The LDPC FEC does a good job. Here are plots of the uncoded (raw) bit errors, and the bit errors after LDPC decoding, with the SNR estimates below:

Here are some wave and raw (headerless) audio files. The off air audio is error free, albeit at the low quality of Codec 2 at 700 bits/s. The goal of this work is to get intelligible speech through HF channels at low SNRs. We’ll look at improving the speech quality as a future step.

Still, error free digital voice on a heavily faded HF channel at 2dB SNR is pretty cool.

See below for how to use the last two raw file samples.

sample 33 off air modem signal Sample 33 decoded voice Sample 32 off air test frames raw file Sample 33 off air voice raw file

SNR estimation

After I sampled the files I had a problem – I needed to know the SNR. You see in my development I use simulated channels where I know exactly what the SNR is. I need to compare the performance of the real world, off-air signals to my expected results at a given SNR.

Unfortunately SNR on a fading channel is a moving target. In simulation I measure the total power and noise over the entire run, and the simulated fading channel is consistent. Real world channels jump all over the place as the ionosphere bounces around. Oh well, knowing we are in the ball park is probably good enough. We just need to know if FreeDV 700D is hanging onto real world HF channels at roughly the SNRs it was designed for.

I came up with a way of measuring SNR, and tested it with a range of simulated AWGN (just noise) and fading channels. The fading bandwidth is the speed at which the fading channel evolves. Slow fading channels might change at 0.2Hz, faster channels, like samples #32 and #33, at about 1Hz.

The blue line is the ideal, and on AWGN and slowly fading channels my SNR estimator does OK. It reads a dB low as the fading bandwidth increases to 1Hz. We are interested in the -2 to 4dB SNR range.

Command Lines

With the samples in the table above and codec2-dev SVN rev 3465, you can repeat some of my decodes using Octave and C:

octave:42> ofdm_ldpc_rx("32.raw")
EsNo fixed at 3.000000 - need to est from channel
Coded BER: 0.0010 Tbits: 54992 Terrs:    55
Codec PER: 0.0097 Tpkts:  1964 Terrs:    19
Raw BER..: 0.0275 Tbits: 109984 Terrs:  3021

david@penetrator:~/codec2-dev/build_linux/src$ ./ofdm_demod ../../octave/32.raw /dev/null -t --ldpc
Warning EsNo: 3.000000 hard coded
BER......: 0.0246 Tbits: 116620 Terrs:  2866
Coded BER: 0.0009 Tbits: 54880 Terrs:    47

build_linux/src$ ./freedv_rx 700D ../../octave/32.raw /dev/null --testframes
BER......: 0.0246 Tbits: 116620 Terrs:  2866
Coded BER: 0.0009 Tbits: 54880 Terrs:    47

build_linux/src$ ./freedv_rx 700D ../../octave/33.raw  - | aplay -f S16

Next Steps

I’m working steadily towards integrating FreeDV 700D into the FreeDV GUI program so anyone can try it. This will be released in May 2018.

Reading Further

Towards FreeDV 700D
FreeDV 700D – First Over The Air Tests
Steve Ports an OFDM modem from Octave to C
Codec 2 README_ofdm.txt

12 thoughts on “FreeDV 700D Part 3”

  1. 700D sounds good. We are looking forward to do some tests on 80 meter ( with lots of qsb and qrm).
    Good work David. 4 times a week we now are active with 700C, but 700D looks very promissing.
    Hoping to use the GUI with 700D soon.
    In behalve of the Dutch FreeDV group thanks for your effort.
    Kind regards, best 73, Hans PA0HWB

  2. Great work, can’t wait to see how low snr codec 2 can support.

    I have been working on ldpc over gf(255) and am am planning to release an open source implementation of it (hopefully next week if I am done with being sick from cold). I will add a link here when it is done.

    According to several papers that should provide more error correction than normal ldpc for the same block length. The downside is performance. Currently it runs around 8x 700bps using 8 threads on an i7. I hope to speed it up 8 times more using simd. It should be sufficient for desktop use but may be too slow for embedded.

    1. Hey that sounds cool.

      700D starts to get bit errors at -2dB SNR (3000Hz noise BW) (3dB coded Eb/No, 0dB uncoded Eb/No) with the current (224,112) code on AWGN. There’s a link budget spreadsheet in codec2-dev/octave.

      Would be happy to work with you to test your code, e.g. I could supply LLRS to your LDPC decoder from the OFDM demod.

      1. Scatterplot for of understandable (but not fully corrected) codec 2

        Great. I do still don’t know the performance of my LDPC solution as i have only tested it on air (and since i use 1.07 as log base for my LLR’s some numbers are based on trial and error). I have uploaded all the code now to github ( ) including two codec2 transmissions over AWGN(ish) channels and the resulting c2 files. There are still some work left, but i think it can be tested fairly easily to see if it actually is better than the normal LDPC.

        1. This post on 700C and Short LDPC Codes has BER v Eb/No curves for the (224,112) code (labeled rate 1/2 HRA 112 112) for AWGN and fading channels. On AWGN we hit the 1% BER target at Eb/No=2dB. IIRC the Shannon limit is about 0.2dB. Can you pls plot your codes BER v Eb/No performance?

  3. It seems like the results are wrong and we were celebrating too early. When making the graphs i posted managed to trick the script to think the block codec was a -0.5 rate codec (and thus the script provides the appropriate SNR). Currently i get graphs in the middle between diversity and the other LDPC codecs. I will see if it is possible to improve that.

    1. Well good work on spotting the error! Coding gain calculations are complex, I always get confused. I’m a FEC noob myself. I am happy my work has provided you with useful references.

      now contains new graphs with a code generated by a script doing random changes to the block code (and testing it with an adaption of the octave script). The PER is better than the normal LDPC codec (but the BER is worse, as it it seems to mess up the packets it can’t correct more).

      The questions i have is if it is ok to have a worse BER if the PER gets better and how much cpu time the PER improvments are worth?

      1. Based on informal listening tests I have a target of 1% BER and 10% PER for acceptable speech, it would be best if both targets were met at the same Eb/No.

        Might also be interesting to test your code with interleaving – as the HF channel is the real problem.

        We don’t seem to be CPU limited with the current FEC, I measured the entire FreeDV decoder stack (“$ time freedv_rx ….”) using 1% of CPU on an average laptop. The source data bit rate is only 700 bit/s ….

Comments are closed.