On Tue, Nov 19, 2013 at 7:58 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > How do you determine the size of taps? How much of a difference does setting > the transition width from 1MHz to 10MHz make? > > Generally, the wider the transition width, the fewer taps. > > You can use the "firdes" functions, which is what the low-pass filter blocks > call in gnuradio, then take their output into a variable and > have another variable be len(filter).
Right. And the firdes functions use the windowing technique to build filters. The way these work, in fact, is that a 10x increase in the transition width produces a 10x decrease in the number of taps. So for a 50 Msps sampling rate with 1 MHz transition width, we get 137 taps. For 10 MHz, we have 13 taps (floor(137/10)). This is true as long as we're keeping the stop-band attenuation the same. There are _2 versions of each filter that allow us to set that attenuation value (in dB). The approximate relationship is: ntaps ~= atten / (22 * tb/fs) (tb: transition bandwidth; fs: sample rate) (Also, I once knew the derivation this relationship but can't remember it now.) Tom > On Tue, Nov 19, 2013 at 6:40 PM, Marcus D. Leech <mle...@ripnet.com> wrote: >>> >>> I really appreciate the detailed explanation. I tried running >>> gr_filter_design last night and it asked me to install SciPy, which I did >>> not feel like doing at that time. I will try using 1MHz for my band, which >>> may help get rid of the real-time running issue. >>> >>> Again, I appreciate your help with this matter. >> >> Let's say you get a filter that's, oh, I dunno, 100 taps long. That >> filter has to process every sample, so, that's 5e7 X 100 taps, or >> roughly 5e9 FLOP/second. Just for that one filter. And your flow-graph >> is likely doing other things *and* it's having to get samples >> all the way through your network or USB stacks into the application >> layer as well, call that 100 instructions/sample. So, that's >> 5e7 x 100 = 5e9 OPS/second just to get your samples into the >> application. You're going to burn-up the cycles on your CPU pretty >> quickly at 50Msps, even for doing "trivial" things. >> >> >> >> >> >> -- >> Marcus Leech >> Principal Investigator >> Shirleys Bay Radio Astronomy Consortium >> http://www.sbrac.org >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
