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
