Week 09 – There is music in the air!

I solved the Reed Solomon issue!

After implementing another Reed Solomon decoder (parts of libfec by KA9Q), both decoders would still not be able to correct any errors. Because I eliminated all possible prior issues and I excepted the possibility that both RS decoders were not properly implemented, the only remaining error source could be the source data itself. I never considered this point because the FIC data which derives from the same source, was always received properly and the firecode checked successfully. However, I did an analysis of the constellation diagram and the spectrum:

Constellation_bad.png
Figure 1: Constellation diagram and FFT plot

The SNR was not pretty great, as you can see. The antenna is placed in 5m height in a building near a window. I use a simple telescope antenna, that I adjusted to a length of λ/2.

λ/2 = (3e8 m/s / 208.064e6 Hz )/2 = 0.72m

The SNR could be raised with the following changes:

  • Place the antenna onto a well conducting ground (in my case a sheet metal): The telescope antenna is a ground plane antenna (monopole antenna) and needs a reflecting surface for the radio waves to “project” the monopole 180° in order to produce a dipole.
  • Reduce the length of the antenna: The knob at the end of the antenna is a capacitor. Its capacitive behavior extends the effective antenna length (the capacitor holds the current for a little while as if there would be more antenna lenght).

With the mentioned changes, the resulting physical channel improved, as you can see in figure 2. (The frequency synchronization is still not good (streched constellation clouds) but that is an other issue)

Constellation_goodSNR
Figure 2: Constellation diagram and FFT plot after reception improvement

After the improvements, the Reed Solomon decoder worked fine. Actually, the most frames had no errors at all and passed right away. In a first 30 seconds reception test, ~92,5% passed without errors, ~5% passed after errors were corrected and ~2,5% of the frames were incorrectable due to a long burst error (The burst error lasted 768 ms and consequently overran the time interleaving (360 ms) and the virtual interleaving of the Reed Solomon).

After eventually finishing the Reed Solomon decoder block, I could finally implement the MPEG 4 decoding block. It works fine and produces signed 16 bit integer (short) PCM samples with a sampling rate of 32 kHz or 48 kHz. The channel mode of the output PCM stream is always stereo, copying the duplicating the mono channel in case of mono mode.

Finally, I implemented a hierarchical python block which summarizes the whole decoding chain. It accepts the softbits from the OFDM demodulator and includes the whole channel decoding chain, the firecode checker, the Reed Solomon decoder and finally the mp4 decoding block. To match with the audio sink of GNU Radio, the 16 bit signed integers are finally mapped to [-1;1] float values.

A first coarse speedtest showed, that the decoder is clearly fast enough for a live running receiver (100% CPU calculation time / live runtime < 20% with 2.20 GHz processor and 4 cores). The implementation has a muli core support by default, thanks to the “thread-per-block” scheduler of GNU Radio. A code optimization, like many other DAB receiver implementations require (mainly optimization of the viterbi algorithm by using a precomputed version with known size, like done in the spiral project), is for now not required.

I also continued the implementation of the audio encoders. The Reed Solomon encoder block is finished and tested against the RS decoder in a loop-back test. The mp2 and mp4 encoder blocks are not completely finished yet.

 

Luca

One thought on “Week 09 – There is music in the air!

Leave a Reply