dvbt_rx_demo.grc always crashes with GPF.

[drmpeg]

The dvbt_rx_demo.grc flowgraph always crashes immediately with a GPF. From dmesg -T:

[Sat Jan 18 16:07:43 2014] traps: python2[12682] general protection ip:b64b33af sp:a483fda0 error:0 in libvolk.so.0.0.0[b6410000+d5000]

This occurs with the Gaussian noise source enabled and a baseband file created from dvbt_tx_demo.grc. Also, it seems like the value of 0.0022097087 in the Multiply Const block is incorrect. Should it be 1/0.0022097087 instead?

[BogdanDIA]

I fixed a bug in OFDM sync code. Maybe it fixes the problem on your machine as the bug does not reproduce on mine.

[drmpeg]

I tried the new changes, but they did not help. However, by disabling volk (by commenting out the line #define USE_VOLK 1) in ofdm_sym_acquisition_impl.cc and dvbt_demap_impl.cc, the flowgraph does run. I get a nice constellation on the scope plot and the messages "Aquired sync - TPS OK for frame 1 or 3" and "Aquired sync - TPS OK for frame 0 or 2" appear many times (which I believe is good).

Unfortunately, the flowgraph does not output any Transport Stream. By placing a file sink at each block, I can see that the convolutional deinterleaver has no output. When the debug messages are enabled in that block, I can see that it never finds sync (it finds many 0xb8 bytes, but never 0x47).

I'm not sure why I'm having so much trouble. The dvbt_tx_demo.grc flowgraph does work fine and produces streams that decode perfectly with gbdvb. The setup here is a Dell T3600 with an Intel E5-1607 CPU. I'm running Ubuntu 13.04, but the 32-bit version (which may be the big difference).

[BogdanDIA]

You may try to increase the amplitude on the noise source that get's added to the signal. There is a problem with signals that have too big SNR and the result is that they do not get decoded. This situation does not happen in real life when the data is sent over real wireless channel.

I guess you have modified the constant value that the dvbt_rx_demo.grc and dvbt_tx_demo.grc use to scale (the value 0.0022097087 should be both on TX and RX).

Try running directly the flow graphs dvbt_tx_demo.grc and dvbt_rx_demo.grc without any modification to see if they are working.

[drmpeg]

After creating a baseband file by using a bladeRF in external loopback (with a 20 dB attenuator) running dvbt_tx_demo.grc, I've achieved a successful decode! The generated TS is completely error free after sync is acquired (only takes about 245 TS packets to get in sync). gbdvb cannot decode this file at all (possibly due to the big DC offset spike), so the gr-dvbt receiver appears to be much better.

The flow is still very unstable though. Sometimes it crashes right away with a GPF or segfault. Sometimes it works, but only produces a short TS file (176128 bytes of a normally 75000000 byte TS file). And sometimes it works perfectly.

I tried re-enabling volk in ofdm_sym_acquisition_impl.cc and dvbt_demap_impl.cc, but that still causes immediate GPF's.

However, the results are very encouraging, and I'm sure operation will become much better in time.

Plot is with no Gaussian noise added and multiply constant set to 0.22097087 instead of 0.0022097087.

[BogdanDIA]

Thanks for testing gr-dvbt. I believe the crashes are from VOLK and I remember having the same problems when started coding using a 32bit system. After that I switched to 64bit systems and newer version of gnuradio and the error has gone. But it seems the error is still there and somehow gr needs to be fixed.

[drmpeg]

I did a little debugging. In my version with volk disabled in ofdm_sym_acquisition_impl.cc and dvbt_demap_impl.cc, the remaining GPF is caused by this code in d_viterbi.c in the function d_viterbi_chunks_init_sse2().

for (i = 0; i < 4; i++) { mm0[i] = _mm_setzero_si128(); pp0[i] = _mm_setzero_si128(); }

I tried adding -mstackrealign to CMAKE_C_FLAGS, but it didn't help. BTW, using GCC 4.7.3 here.

[drmpeg]

The alignment of metric0[] and path0[] causes the GPF (when they end up on an 8-byte boundary, for example 0x0a7f5928). I'm not smart enough to align a C++ object, so I removed them from viterbi_decoder_impl.h and made them static in viterbi_decoder_impl.cc.

static m128i metric0[4] __attribute((aligned(0x80))); static m128i metric1[4] __attribute((aligned(0x80))); static m128i path0[4] __attribute((aligned(0x80))); static m128i path1[4] __attribute((aligned(0x80)));

This solves the GPF issue. The TS output still stops at around 176128 bytes sometimes, so I'll chase that down next.

[BogdanDIA]

It is a bit difficult to do this alignment in c++ w/o the c++11 standard and I will postpone this for a later release. For now I did add the variables as static functions because I will change the viterbi design anyway.

[nits-skydeploy]

hey, Hello dvb T/T2 masters. Great work by both of you. I can see my problem listed at many places but without any potential solution. Can you help me with that. I am not able to receive any signal after OFDM symbol acquisition block, the scope it empty and final ts file too. I dont get any errors about frequency offset or anything, just my output is empty. I am using RTL SDR as Rx and LimeSDR as Tx. Any solution???

Thanks in advance. Regards Nitin

[drmpeg]

Nitin,

This project is no longer supported. It's been transferred into GNU Radio itself in the Digital Television component. You should be using those blocks and flow graphs instead.

Also, an RTL-SDR can't support the default 8 MHz bandwidth of DVB-T. You'll need to use a sample rate that the RTL-SDR can support and match that at the transmitter.

[nits-skydeploy]

Thanks for your reply Ron. I am already using 5 MHz bandwidth with 1Msps sample rate (supported by RTL). I guess the issue also lies with the frequency correction. I used a frequency correction in RTL source and I got the video transmitted and decoded successfully at the receiver end. But now i am facing a new issue that the reception and decoding happens only once in a while. Most of the time i dont get any output. Any suggestions??

Thanks and Regards Nitin www.skydeploy.com

[drmpeg]

You can try the GNU Radio blocks. The OFDM symbol acquisition block has been enhanced quite a bit with input from the gr-isdbt folks.

Flow graphs are in <install_dir>/share/gnuradio/examples/dtv

[nits-skydeploy]

Thank you Ron. When I load the grc from gr-dvbt (downloaded from github, BogDan's repository) it wont show the blocks in GNURadio, I manually arranged the flowgraph by taking blocks from digital television menu given in GNURadio itself, but still this is the output that I get.

Regards Nitin www.skydeploy.com

[drmpeg]

That's about all I have for you. I always use commercial receivers, so I haven't bothered much with the DVB-T receiver.

If you think it's frequency offset, then the 2K mode may work a little better (since the carriers with be spaced further apart).

[nits-skydeploy]

Thanks Ron.

Regards Nitin www.skydeploy.com