discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Combining filters


From: Brian Padalino
Subject: Re: [Discuss-gnuradio] Combining filters
Date: Sun, 15 Aug 2010 00:46:24 -0400

On Sat, Aug 14, 2010 at 8:18 PM, Marcus D. Leech <address@hidden> wrote:
> On 08/14/2010 08:08 PM, Brian Padalino wrote:
>> On Sat, Aug 14, 2010 at 7:59 PM, Marcus D. Leech <address@hidden> wrote:
>>
>>> I have an application that's running on some fairly "spartan" hardware,
>>> so I'm trying to find ways to make the
>>>  flow-graph more computationally efficient, so that I have more
>>> headroom for inevitable feature creep.
>>>
>>> Part of my flow-graph has a FIR bandpass filter, which is followed
>>> immediately by an FFT filter.  The FIR bandpass is simply
>>>  to define my passband of interest (I bring in 1MHz, but only need/want
>>> 700KHz in the middle), and the FFT filter is designed
>>>  to allow me to dynamically notch-out narrowband interferers.   Is
>>> there an efficient way to combine these two into a single
>>>  filter, that will be more computationally efficient than two filters
>>> in series?
>>>
>> You should be able to convolve the time domain taps of both filters to
>> achieve the cascaded performance of the two filters in series.
>>
> Oh, I knew somebody would say "just convolve 'em", but that yields a
> filter that's
>  computationally the some order as the two in series, give or take.  Sigh.

Glad I could be that somebody.

>> I am not sure this would really yield any better computational
>> results, but it's the easiest thing that comes to mind.  Switching to
>> fixed point for your filtering may be the best bang-for-your-buck as
>> long as you don't need a massive amount of dynamic range.
>>
>>
> My impression is that floating-point performance these days, on *86
> hardware,
>  is generally better than integer, particular with the SIMD floating-point
>  instructions.  The particular platform is Atom based, a D510, which is
>  a dual-core CPU running at about 1.7GHz.  The current app is taking up
>  about 65% of the combined CPU, and I just want to get a little more
> headroom.

If you take that approach, you'd get better performance for the longer
SIMD instructions since you wouldn't be fetching as many instructions
using the convolved filters, right?  The number of operations ends up
being the same, but how quickly and how concise you can tell the
processor to do the operation is what you're fighting now it seems.

It's a shame it's a D510 and doesn't support DPPS or DPPD dot product
instruction as described here:

    http://en.wikipedia.org/wiki/SSE4#SSE4.1

Either way, you may be able to pack twice as many samples if you use
16-bit samples instead of 32-bit floats:

    http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

But that ends up as a reduction in dynamic range, which I'm not sure
you can deal with.

>> I'd be interested to hear what solution you come up with.
>>
>>
> Me too :-)
>
> Actually, something I'd thought of would be to treat the "edges" as
> multiple contiguous
>  notches, and run that in the FFT filter only, and eliminate the FIR
> bandpass filter.  But I'm not sure
>  I'll get really good stop-band attenuation that way.

Not knowing your bandpass FIR filter, but guessing equiripple - you
could complex mix your center to baseband and do a real low-pass
filter which should be a lower order than an equivalent bandpass
equiripple - but I am making a lot of assumptions about your filters,
your data/dynamic range requirements and all sorts of other crucial
bits.

>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>

In the end, I'm no microarchitecture expert - especially when it comes to x86.

Good luck.

Brian



reply via email to

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