Re: DVB-T receiver problem (OFDM symbol acquisition)

[CEL]

Hi Ralf,

wow, thanks for the extensive mail! Can't process it right now (at
work), but a few quick notes:

 * 3.7.11 is rather oldish, and upgrading to GNU Radio 3.8 would
   definitely be a good idea. In fact, on the current development
   version of GNU Radio, we even have enabled a few optimizations that
   make things /much much faster/.
 * Your debugging based on a file is on-point, excellent work
 * I also expect the output of the OFDM symbol acquisition to be
   constant. That might be a bug we fixed when we moved to GNU Radio
   3.8
 * All in all, if you're really still running GNU Radio 3.7, it'd be
   worth just trying with Debian Testing, which comes with our latest
   release, or at least debian stable / buster, which comes with
   3.8.0.0

Best regards,
Marcus
On Mon, 2020-03-02 at 12:58 +0100, Ralf Gorholt wrote:
> Dear all,
> 
> please apologize my long email but I cannot explain my problem and what I 
> have done so far in three words.
> 
> I am currently working on a DVB-T receiver project to receive transmissions 
> on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. 
> The flow graph is based on the examples in gr-dvbt. The transmitter is a 
> HiDes model HV320E. Reception works, but the video stops after one minute or 
> so while the constellation diagram is still active (dots are moving). I am no 
> expert and have only few knowledge of DSP and DVB yet, but to me the problem 
> seems to be in the OFDM symbol acquisition block.
> 
> Conditions:
> Linux Mint 19.3 in a virtual machine (VMware)
> GNU Radio 3.7.11 if I am right (I would need to check at home)
> 
> What I have done so far:
> 
> I have created a flow graph for a DVB-T receiver based on the examples in 
> gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 
> MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server 
> sink to which I connect with VLC media player to display the received video 
> transport stream. This works, but after one minute or so the video stops 
> while the constellation diagram is still active (dots are moving). I am 
> currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also 
> tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem.
> 
> To track down the source of the problem, I have created a file outside of GNU 
> Radio that I can use in a file source instead of the RTL-SDR source of my 
> flow graph. This allows me to make tests with an input signal that does not 
> change between different tests.
> 
> The data of this file are sent to the OFDM symbol acquisition block and the 
> output of this block is stored in a second file. When the input signal, the 
> algorithm and the parameters do not change between different tests I expect 
> the generated file to be always the same. However, this is not the case. The 
> files that are generated with the output of the OFDM symbol acquisition block 
> differ from each other. But when I send the content of one of those generated 
> files to the rest of the receiver and do this several times, I always get the 
> same transport stream at the output. I have verified this by using a file 
> sink and comparing the files. That’s why I suspect the OFDM symbol 
> acquisition block to be the culprit.
> 
> When I was searching the internet for information concerning my problem, I 
> found an email from 2015 in the archive of this mailing list where someone 
> wrote that the OFDM symbol acquisition block of gr-isdbt should be used 
> because it worked better than the one in gr-dvbt. I have done so and 
> installed gr-isdbt from git and replaced the block. However, there are two 
> such blocks in gr-isdbt and none of them solves my problem. They perform even 
> worse than the original block in gr-dvbt and after some time the program 
> terminates without a message.
> 
> I hope that my explanations are clear enough.
> 
> Is there anybody who can tell me what might be wrong here or what I am doing 
> wrong? Why is the output of the OFDM symbol acquisition block not always the 
> same when the start condition of every run is the same? Am I missing 
> something here?
> 
> Thank you very much for your help.
> 
> Kind regards,
> 
> Ralf

smime.p7s
Description: S/MIME cryptographic signature