discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] HELP! - Problem with radio application deploy


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] HELP! - Problem with radio application deploy
Date: Tue, 19 Nov 2013 20:37:50 -0500

On Tue, Nov 19, 2013 at 7:58 PM, Marcus D. Leech <address@hidden> 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 <address@hidden> 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
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



reply via email to

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