Okay, just making sure since you mentioned gr-dvbt. I'll take a look at
the gr-isdbt acquisition block and see if the interpolation method can
be ported to GNU Radio.
It doesn't take much difference in sample rate to cause the problem. In
my setup, I'm using two different Ettus B210's (without GPS locking),
and it fails pretty quickly. I can make it run longer by using the test
block and manually adjusting the sample rate of one B210.
Ron
On 3/2/20 05:35, Ralf Gorholt wrote:
Dear Ron,
thank you very much for your quick answer.
I know that Bogdan donated gr-dvbt to GNU radio and I did not install
it seperately. It has been installed with GNU Radio using the package
manager. The commit you mention seems to be from december 2015, so I
suppose it is already in the package but I will check the source code
of the installed GNU Radio version when I am back at home.
As far as the drift is concerned, I will try your block and see what
it prints out. There might be a slight difference because some source
blocks accept only integer values as sample rates (if i remember
correctly the ADALM PLUTO does), but in my case a sample rate of 16/7
MHz is needed, which is not an integer value.
I suppose there is no way to correct a sample rate difference
automatically and for small differences resampling won't help either...
Kind regards,
Ralf (DL5EU)
*Gesendet:* Montag, 02. März 2020 um 13:42 Uhr
*Von:* "Ron Economos" <w...@comcast.net>
*An:* discuss-gnuradio@gnu.org
*Betreff:* Re: DVB-T receiver problem (OFDM symbol acquisition)
Did you read the README.md of gr-dvbt? It says:
/Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It
is now integrated in the mainline of gnuradio/gr-dtv./
The OFDM symbol acquisition block in gr-dtv has been upgraded with the
fixes from the ISDBT team. See this commit:
https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a
However, there is still an issue with the block. It can't tolerate a
sample rate difference between the transmitter and receiver. If the
difference is large, the block will fail fairly quickly (minutes).
I have a test OFDM acquisition block that prints out the drift. It can
be found here:
https://github.com/drmpeg/gr-dvbtx
You may have to go back one commit to make it compile with the latest
version of GNU Radio 3.7.
Ron
On 3/2/20 03:58, 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
