Peak/Average Power Ratio (PAPR) Improvements

The FreeDV FDMDV modem waveforms have a PAPR of around 12dB. That means the peaks of the waveform are 12dB higher than the average. So the average power of the signal is limited to 12dB less than the peak power of the amplifier.

Now the average transmit power sets the Bit Error Rate (BER) of the received signal. So if we can reduce PAPR, we can raise the average power without clipping the amplifier, and improve our BER. Peter Martinez, G3PLX, suggested that some hard clipping of the modem waveform might reduce PAPR without adversely affecting performance. Here are the results from clipping, obtained using the fdmdv_ut simulation in an AWGN channel:

Test (a) is the baseline unclipped modem waveform with a BER of 0.0134. If we clip the waveform to 0.7 of the peaks (b) in the same channel we get only a slight increase in BER however the PAPR has reduced by 5dB. This is very significant, as it potentially allows us to increase the transmit power, for example by 3dB (c) or even up to 5dB (d), with significant reductions in the BER.

This got me thinking about what happens in a SSB radio power amplifier if we drive it into compression, a somewhat softer form of reducing the peak level than hard clipping. So we tested various power levels on an IC7000 owned by Mark, VK5QI. A nearby receiver and FreeDV was used to monitor the SNR of the received signal. In this case the SNR (as measured by FreeDV) represents distortion due to compression, the tx and rx were so close that there was no significant channel noise affecting SNR.

We found that at 25W average power the radio became quite hot. A higher average power would not be practical. Now FreeDV users typically drive their tx at the 10-20W average level, this is a backoff from the peak 100W power of 10-7dB. This is similar to the 7dB PAPR obtained from the hard clipping experiments above. This is well into compression, but as we can see above the SNR is still quite high, so the distortion due to this much compression won’t affect the BER much.

So despite the PAPR reduction we found by experimenting with hard clipping above, it is not possible to get any further power benefits from PAPR reduction – we are already running the typical SSB power amplifier near it’s safe limits.

Codecs for HF DV

I spent some time watching the 1600 and 2000 bit/s modes introduced in the last post in action. I noticed they were still falling over on typical HF fading channels, especially in the 0-5dB SNR range. After some thought, I came up with some design ideas for HF DV modes:

1. Intelligible speech at around 10% raw BER for QPSK (averaging all carriers over over a few seconds).
2. For a FEC code to work with a raw bit rate of 10% BER we require a low code rate (e.g. 0.3), which means lots of parity bits (a high bit rate), and large block sizes.
3. But we are constrained by latency to short blocks, and the code rate is constrained by bit rate (e.g. its hard to get more than 2000 bit/s thru this channel).
4. So it is difficult to protect all bits in the Codec with FEC.

My previous tests show the excitation bits (pitch, voicing, energy) are the most sensitive. The excitation bits affect the entire spectrum, unlike LSPs where a bit error introduces distortion to a localised part of the spectrum.

So I dreamt up a new 1300 bit/s Codec 2 mode that has “less” sensitive bits. The 1300 bit/s Codec 2 mode only sends (scalar) pitch and energy once every 40ms, rather than twice for the previous 1600 Codec 2 bit/s mode. This reduces the 0 BER quality a little, but now there is “less to go wrong” (just 16 bits for the excitation) at high BER. Less excitation bits means they can be protected with just a few extra FEC bits. So I added a single Golay FEC word to protect 12 of the 16 excitation bits to get a total bit rate of 1600 bit/s over the channel. This is known as the new 1600 bit/s mode.

This table shows the difference between the 1300 and previous 1600 bit/s Codec 2 modes, you might be able to hear a small difference:

This table has some samples of the 1300 bit/s Codec 2 + 300 bit/s FEC (1600 bit/s FreeDV mode) over several simulated and real world channels, as shown in the table below:

The signal sampled from VK2MEV had a reasonably high SNR (above 5dB) but a high average BER due to the constant fading:

Note the number of frames in the 10 to 15% error range, and the near constant fading on at least one carrier. As the fading is so regular, the SNR is fairly steady. The last plot is the timing offset, which is slowly drifting downwards indicating a sample clock difference between the tx and rx sound cards.

The K5WH to K0PFX sample is an example of a SSB signal interfering with FreeDV:

You can hear the SSB and modem signals together in this sample of the off air signal. You can hear the FreeDV modem tones start up about 10 seconds in. The decoded speech (in the table above) holds up pretty well.

