Hi Ron,
when I adapt the parameters of my flow graph I get exactly the same
result with your file as you do.
Kind regards,
Ralf
Am 03.03.2020 um 02:22 schrieb Ron Economos:
Yes, changing back to uint16_t is correct. But something is not
correct with your file. When you read from a file, sample rate doesn't
matter. You shouldn't see any drift at all.
I have a test file on my website. It can be downloaded at:
http://www.w6rz.net/adv16.cfile
It's 934,551,552 bytes
It's meant to be run with the default test flow graph, dvbt_rx_8k.grc
(8K, 2/3, 16QAM, 1/32 GI). On my setup, I get the following from the
debug block every time.
OFDM Symbol Acquisition Restarted!
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
>>> Done
That file was created by just using the transmitter test flow graph
(dvbt_tx_8k.grc) and writing to a file instead of transmitting over
the air.
Ron
On 3/2/20 12:45, Ralf Gorholt wrote:
Dear Ron,
the fixes seem to be included in the version that I have installed
(3.7.11-10).
I have tried to build your debug block but I get an error message
concerning a type cast:
ralfg@vm5:~/GNU Radio/src/gr-dvbtx-master/build$ make
[ 5%] Building CXX object
lib/CMakeFiles/gnuradio-dvbtx.dir/dvbtx_ofdm_sym_acquisition_impl.cc.o
/home/ralfg/GNU
Radio/src/gr-dvbtx-master/lib/dvbtx_ofdm_sym_acquisition_impl.cc: In
member function ‘int
gr::dvbtx::dvbtx_ofdm_sym_acquisition_impl::peak_detect_process(const
float*, int, int*, int*)’:
/home/ralfg/GNU
Radio/src/gr-dvbtx-master/lib/dvbtx_ofdm_sym_acquisition_impl.cc:54:68:
error: cannot convert ‘uint32_t* {aka unsigned int*}’ to ‘uint16_t*
{aka short unsigned int*}’ in argument passing
volk_32f_index_max_16u(&peak_index, &datain[0], datain_length);
To be able to compile the module, I have changed the type of
peak_index to uint16_t, hoping this is correct.
When I run my flow graph on a live video, I can see that the position
of the cyclic prefix changes constantly. The same happens when I take
the data from the file as input (which I think is normal, because the
signal has been sampled with the same sample rate).
However, given that the data in the file don't change, I do not
understand why two consecutive runs on the same data detect different
positions of the cyclic prefix:
1st run:
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
Cyclic Prefix position = 3963
Cyclic Prefix position = 3978
Cyclic Prefix position = 3993
Cyclic Prefix position = 4009
Cyclic Prefix position = 4026
[... deleted ...]
Cyclic Prefix position = 4597
Cyclic Prefix position overflow!
OFDM Symbol Acquisition Restarted!
Cyclic Prefix position = 3460
2nd run:
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
Cyclic Prefix position = 3963
Cyclic Prefix position = 3979
Cyclic Prefix position = 3995
Cyclic Prefix position = 4010
Cyclic Prefix position = 4025
[... deleted ...]
Cyclic Prefix position = 4595
Cyclic Prefix position overflow!
OFDM Symbol Acquisition Restarted!
Cyclic Prefix position = 3458
At the beginning of both runs the position of the cyclic prefix is
3963. This means, that in both cases the first symbol is detected at
the same position. How is it possible that the position of the
following symbols differ (e.g. 3978 vs. 3979)? All I did was stopping
and restarting the flow graph. As everything in the block is pure and
well defined mathematics, when the conditions (data, parameters) do
not change, to my understanding the result should always be the same.
I may be wrong, but in this case I would like to understand why. Do
you have an explanation for me?
Thank you very much for your help.
Kind regards,
Ralf, DL5EU
Am 02.03.2020 um 13:42 schrieb Ron Economos:
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
