Never too late, just put it on the Ideas List wiki page On Mon, 2020-03-02 at 10:38 -0300, Federico 'Larroca' La Rocca wrote: > 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> > > > 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
smime.p7s
Description: S/MIME cryptographic signature