Command Line

octave:1> fdmdv_demod("/home/david/n4dvr.wav",1600*30,16,"mod_test_1600_n4dvr_001.err")
45952 bits  1321 errors  BER: 0.0287 PAPR(rx): 22.53 dB
david@bear:~/codec2-dev/src$ ./c2enc 1300 ../raw/ve9qrp.raw - | ./fec_enc - - 1600 | ./insert_errors - - ../octave/mod_test_1600_n4dvr_001.err 64 | ./fec_dec - - 1600 | ./c2dec 1300 - - | play -t raw -r 8000 -s -2 -


The 1600 bit/s mode uses simplified scalar pitch and energy quantisers. This makes it more robust to bit errors, but at a cost of increased bit rate. The increase equates to a 10log10(1600/1400) = 0.5dB drop in SNR, which is pretty modest. The 2000 bit/s mode uses the 1400 bit/s codec, plus 600 bit/s of FEC to protect the first (and most sensitive) 24 bits of the Codec data.

Here are the results over a simulated “CCIR moderate” channel with 10dB SNR:

Out of the digital modes, I think 2000 bit/s is best, with 1600 bit/s quite close. Compared to the analog, the digital has some annoying R2D2 sounds, but lacks the constant hiss. At 2000 and 1600 bit/s my goal of intelligible speech over a HF multipath channel is, I think, achieved. Here is a typical waterfall, bit error pattern, and SNR against time for this channel:

Note the sample files only play the decoded audio for the first 12 seconds, the plots cover 30 seconds.

Here are some results on a “CCIR poor” channel at 4dB SNR, followed by the waterfall, bit error pattern, and SNR plot against time. The poor channel has faster fading and with the low SNR we have a much higher BER (which averages 8% before FEC).

Although they are all pretty bad, in this case I think the 1600 bit/s version performs best. A QSO might “just” be possible. Actually it’s quite remarkable that we can hear anything given an average BER of 8%! I think the poorer performance of 2000 bit/s on this channel is an example of FEC breaking down at low SNRs/high BERs. The FEC is actually making more bit errors than it corrects! Digital voice is unique in the low SNRs/high BERs it operates in compared to regular data.

The fluttering at the start of the 1600 bit/s sample might be caused by bit errors in the frame energy parameter causing the level to jump around, or possibly bit errors in the voicing bit. If we know the channel is bad (the modem can tell us), we could “lock down” a few bits to enhance speech on poor channels. For example force all frames to be voiced, or smooth rapid changes in the energy. This could even be a “DV noise reduction” checkbox the operator can enable on poor channels. Try doing that with your closed source Codec!

The SSB sample is still very intelligible, perhaps better than the digital if you don’t mind the hiss. We still have a long way to go (maybe 6dB?) to do better than SSB in poor channel conditions!

Command Lines

The samples above were generated by some magical command line incarnations that run simulations of various parts of the system. Pathsim is used to generate modem files corrupted by the simulated HF channel. I then use a GNU Octave simulation of the demod to generate the bit error patterns for that mode/channel combination. For example the 1400 bit/s mode:

octave:18> fdmdv_demod("../src/mod_test_1400_poor_4dB.wav",1400*30,14, "mod_test_1400_poor_4dB.err")
38640 bits  2773 errors  BER: 0.0718 PAPR(rx): 16.20 dB

This means take the mod_test_1400_poor_4dB.wav file as input, demodulate 30 seconds worth of bits at 1400 bit/s, using a 14 carrier modem, and save the error patterns to mod_test_1400_poor_4dB.err. Running the simulation also generates a bunch of nice plots to help me work out what’s going on, some of which are above.

Next step is to insert the bit errors into a Codec 2 bit stream and decode the results. I do this with a bunch of piped command line tools:

~/codec2-dev/src$ ./insert_errors ve9qrp_1400.c2 - ../octave/mod_test_1400_poor_4dB.err 56 | ./c2dec 1400 - - | play -t raw -r 8000 -s -2 -


The “56″ above refers to the number of bits/frame for the 1400 bits/s mode. When testing the 2000 bit/s mode I use additional command line tools for the FEC, for example:

