discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DVB-T receiver problem (OFDM symbol acquisition)


From: CEL
Subject: Re: DVB-T receiver problem (OFDM symbol acquisition)
Date: Mon, 2 Mar 2020 17:22:01 +0000

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 (<address@hidden>) 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" <address@hidden>
> > > An: address@hidden
> > > 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]