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