~/codec2-dev/src$ ./fec_enc ve9qrp_1400.c2 - | ./insert_errors - - ../octave/mod_test_2000_poor_4dB.err 80 | ./fec_dec - - | ./c2dec 1400 - - | play -t raw -r 8000 -s -2 -


And finally to generate a 12 second output wave file (this time for the 1600 bit/s mode):

~/codec2-dev/src$ ./insert_errors ve9qrp_1600.c2 - ../octave/mod_test_1600_poor_4dB.err 64 | ./c2dec 1600 - - | sox -t raw -r 8000 -s -2 - mod_test_1600_poor_4dB.wav trim 0 12


Simulating communications systems on the command line. Who needs a GUI?

Off Air Examples

Simulated channels are useful as the channel is the same for each run, so a direct comparison of the 3 modes on exactly the same channel can be made. However I wanted to backup these simulated results with some bit errors from real world, off air HF channels.

So last Saturday I hooked up with Mark, VK5QI, on 40m. It was a pleasant Summer (well early Autumn) evening for us. Mark and Andy VK5AKH set up a 40m dipole up the back of the Morialta Conservation Park in Adelaide, and were using a Codan 2110 Manpack for most of the testing.

I was operating “portable” in a backyard in Geelong, with an end fed dipole strung from an 8m squid pole. I was happy to find that my FT-817 with 2.5W SSB could reach 800km to Mark so we could coordinate the tests. At my end the analog SSB was noisy (beneath my urban S8 background noise level) but intelligible. Just the sort of channel I’d like FreeDV to work over.

Some pictures of Mark’s portable station are here.

I generated some modem files with test data sent using 14, 16 & 20 tones. Mark played these files to me over his tx at about 4W average power and I received and recorded them using the FreeDV “record from radio” feature on the Tools menu. We recorded several samples of each mode – and each sample was quite different due to the ever changing nature of HF radio channels. Later, I ran the recorded files through the simulations described above to produce samples of the bit error patterns and decoded voice over the three modes. Here are four examples of the 2000 bit/s mode, taken a few minutes apart, followed by the usual plots for one of them (serial 003). These are longer samples, about 30 seconds, to make sure we experience a few fades.

If you listen to sample 3, you can hear errors creep in at times corresponding to the low SNR (high BER) points in the plots above.

Sample 004 is an example of too much Tx drive. To illustrate this, Mark intentionally cranked the average power up from 4W to 11W, on a radio that is rated 25W PEP for SSB. This distorts the modem waveform, the BER goes up, and it sounds bad.

Unlike the simulations, the waterfall for off air samples shows the effect of the SSB rx AGC bringing the noise level up during fades, as it seeks to maintain the same average output level. The noise at the start and end of the waterfall is the channel noise before and after the 30 second test wave file.

This was a noisy but intelligible SSB channel for me, and FreeDV sounds OK over it. That’s pretty much what I am aiming at – for FreeDV to work about as well as SSB over HF multipath channels.

Next Steps

So now it’s time to try some real QSOs with these new modes and see if we have made any real progress. There is danger in getting too far ahead of oneself with simulations. A common mistake is getting a good result, declaring “victory”, then moving on when some bug is actually means you are fooling yourself. To support the new modes in FreeDV means quite a bit of coding which will keep me busy for the next week or so!

Once I am ready for testing the first step will be to establish the flatness of the tx response using this swept sine wave. Then ensure SSB works OK over a given channel, and start trying the new modes, in particular looking for examples of fading that break the modes.

Further down the track it would be nice to try different FEC and modulation schemes, lower Codec bit rates with strong FEC, attenuating or masking the annoying R2D2 sounds when there are bit errors, and (Peak/Average Power Ratio) PAPR improvements to increase our average transmitted power.

How You Can Help

I am interested in finding some more examples of channels that break the new modes. If you and a friend are set up for digital modes, then you can play and record wave files over a HF channel. By making off-air recordings of my modem test files, you can help me gather examples of real world HF channels, and help improve FreeDV.

Here is how you can help:

1. If you are using FreeDV and find it’s not decoding, switch to SSB and confirm you can still communicate OK.
2. Download and play these files (mod_test_1400.wav, mod_test_1600.wav, mod_test_2000.wav) over the channel, while your partner records the received audio. Make a separate recording for each file. The files are 30 seconds long, so I set the record time for 40 seconds. The FreeDV Tools-Record From Radio feature is a convenient way to record. It doesn’t matter if there is some noise at either end of the recording.
3. Name the recorded files mod_test_1400_yourcallsign.wav, mod_test_1600_yourcallsign.wav, mod_test_2000_yourcallsign.wav.
4. Email them to me.

