Re: USRP B210 overflow and underflow
Thanks a lot for so much help. Best regards Karen On Tue, Jan 3, 2023 at 5:37 PM Marcus D. Leech wrote: > 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. > > >> >
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 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: image.png 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.
Re: USRP B210 overflow and underflow
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: image.png 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.
Re: USRP B210 overflow and underflow
On 29/12/2022 10:56, Karen young wrote: Hi, I am using a USRP B210 to transmit and receive pulse signals using attached antennas, and try to measure the phase delay between the transmitted and received signals. I do not understand why the following problems are happening. What can I do to fix them? Attached is the model. 1. The usrp_source overflow and usrp_sink underflow errors occur frequently, the received signal (in Red) is jumping accordingly as shown in Fig 1. 2. Since the transmitted signal is positive pulse, I am expecting the received signal is also positive. While the received signals are: sometimes positive peak, sometimes negative peaks as shown in Fig 2. Thanks Karen Overruns and Underruns are caused by your computer being unable to "keep up" with the sample streaming requirements of the hardware. You might add: num_recv_frames=256 num_send_frames=256 To your device arguments, which can help "ride through" short-term performance insufficiency.
