On Oct 27, 2014 6:36 PM, "Jeff Long" <willco...@gmail.com> wrote: > > On 10/27/2014 04:40 PM, Andy Walls wrote: >> >> On Thu, 2014-07-31 at 12:01 -0400, discuss-gnuradio-requ...@gnu.org >> wrote: >> >>> Message: 5 >>> Date: Wed, 30 Jul 2014 18:42:14 +0200 >>> From: Daniele Nicolodi <dani...@grinta.net> >>> To: GNURadio <discuss-gnuradio@gnu.org> >>> 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). 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. The filter is applied after interp and before decim, which is not obvious from the API.
- Jeff
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
