IIR Filter taps

GNU Radio
1

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

2

On 19/11/12 10:11 AM, Tom R. wrote:

GNU Radio. So we should have the program produce filter coefficients

Tom

Discuss-gnuradio mailing list
removed_email_address@domain.invalid
Discuss-gnuradio Info Page

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

3

On Mon, Nov 19, 2012 at 10:20 AM, Marcus D. Leech removed_email_address@domain.invalid
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

4

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

5

On 11/19/12 10:11 AM, Tom R. 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

6

On Mon, Nov 19, 2012 at 9:22 AM, Ed Criscuolo
removed_email_address@domain.invalidwrote:

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

7

On Mon, Nov 19, 2012 at 1:57 PM, Johnathan C.
removed_email_address@domain.invalid wrote:

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

8

On Mon, Nov 19, 2012 at 2:40 PM, Tom R. removed_email_address@domain.invalid 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

9

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

10

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

11

On Thu, Nov 22, 2012 at 3:34 AM, Martin B. (CEL)
removed_email_address@domain.invalid 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