Forum: GNU Radio IIR Filter taps

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

On 19/11/12 10:11 AM, Tom Rondeau wrote:
>
> GNU Radio. So we should have the program produce filter coefficients
>
> Tom
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> 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
http://www.sbrac.org

On Mon, Nov 19, 2012 at 10:20 AM, Marcus D. Leech <mleech@ripnet.com> 
wrote:
>> H(z) = \ frac{\sum_{k=0}^{M} b_k z^{-k}}{1 - \sum_{k=1}^{N} a_k z^{-k}}
>> gr_filter_design could be used by others running programs other than
>> 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
systems.

> 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

Thanks,
Tom

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

On 11/19/12 10:11 AM, Tom Rondeau wrote:

> 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 agree that changing the way gr_iir_filter takes in the taps could
be disruptive, unless backward compatibility is maintained. Some of
the group are using GnuRadio for operational systems.

Here's two more suggestions for solutions:

1.  Add an optional flag parameter to the constructor, with values
     of "Old_API" and "New_API",  with the default set to "Old_API".
     This flag would control how gr_iif_filter interprets the taps.
     It could be maintained this way for some time, with the Old_API
     being deprecated, and eventually change the default to
     New_API, or even make the default a cmake option.

2. Create two subclasses of filter taps that are identical in
    format, and use C++ overloading to determine which constructor
    or set method to use.

@(^.^)@  Ed

On Mon, Nov 19, 2012 at 9:22 AM, Ed Criscuolo
<edward.l.criscuolo@nasa.gov>wrote:


> I agree that changing the way gr_iir_filter takes in the taps could
> be disruptive, unless backward compatibility is maintained. Some of
> the group are using GnuRadio for operational systems.
>

Yes.


>    format, and use C++ overloading to determine which constructor
>    or set method to use.
>

I think the first is most straightfoward and consistent with how we've 
make
API changes in the past.

Johnathan

On Mon, Nov 19, 2012 at 1:57 PM, Johnathan Corgan
<johnathan@corganlabs.com> wrote:
>
>> 2. Create two subclasses of filter taps that are identical in
>>    format, and use C++ overloading to determine which constructor
>>    or set method to use.
>
>
> I think the first is most straightfoward and consistent with how we've make
> API changes in the past.
>
> Johnathan

Agreed. That's a pretty sane way of helping make the transition. An
argument to the constructor should make people perk up and pay
attention to the fact that there is a change.

Tom

On Mon, Nov 19, 2012 at 2:40 PM, Tom Rondeau <tom@trondeau.com> wrote:
>>
>>>     New_API, or even make the default a cmake option.
>
> Agreed. That's a pretty sane way of helping make the transition. An
> argument to the constructor should make people perk up and pay
> attention to the fact that there is a change.
>
> Tom

I just pushed a branch to my github repo called iir_filter that
implements the optional argument to the IIR filter as we discussed.
The default is oldstyle=True and doesn't change any behavior. If you
set this to False, you can directly copy taps from programs like
gr_filter_design (the new version not yet integrated into GNU Radio).

Comments, questions, etc.? If no one sees a problem with this, I'll
merge it into next.

Tom

>I just pushed a branch to my github repo called iir_filter that
>implements the optional argument to the IIR filter as we discussed.
>The default is oldstyle=True and doesn't change any behavior. If you
>set this to False, you can directly copy taps from programs like
>gr_filter_design (the new version not yet integrated into GNU Radio).
>
>Comments, questions, etc.? If no one sees a problem with this, I'll
>merge it into next.

Tried a few IIR filters using iir_filter branch with taps copied from 
gr_filter_design (in GRC). Works fine! :).

-Sreeraj

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

On Thu, Nov 22, 2012 at 3:34 AM, Martin Braun (CEL)
<martin.braun@kit.edu> wrote:
>
> I didn't actually build and test it, but I do like this solution and it
> seems correct. A very, very minor suggestion is to apply the attached
> patch, it's probably a bit OCD, but it changes the formulas in the
> doxygen block to reflect the change, as well.
>
> MB

That's great, Martin, thanks!

Tom