Re: [Discuss-gnuradio] Filter in rational resampler

[Andy Walls]

From: 
Jeff Long
Subject: 
Re: [Discuss-gnuradio] Filter in
rational resampler
Date: 
Tue, 28 Oct 2014 04:31:30 -0400

> On Oct 27, 2014 6:36 PM, "Jeff Long" <address@hidden> wrote:
> >
> > On 10/27/2014 04:40 PM, Andy Walls wrote:
> >>
> >> On Thu, 2014-07-31 at 12:01 -0400, address@hidden
> >> wrote:
> >>
> >>> Message: 5
> >>> Date: Wed, 30 Jul 2014 18:42:14 +0200
> >>> From: Daniele Nicolodi <address@hidden>
> >>> To: GNURadio <address@hidden>
> >>> Subject: [Discuss-gnuradio] Filter in rational resampler
> >>>
> >>> Hello,
> >>>
> >>> I was studying the code of the rational resampler block in
> >>> gnuradio/gr-filter/pythoin/rational_resampler.py and I have a
> doubt
> >>> about the low pass filter generated by the design_filter()
> function.
> >>>
> >>> It seems that the generated filter does not take into account the
> >>> decimation factor. Is that correct? I don't see how this may
> result in
> >>> the correct anti-aliasing filter when it is applied by
> >>> rational_resampler_base_xxx.
> >>>
> >>> Can someone point me to a relevant explanation?
> >>>
> >>> Thanks a lot. Cheers,
> >>> Daniele
> >>
> >>
> >> Daniele,
> >>
> >> I just had occasion to use the rational resampler for a 25 Ksps ->
> 16
> >> Ksps resampling and low-pass filtering all in one step, with a LPF
> that
> >> cut off frequencies higher than 3000 Hz.  I started by using this
> >> _expression_ for the taps, following the filter design in
> >> gr-filter/python/rational_resampler.py:
> >>
> >>         filter.firdes.low_pass(16.0, 16000.0, 3250.0/16.0,
> 500.0/16.0, filter.firdes.WIN_KAISER, 5.0)
> >>
> >> That filter only includes the interpolation factor, 16.0, and
> seemed to
> >> do the wrong thing.  The FFT scope showed the rolloff started at
> around
> >> ~4700 Hz, about 25/16 * 3000 Hz.
> >>
> >> This _expression_ for the taps, which included the decimation
> factor of
> >> 25.0, appeared to do the right thing:
> >>
> >>         filter.firdes.low_pass(16.0, 16000.0, 3250.0/25.0,
> 500.0/25.0, filter.firdes.WIN_KAISER, 5.0)
> >>
> >>
> >> Can someone else take a closer look at
> >> gr-filter/python/rational_resampler.py and confirm it is doing the
> wrong
> >> thing?
> >>
> >> Regards,
> >> Andy
> >
> >
> > It looks like the default filter is only valid where interp > decim,
> and it's not really meant to have an arbitrary cutoff. As Daniele
> pointed out, decim is not taken into account.
> >
> > I think that 'interpolation' in design_filter() should be replaced
> with 'max(interpolation,decimation).

Right, or something similar.  Basically design_filter() should design
the narrower of the required anti-image postfilter or anti-alias
prefilter.

Section 12.6 on page 691 of this book has a nice explanation:
http://www.ece.rutgers.edu/~orfanidi/intro2sp/
http://www.ece.rutgers.edu/~orfanidi/intro2sp/orfanidis-i2sp.pdf

I'll submit a bug to the issue tracker.

>  If taps are supplied by the caller, it needs to understand how the
> taps will be used.
> >
> > Andy, to mimic design_filter, you'd need to do:
> >
> >   low_pass(16.0, 25000.0, 3250.0, 500.0, ...)
> >
> > Not that I know if that's right, but that's what design_filter()
> does.
> >
> Andy, ignore that last part. Your params are right and that filter
> actually makes sense.

Yeah.  I experimentally knew what I had was right.  I just needed to go
back and confirm it, by reading my Orfanidis book to refresh my memory
on what I learned over 17 years ago. :P

FWIW, after the upsampling, for my specific case, the Fs of the filter
is 16 * 25000 sps.  So to get my desired 3000 Hz cutoff, which is
narrower than both the required anti-image and anti-alias filter
cutoffs, I should have used:

     low_pass(16.0, 16.0*25000.0, 3250.0, 500.0, ...)

but 

     low_pass(16.0, 16000.0, 3250.0/25.0, 500.0/25.0, ...)

is equivalent.

>  The filter is applied after interp and before decim, which is not
> obvious from the API.
> 
> - Jeff

Thanks for looking at this!

Regards,
Andy