[Top][All Lists]

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

Re: [Discuss-gnuradio] IIR Filter taps

From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] IIR Filter taps
Date: Mon, 19 Nov 2012 10:27:54 -0500

On Mon, Nov 19, 2012 at 10:20 AM, Marcus D. Leech <address@hidden> wrote:
> On 19/11/12 10:11 AM, Tom Rondeau wrote:
>> Hi all,
>> So we're working towards integrating the new gr_filter_design tool
>> that Sreeraj built this summer for our GSoC project. One issue has
>> come up with it is the specification of the IIR filter taps and how
>> they are used in GNU Radio. To summarize the conversation between
>> Sreeraj and myself:
>> GNU Radio's expected transfer function:
>> H(z) = \ frac{\sum_{k=0}^{M} b_k z^{-k}}{1 - \sum_{k=1}^{N} a_k z^{-k}}
>> But gr_filter_design gives the denominator (a_k) in the form:
>> {1 + \sum_{k=1}^{N} a_k z^{-k}}
>> So when taking from gr_filter_design, we need to invert the sign of
>> all taps except the first one.
>> I feel like we should be able to just copy and paste the a and b
>> vectors from gr_filter_design straight into a GNU Radio program
>> (Python or GRC) and have it run. Also, though, I think
>> gr_filter_design could be used by others running programs other than
>> GNU Radio. So we should have the program produce filter coefficients
>> useful to them, too.
>> >From my background, the way gr_filter_design works currently is the
>> 'right' way and our gr_iif_filter uses the 'wrong' representation. But
>> I want to hear other people's opinions on this. What's the standard
>> convention for other IIR filtering tools/programs that people have
>> used? Should be change the way gr_iif_filter takes in the taps, or
>> should we change how gr_filter_design produces them?
>> Thanks for the feedback!
>> Tom
> I'm thinking that changing the way the current taps work in Gnu Radio
> would be a disruptive change.

Yes, that's my main concern. We'd do this on the next branch so it
would be a change in version 3.7. Still, it's a subtle change that if
people weren't paying close attention to it, we could impact a lot of

> I can think of two ways around this:
> Provide alternate forms of the IIR functions that just translate the taps.
> Provide a helper function, possibly in firdes? That re-expresses the
> taps, and you can then pass that into
>   the existing GR IIR filter functions.

Sure, one of those might work. Hopefully we'll get more comments in
about this to figure out the best answer.

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


reply via email to

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