Re: USRP B210 overflow and underflow

On 03/01/2023 17:31, Karen young wrote:

  Hi Marcus,

Great! I removed the high pass filter for comparison, do see much less underflow and overflow errors.

May I ask how do the over 1000 taps come from? I do not understand how you get this number.

If I have to use a high pass filter, how to reduce its effect on slowing down the operation speed?

Thanks

Karen

If you use the "High Pass filter taps" object, and hand it the same parameters you used, then do a len(x) on
  that object, it comes back at 1250.

The length of a FIR filter is proportional to the ratio between the sample-rate and the transition width. Gnu Radio
  uses a version of the Parks-McLellan filter-design algorithm (which is in turn a variant of Remez Exchange).
  The algorithms try to find a filter that is optimal both in length and passband parameters.  The filter length tends
  to grow considerably as this ratio gets larger.

This is basic DSP stuff, and not specific to Gnu Radio.  ANY DSP framework that uses FIR filters will have similar
  issues. 

Now what you might want to do is generate the taps with the "High Pass Filter Taps" object, and then use those taps
  as the coefficients in a generic FFT filter--the FFT filters tend to be more computationally efficient for larger numbers
  of taps, where "larger" is somewhat system specific, but I tend to use them for anything where there are more than
  about 50 or 60 taps.

On Tue, Jan 3, 2023 at 5:00 PM Marcus D. Leech <patchvonbraun@gmail.com> wrote:

On 03/01/2023 16:53, Karen young wrote:

sample_rate is 5M

what it is you're doing at those rates: I am using a USRP B210 to transmit and receive pulse signals using attached antennas. The antennas work at 430MHz. See attached fig.

and what kind of computer/OS you're using: 

One thing that struck me--your high-pass filter is very compu-spendy -- with those parameters, there's over 1000 taps.
   That's considered rather chunky.

Since it's a decimation=1 filter, it will have to perform over 1000 multiply-accumulate operations and the matching shift
  operations on every sample.

That may be what's slowing you down.