[Top][All Lists]

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

Re: [Discuss-gnuradio] IIR Filter taps

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] IIR Filter taps
Date: Mon, 19 Nov 2012 10:20:45 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

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
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I'm thinking that changing the way the current taps work in Gnu Radio
would be a disruptive change.

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.

Principal Investigator
Shirleys Bay Radio Astronomy Consortium

reply via email to

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