[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: |
Mon, 27 Oct 2014 16:40:21 -0400 |
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
- Re: [Discuss-gnuradio] Filter in rational resampler,
Andy Walls <=