[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DVB-T receiver problem (OFDM symbol acquisition)
From: |
CEL |
Subject: |
Re: DVB-T receiver problem (OFDM symbol acquisition) |
Date: |
Mon, 2 Mar 2020 12:57:18 +0000 |
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
- Re: DVB-T receiver problem (OFDM symbol acquisition), (continued)
Re: DVB-T receiver problem (OFDM symbol acquisition), Ralf Gorholt, 2020/03/02
Re: DVB-T receiver problem (OFDM symbol acquisition), Ralf Gorholt, 2020/03/04
Re: DVB-T receiver problem (OFDM symbol acquisition),
CEL <=