Ron, Let me know if I can be of any help. I've been wanting to port the whole project and integrate it to GNU Radio for a some years by now, but I just can't find the time. Maybe it would make a GSoC project? Or it's too late by now? best Federico
El lun., 2 mar. 2020 a las 10:56, Ron Economos (<w...@comcast.net>) escribió: > 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> <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 > >
