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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