Thanks!

Incremental Improvements

Over the past few weeks I have made some incremental improvements:

1. Bill Cowley pointed out the Gray code mapping was wrong. That’s worth up to 25% of the Bit Error Rate (BER).
2. Some SSB transmitters may have a non-flat frequency response. This can have a big effect on FreeDV performance. I encourage anyone using FreeDV to test your transmitters frequency response using this wave file and power meter. This file sweeps between 1000 Hz and 2000 Hz over 10 seconds. Just play it through the same rig interface at the same levels as you would run FreeDV. The power of the tone is about the same as the FreeDV modem signal. Monitor the variation in power over the sweep, for example if the power changes between 10W and 20W that’s a 3dB slope.
3. Improvements to the sync state machine algorithm to avoid sync dropping out so when a fade temporarily wipes out the centre BPSK sync carrier.

Testing FreeDV over HF Channels

I need a repeatable way to test the system. The first step was to generate a 30 second file (1400 bit/s x 30 = 42000 bits) of modulated test bits (112 bit sequence that repeat every 80ms) using the command line tools:

~/codec2-dev/src$ ./fdmdv_get_test_bits - 42000 | ./fdmdv_mod - mod_test_v1.1.raw


This file was converted to a wave file using sox and sent to some friends for transmission over the air. This gives me samples of bit errors over real HF channels. I have been passing it through the Pathsim HF channel simulator (which runs well on Linux under Wine):

After processing by Pathsim, I can use the Octave demod simulation to demodulate the signal and generate error patterns:

octave:12> fdmdv_demod("../src/mod_test_v1.1_moderate_10dB.wav",1400*30,"moderate_10dB_inter.err")


Here is the waterfall and bit error patterns for the CCIR 10dB Moderate channel:

Using my handy collection of command line tools I can then apply this bit error pattern to a Codec 2 bit stream and listen to the results:

/codec2-dev/src$ ./insert_errors ve9qrp.c2 - ../octave/moderate_10dB.err 0 55 | ./c2dec 1400 - - | play -t raw -r 8000 -s -2 -


Note ve9qrp.c2 is a 1400 bit/s Codec 2 file, the “0 55″ parameters specifies the range to apply bit errors to. This range lets me simulate the effect of errors on different parts of the Codec 2 frame. Not all bits are created equal. I happen to know that the excitation bits (voicing, pitch/energy VQ) are the most sensitive. They live in the first 20 bits of the 56 bit frame.

I am interested in using a (24,12) Golay code which can protect multiples of 12 bits. If we protect two blocks of 12 bits thats the first 24 bits protected. Lets assume this code can correct all bit errors. To simulate the effect of perfect FEC on the first 24 bits (with no protection on the last 32 bits) we can use:

/codec2-dev/src$ ./insert_errors ve9qrp.c2 - ../octave/moderate_10dB.err 24 55 | ./c2dec 1400 - - | play -t raw -r 8000 -s -2 -


This seems to work pretty well, as you can see from the samples below:

This suggests some FEC protecting the first 24 bits will give good performance on HF multipath channels, with intelligibility similar to analog SSB – but without the noise.

Increasing the bit rate

We currently use all of the 1400 bit/s for the Codec 2 data. We now need some more bits to carry FEC information.

One strategy is to make Codec 2 operate at a lower bit rate (say 1000 bit/s), then use the balance (say 400 bits/s) for FEC. This is tricky, as Codec 2 already operates at a pretty low bit rate. It might be possible if we make wider use prediction of the Codec parameters (i.e. sending differences), and/or vector quantisation (big tables to quantise a bunch of parameters at once). Prediction means the effect of an uncorrected bit error propagates into future frames. Vector Quantisation means a single bit error can change many parameters all at once.

So lowering the Codec 2 bit rate is likely to make the Codec more sensitive to bit errors. This might still be OK if we use blanket FEC protection of all bits. Some people prefer this approach, but I am not going to work on it for now. Instead I will stick with the 1400 bit/s speech codec and look at increasing the bit rate over the channel to provide bits for FEC.

Lets say we need to protect 24 bits/frame with a half rate code. That means we need a total of 56+24 = 80 bits/frame or 2000 bits/s. Some options are:

