[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Filter in rational resampler
From: |
Andy Walls |
Subject: |
Re: [Discuss-gnuradio] Filter in rational resampler |
Date: |
Tue, 28 Oct 2014 07:47:17 -0400 |
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