discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] IIR Filter taps


From: Martin Braun (CEL)
Subject: Re: [Discuss-gnuradio] IIR Filter taps
Date: Mon, 19 Nov 2012 17:31:14 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Nov 19, 2012 at 10:20:45AM -0500, Marcus D. Leech wrote:
> > 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}}
> >
> > [...]
> >
> > 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?

1 vote for the gr_filter_design style from myself.
Matlab also uses the '+' format, which means a lot of people will
probably be more used to this.

> I'm thinking that changing the way the current taps work in Gnu Radio
> would be a disruptive change.

Would it really? We're currently smashing the GNU Radio API anyway.
So perhaps this would just be another small change among others.
Everyone will need to go from gr.iir to filter.iir, anyway.
Besides, I doubt the IIR filter gets used *that* often (leaving aside
the single pole IIR, of course).

If more people are used to the '+' format than otherwise, changing this
might help more people than it would cause disruption. If someone has
some really sensitive program running using gr_iir, he or she will most
likely keep a stable but old version of GNU Radio around, anyway.

> 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.

Adding something like this into firdes is definitely harmless, so that's
a good idea. Having multiple forms for the IIR functions might be
harmful, though, as it's a source of confusion (and we mailing list
subscribers all know what that means...).

MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstra├če 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-W├╝rttemberg and
National Laboratory of the Helmholtz Association

Attachment: pgpPiZ5v1FizC.pgp
Description: PGP signature


reply via email to

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