Re: USRP B210 overflow and underflow

[Marcus D. Leech]

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.