dvbt_rx_demo.grc always crashes with GPF. about gr-dvbt HOT 15 OPEN

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

from gr-dvbt.

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).

from gr-dvbt.

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.

from gr-dvbt.

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.

from gr-dvbt.

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.

from gr-dvbt.

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.

from gr-dvbt.

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.

from gr-dvbt.

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.

from gr-dvbt.

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

from gr-dvbt.

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.

from gr-dvbt.

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

from gr-dvbt.

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

from gr-dvbt.

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

from gr-dvbt.

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).

from gr-dvbt.

Thanks Ron.

Regards
Nitin
www.skydeploy.com

from gr-dvbt.