discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] GNURadio Companion LPF


From: Derek Kozel
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF
Date: Tue, 22 May 2018 11:41:25 +0100

Hello Yeo,

You've posted so many different emails it is very hard to keep up with your questions and who has answered what. Could you please keep related questions in the same email thread?

For information on underflows and overflows, here is the page of the USRP manual.
http://files.ettus.com/manual/page_general.html#general_ounotes

I recommend reading all the pages in the General Usage section to get a better understanding of how UHD and the USRPs work.
http://files.ettus.com/manual/page_devices.html

Yes, Overflows and underflows will affect your results because you will be missing data.

Derek

On Tue, May 22, 2018 at 11:01 AM, Yeo Jin Kuang Alvin (IA) <address@hidden> wrote:

Hi all,

 

What are the disadvantage of having overflows and underflows? I am working on radar projects which is in real-time, will these underflows and overflows affect my results?  Sorry I am still trying to learn all these.

 

Thank you in advanced!

 

From: Marcus D. Leech [mailto:address@hidden]
Sent: Tuesday, 22 May 2018 11:32 AM


To: Yeo Jin Kuang Alvin (IA); address@hidden
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF

 

On 05/21/2018 11:28 PM, Yeo Jin Kuang Alvin (IA) wrote:

Hi all,

 

Thank you! I’ve noticed my mistake.

 

Now I’ve tried both 5000 and 100e3, instead of overflowing “O”, I see lots of “L” late packets.

 

Thank you in advanced!

'L' is from TX side of things.  It's a special variant of 'U', where the transmission is time-tagged, and the device time is already past that point when
  the time-tagged packet arrives.



 

From: Marcus D. Leech [mailto:address@hidden]
Sent: Tuesday, 22 May 2018 11:19 AM
To: Yeo Jin Kuang Alvin (IA); address@hidden
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF

 

On 05/21/2018 11:14 PM, Yeo Jin Kuang Alvin (IA) wrote:

Hi Marcus,

 

Thank you for the quick reply!

 

Is there any block in GRC that works with the FPGA in the USRP B210? And I have tried lowering the transition width from 1000 to  ~150 but I still see overflow, does this means that the only solution to it is to get a faster computer?

There are no FPGA-for-B210 blocks in Gnu Radio.  That's not how Gnu Radio works.   RFNoC is an exception, but B210 is not an RFNoC-capable radio.

Narrowing the transition width (as a fraction of sample-rate) is precisely how you end up with really-long, hard-to-compute, filters.  Try a transition
  width of 100e3, and see how that does.  That's a roughly 2% fractional bandwidth.  Which, in the analog world, would be a pretty "tight" filter.




 

Thank you in advanced!

 

From: Discuss-gnuradio [mailto:discuss-gnuradio-bounces+yjinkuan=dso.org.sg@gnu.org] On Behalf Of Marcus D. Leech
Sent: Tuesday, 22 May 2018 11:02 AM
To: address@hidden
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF

 

On 05/21/2018 10:54 PM, Yeo Jin Kuang Alvin (IA) wrote:

Hi all,

 

Apparently, I tried connecting the USRP Source to a Low Pass Filter and to a File Sink, I get overflows “OOOOOO”. However, when I removed the LPF, there is no overflow. The question is, why is this happening? Is the Low Pass Filter in GRC done in the FPGA or in the computer itself? I am using USRP B210 and my sampling rate is 6MHz.

 

Is there a solution to this?

 

Thank you in advanced!

 

'O' are caused by the computer not "keeping up".  Gnu Radio is a software-defined-radio framework, and all the blocks execute on the PC host.

It is typically the case that new users make low-pass filters with very "aggressive" transition bandwidths, which leads to a very expensive-to-compute
  filter.  Try relaxing the transition bandwidth.




 

 


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



reply via email to

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