• Go from 14 to 20 QPSK carriers, this will make the bandwidth 20x75Hz/carrier = 1500Hz, and reduce the power per carrier by 14/20 or 1.54dB. The wider bandwidth may cause problems with the skirts of the Tx audio filtering. Twenty carriers will also make Peak/Average Power Ratio (PAPR) problems worse, perhaps reducing our effective power output further by requiring further tx drive back off.
• We could increase the symbol rate from 50 to 100 baud. This would reduce the energy/symbol by 3dB, but we would need only 10 carriers to get 2000 bit/s which means a power increase per carrier of 14/10 or 1.46dB so once again we have a difference of 3-1.46 = 1.54dB. The bandwidth of the signal would be 10*150Hz/carrier = 1500Hz. PAPR would be improved as we have only 10 carriers.
• We could go to 10 carriers using 8PSK, this would reduce our energy/bit by about 3dB (according to this graph), but we would gain 1.54dB by moving from 14 carriers to 10, giving a raw performance 1.46dB less than the current 1400 bit/s waveform. The bandwidth would be a very tight 10x75Hz/carrier = 750Hz, narrower than the current 1400 bit/s, 1100Hz wide waveform. PAPR will be better. The narrow bandwidth has pros and cons – good for channel density and interference, but bad for frequency diversity – a wider bandwidth is generally better for handling frequency selective fading.

Why does Analog SSB work so well?

I have been thinking about the differences between analog SSB and digital speech. I figure we might be able to learn from the strengths of Analog SSB:

• Frequency selective fading causes frequency selective filtering of the analog signal which is no big deal as speech is very redundant. With digital speech a freq selective fade may wipe out a bit that carries information for the entire spectrum, for example the voicing, pitch or energy bits.
• There is no memory in analog speech. An “error” in the speech spectrum only affects the signal at the time it occurs. A bit error in digital speech may affect future bits for a few 100ms, if predictive coding of model parameters is used (e.g. the pitch/energy quantiser in Codec 2).
• As the SNR drops the analog signal drops into the noise. The human ear is good at digging signals out of noise, although it can be fatiguing. Digital errors due to low SNR cause R2D2 sounds that the human ear finds harder to make sense of.
• Analog speech automatically applies more power to the perceptually important low speech frequencies, as the audio signal entering the microphone from your mouth has higher low frequency energy. So as the SNR drops the perceptually important low frequency energy is the last to go, an ideal situation.
• The FDM modem waveform is sensitive to clipping of the peaks. The analog signal processing of the SSB receiver and ear of the listener is not. So analog speech can be sent at a higher average power level.
• Codec 2 produces intelligible speech up to a bit error rate of about 2%. Now 0.02 of 56 bit/s frame is about 1 bit error. So if even one carrier is suppressed by a fade we are in trouble with digital speech.
• The FDMDV modem signal is narrower than analog SSB, so a fade of the same width wipes out proportionally more of the digital signal.
• A fade during silence (say between syllables or words) or in a low energy (inter-formant) area of the speech spectrum has no effect on analog signals. A fade in silence frames or in any part of the modem signal spectrum has an effect on the digital speech.

For comparison, here is the waterfall (spectrogram) for the analog SSB sample:



The strong vertical lines are due to clipping by the channel simulator as it’s AGC adjusts, this can also be heard as clipping in the analog sample. This is probably a set up error on my part. The comb like lines are the pitch harmonics of the speaker. Note the bandwidth is much wider than the FDMDV signal. Unlike the spectrogram of the FDMDV signal, it’s not obvious where the fades are. Most of the “area” of the spectrogram is low energy (blue) – silence in the time domain or low energy regions in the frequency domain.

Next Steps

The next step is to modify the Octave modem simulation so it support 8PSK as well as QPSK, and a run-time defined number of carriers. This can then be used to generate waveforms that can be played over the air or through the channel simulator. I’ll then build up some command line programs to send Codec frames that include various combinations of FEC.

As I suspected, the 12V battery was flat. I traced the problem to the DC-DC converter, which appeared to be dead. In an EV, the DC-DC converter works like the alternator in an internal combustion car. It converts the traction battery voltage (in my case about 120V) to 13.8V to power the 12V systems of the car and charge the 12V battery. In an EV only a small 12V battery is required. Just enough to power the 12V systems when the car is off and close the solid-state relay that switches power to the DC-DC converter when the car is “on”. Once the DC-DC converter is on it takes over, providing power to the 12V systems and charging the 12V battery.

