HF Modem Bit Error Patterns

I am working on improving the performance of FreeDV on HF channels. As a first step I have been exploring the bit error patterns from the modem using some samples of a 1300 km HF radio path. These samples were kindly collected by Mark, VK5QI and Brenton, VK2MEV.

The FDMDV modem has 14 DQPSK data carriers. As I know the data that was transmitted, I can calculate the location of each bit error against time. Here are the bit error patterns for the 50W tx power sample, with the waterfall (spectrogram) of the same signal plotted below:

The red and blue lines indicate bit errors for the two bits modulated on each carrier. The number of each carrier (1 to 14) is on the LH axis. The x axis for both plots is time (500 bits/carrier and 10 seconds total).

At around 4-6 seconds on the waterfall we can see a fade in the top few carriers, with a corresponding burst of errors in the top few carriers of the bit error plot. Good.

However there are also two strange bit error effects. Firstly, the lowest few carriers have a permanently high bit error rate. The waterfall always shows a blue colour for these carriers – indicating a low power level. They are attenuated all of the time relative to the other carriers, as well as experiencing some fades at 2-3 and 8-9 seconds. Normally for a HF channel the level (and hence SNR and Bit Error Rate) should go up and down as the channel evolves. This suggests something is attenuating the carriers at around 500Hz, possibly some analog (high pass?) filtering in the SSB transmitter. It can’t be filtering in the receiver, as that would affect the level of both the signal and noise, and hence not affect the SNR or BER.

FreeDV has the ability to replay recorded samples from the SSB receiver. This gives an animated display of the spectrum and waterfall, which can show more information than a fixed image. Here is a screen shot of FreeDV replaying the 50W sample, also showing the lower tones being constantly attenuated:

In this case the waterfall is rotated (time on the vertical axis) compared to the waterfall plot above.

This sample has a centre frequency of 1200Hz. This has since been changed to 1500Hz, which I am hoping will fix the problem by moving the lower tones into a flatter region of the SSB radio passband. It does illustrate how important station set up can be for digital modes – we really want all the carriers to have the same TX power. We need a way to detect this sort of problem – otherwise we are introducing bit errors for no reason. Perhaps a “test frame” mode for FreeDV, so a friend can monitor the BER of each of your carriers, while you adjust your station.

The second strange effect can be observed in the bit error pattern for carrier 8. Bit errors are occurring at regular intervals, rather than the random distribution we would expect. Between symbols 300 and 400 (2 seconds) I count 9 bit errors. Now the FDM modulator waveform has a spiky nature, for example here is 10 seconds of the modulator waveform:

This because every now and again all of the carriers have the same phase, which sum to a big amplitude spike. The large spikes occur at a rate of 9 every 2 seconds. This suggests we are over driving the transmitter, causing distortion of the modem waveform and hence bit errors.

Lets look at a sample generated using 18W of transmit power (plotted below with corresponding waterfall). In this case there is less evidence of regularly spaced bit errors. This supports our theory that the TX was over driven in the 50W sample. However we can still see the effects of attenuation in the low frequency carriers (a high bit error rate). The bursts of errors sweeping through one carrier after another are also more obvious, corresponding to diagonal stripes on the spectrogram.

The next step is to gather some more off air samples using the 1500Hz centre frequency and see if the bit error pattern for the low frequency carriers improves. I am also coding up tests for interleaving and experimenting with unequal error protection schemes.

7 comments to HF Modem Bit Error Patterns

  • David,

    Nice work. I think we need a few “analog” test patterns to make the issues accessible to the operator. The stress here should be on allowing them to read with their meters or at most an oscilloscope. The fewer tools necessary, the more they’ll use it.

    1. Drive the TX continuously at the expected peak amplitude, single tone, so that the operator can adjust the maximum power.
    2. The classical two-tone pattern, two non-harmonically-related tones. Observe gross linearity problems in the beat note on an oscilloscope.
    3. Slow sweep, about 20% wider than our signal would be. Slow enough to see on a power meter if there’s obvious attenuation within the band. Maybe an oscilloscope versions of this too, with a faster rate.
    4. Amplitude ramp, slow enough to read on a power meter. Expose compression and clipping issues. Maybe an oscilloscope version of this too, with a faster rate.

    I like the idea of having FreeDV send a digital test pattern too. Besides the end-to-end test, I think a loop-back test would be good for testing the sound card.



    • david

      I like the idea of using a power meter, or even a simple (diode/capacitor) RF probe connected to a multimeter.

      FreeDV could be configured to generate alternate tones at the beginning and end of the pass band (say 1000 and 2000 Hz). Like a police siren, a few seconds of each tone. Measure the difference in power. A difference that is significant for FreeDV will be very obvious, e.g. 3dB across the passband will be a 50% drop in power!

      We will need to confirm that these static power measurements map to the same dynamic (FreeDV tx running) measurements. This could be confirmed with BER measurements at the Rx.

      For development purposes all the test signals we have described could simply be wave files that we play thru the rig interface, thats easier than modifying FreeDV.

      - David

  • Yes, this attenuation has been seen many times and can be caused by failing to have a flat TX response when switching modes to digital voice and retaining “EQ” settings or other “filters”. I’ve also noted this atteunation, however more on the higher carrier frequencies than lower. The signal as seen in a panadapter will be “slanted” caused by attenuation while the waterfall will show a dark area indicating the carriers with lower power. This problem is seen frequently with wider 2.4khz BW signals as used by WinDRM or with EasyPal. FreeDV’s narrow BW fits nicely in most SSB rigs TX filter.
    For best voice quality, I’ve found that very close attention must be made for the sound card Mic level input. It is easy to over drive and distort the audio. Modulation as seen in the TX window between 0.4 to 0.6 provide good results.

  • Perhaps a useful test pattern that could be generated would be to use a series of QPSK carriers spaced 75Hz part between 300Hz and 2100Hz just transmitting the sequence “Carrier #{N} {CALLSIGN} Station in test” on loop.

    The receiving app could then try decoding each of these and determine which ones are decodable and which ones are getting bit errors.

  • david

    Bill Cowley (in an email to me) noticed more red than blue errors in the tracks above and suggested the PSK symbol mapping might be incorrect.

    I am using:

    00 -> 0 degrees
    01 -> 90
    10 -> 180
    11 -> -90

    Should be:

    00 -> 0 degrees
    01 -> 90
    10 -> -90
    11 -> 180

    I ran the modem simulation on an AWGN channel with both mappings:

    Mapping SNR errors BER
    old 4.0 98 0.0090
    new 4.0 86 0.0079
    old 2.0 395 0.0364
    new 2.0 300 0.0276

    Well spotted Bill & thanks so much!

    - David

  • Patrick

    Seems like gray code now to me: 90° phase offset changes only one of two bits.

    How did you run the BER tests?
    With more data points I’d like to draw a SNR/BER-diagram, to compare for with FEC charts.

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>