For over the air, the start condition can be different depending on
exactly where in the OFDM symbol the receiver starts capturing. When you
get the debug block working, you'll see it.
Ron
On 3/2/20 06:05, Ralf Gorholt wrote:
Dear Marcus,
Thank you too for your quick answer. I am struggling with GNU Radio
since the end of last year but it's getting better :-)
The reason why I still use version 3.7 is that it is included in
LinuxMint 19.3 and offers source blocks for RTL-SDR sticks and the
ADALM PLUTO (I have both devices). I am not familiar with building and
installing software on Linux from the sources. I had installed GNU
Radio 3.8.1 for testing but some source blocks were missing so I went
back to 3.7. However, since yesterday I know how I can build blocks
myself (I did it with gr-isdbt), so I will try version 3.8 again.
I am looking for a simple and reproductible solution that other people
are able to use without too much effort, because not every HAM is a
software or Linux guru and most of the people I know prefer Windows,
but that is another point. It is difficult to change habits. First I
need something that works reliably.
To come back to Rons mail, if a difference in the sample rates of TX
and RX caused the problem, shouldn't the program always fail at
exactly the same point (time) because the input data and start
conditions do not change? This is not the case.
To mention something that just comes back to my mind: as far as I can
see, the first difference in the files is always at a 16k boundary
(0x8000, 0xc000, 0x14000, ...) but this might be a coincidence.
Kind regards,
Ralf (DL5EU)
*Gesendet:* Montag, 02. März 2020 um 13:57 Uhr
*Von:* "Müller, Marcus (CEL)" <muel...@kit.edu>
*An:* "ralf.gorh...@gmx.de" <ralf.gorh...@gmx.de>,
"discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
*Betreff:* Re: DVB-T receiver problem (OFDM symbol acquisition)
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