The DC-DC converter must have died a few days before I left. The 12V battery by itself could supply the few amps required for a few days. Leaving the car for a month meant the 12V (lead acid) battery was further discharged. So there was just enough left in the 12V battery to run the car at night without the DC-DC converter for 10 minutes before it was completely discharged. No 12V power meant no power to close the contactor solenoid and the EV stopped – despite a nearly full traction battery.

I ordered a new DC-DC converter from EV-Works for $179 including shipping. To limp around until my new DC-DC converter arrived I manually charged the 12V battery each day. During day time driving the 12V system only draws a few amps to run the contactor, indicators, and brake lights. So I restricted my driving to day time to avoid the 14A load of the headlights.

A few days later the new DC-DC converter was installed in about 1 hour by crimping the connections to the existing wiring. The mounting holes fit the old DC-DC converter mounting holes under the passenger front seat. The new unit outputs 14.1V under light load, which delivered 13.8V to the 12V battery terminals. The 0.3V voltage drop is due to schottky diodes mounted on the battery terminals to prevent the battery discharging into the DC-DC converter when the car is off.

The DC-DC converter model I purchased was rated at 144V, with a minimum voltage of 115V. This was a concern, as my pack regularly drops beneath 115V under load. So I went for a driving test. With the headlights on high beam, and the car accelerating (bringing the traction pack voltage down to 110V) the DC-DC output voltage dropped to a minimum of 13.5V which is quite acceptable. Here is my clamp on ammeter next to teh new DC-DC converter measuring the “idle” current of the EV, I think it’s topping up the lead acid battery:

This new DC-DC converter doesn’t have a fan, the old one looked more like a PC power supply and had a fan that would stop and start as I drove. In fact it was noisiest thing inside my EV.

My EV is a one off prototype, so I expect occasional problems like this. Still 1 hours work and $179 in the 12 months since the last bug is not bad. My little EV has now done 33,000 electric km since conversion about 4 years ago.

Living Without a Petrol Car

About a year ago I sold my old ICE car, and have been experimenting with living with just the EV here at my home in Adelaide. It’s working out well.

The longest regular trip I make is to a friends country property, about 40km each way at 80-100 km/hr. I usually stay at his house for a few hours, charging while I am there to top up the pack. For an interstate road trip last year I rented an ICE car for 1 week, and some times I borrow my parents car when I need a 5 seater (my EV is limited to 4 seats).

I feel I am experimenting with different forms of car ownership. Rather than owning a long range ICE car and a short range EV, I am using an EV I own for 95% driving then temporarily using cars I don’t own for the rarer longer distance trips.

Codec 2 and FreeDV

This year because of my Codec 2 & FreeDV work I met many people who were involved with Amateur (Ham) Radio. Mark VK5QI, and Josh VK3XJM, set up portable antennas and worked some FreeDV from various sites around the conference. Although I am an author of FreeDV I don’t have an operational HF station to test it on, so it’s an eye opener for me to see it in action.

There is a lot in common between the Open Source and Ham Radio communities, for example experimentation, communication, sharing information, open hardware and software, and the way new comers are welcomed and helped. There are also some contrasts – the average age of Hams and Linux users are several decades apart and the majority of Hams use Windows.

I can see a lot of benefit in bringing the two groups together. Linux users are fascinated with radio, and Hams can benefit from open source.

I spoke on Open Source Digital Radio (Open Office slides and OGV video and MP4 video). I had some good feedback on my explanation of Codec 2, which is based on this Octave Script which I run during the presentation. The script has buttons to allow flipping between the time domain, frequency domain, and harmonic sample views. It allows single stepping through frames to create an animated effect. Watch the video to see how it comes together.

As I described last year there is an art to presenting a deeply technical topic (like speech coding) to an audience without specific domain knowledge. I want the talk to be interesting, comprehensible, and to send each member of audience away with 3 pieces of new knowledge. So I vary each presentation, and take care to observe what works and what doesn’t.

I was also involved with a great presentation by Joel Stanley. Joel is running FreeDV on an Android phone, using a homebrew Double Sideband (DSB) receiver.

