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: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF
Date: Mon, 21 May 2018 23:18:41 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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:address@hidden] 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.




reply via email to

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