Several people approached me after Joel’s presentation and commented on how they enjoyed Joel’s simple explanation of how radio receivers work. I noticed that Linux users are naturally interested in radio, and how things work in general. So a good approach for an engaging talk at LCA is to explain how technology used on the periphery of Linux works. Demystify it, make it less of a black box for the smart, but not domain aware LCA audience.

I would like to make a special thank you to Mark, V5KQI, who operated a radio transmitter so Joel and I could demonstrate FreeDV at LCA. Mark has also been very helpful with FreeDV testing and the development of Joel’s FreeDV on Android project.

Given the strong interest in radio topics, a conversation with Tridge lead to the idea of a radio miniconf for LCA 2014. Some possible topics:

• Get your Foundation license at lca.conf.au
• GNU radio tutorial
• FreeDV
• Build (solder) a SDR radio kit for the Ham, CB, or ISM bands.

Keynotes

A very good set of keynotes (available to view on line). They showed some really tough problems where progress were unfortunately being blocked by human nature. For example:

• Bdale Garbee covered (among other things) the lack of adoption of Linux on the desktop. One of the main reasons is that companies selling Windows PCs in high volume actually get income from Windows and demo-ware. Windows is a profit centre, not a cost. So selling a PC with Linux installed actually loses money!
• Radia Perlman spoke about networking protocols, and they are standardised. A key take away was that standards we consider to be sacred are often handed down by committees behaving like “drunken sports fans”! A funny and engaging talk.

Here is nice picture I took during the Speakers Dinner at the top of the Telstra Tower overlooking Canberra. LCA really does treat it’s speakers nicely:

I have a background in modems for satellite communications, which use non differential PSK and coherent demodulation. This has a 3dB advantage over DPSK, at the cost of additional complexity. The FDMDV modem used for FreeDV uses Differential Phase Shift Keying (DPSK). This is the usual choice for HF radio channels which have phase distortion due to multipath propagation. However 3dB is a big potential improvement, so I couldn’t help wondering if coherent demodulation would work for HF radio channels. So I wrote some Octave code to try it.

First I needed to develop a phase estimation algorithm that could be bolted onto the FDMDV demodulator, but using the same DPSK modulator and over the air specification. True coherent demodulation requires a unique word to resolve phase ambiguities. This isn’t possible with the current FDMDV modem specification as there are no spare bits. So I went for a pseudo coherent scheme where we coherently demodulate the PSK symbols, then pass them to a DPSK decoder. This has a performance hit compared to coherent PSK, but resolves the phase ambiguity without a unique word.

The function rx_est_phase() in fdmdv.m estimates the phase over a window of Nph symbols.

As a first step I plotted the scatter diagram of DPSK (top) versus pseudo coherent DPSK (bottom) for data from a real HF channel.

The psuedo coherent scatter plot looked a bit better to me so I decided to go a little further. I implemented a demodulator simulation that could measure bit error Rate (BER) for AWGN channels. During development I found that the phase estimator couldn’t be used to track frequency offsets larger than 0.5 Hz. I think this is because of the low 50 Hz symbol rate. So the existing DPSK demodulator was run in parallel to provide frequency offset tracking.

Here are the BER results for two Eb/No values (5 and 7 dB) for the two different algorithms.

The bit error rates are about half, which is a 1dB improvement. This is not very much, but I decided to “run it to ground” and test using some FDMDV modem data from real HF channels. Mark VK5QI kindly gathered these samples for me. Rather than Codec 2 data, a known test sequence is transmitted so BER can be determined at the receiver. The fdmdv_demod_coh.m script implements a demodulator that uses sample files as input.

Here are the results for 50W Tx power (VK2-VK5_20m_50W_TX.raw) using 1400*10 bits. The “Nph” parameter is the size of the window used to estimate the phase. More symbols means a smoother estimate but a slower response to phase variations.

Not a very impressive improvement, at best a 20% improvement in BER. The results with 18W of Tx power (VK2-VK5_20m_18W_TX.raw) using 1400*10 bits are also marginal:

On the HF channel we have multipath pushing FDM carriers down into the noise. My guess is that the HF channel can be modelled as either good, where the SNR is high, or bad, where a fade knocks out one of the FDM carriers entirely. A small improvement in demodulator performance only affects the transition between the two states.

So, the next step in improving FreeDV performance is to explore Forward Error Correction (FEC).