Re: [Discuss-gnuradio] Filter in rational resampler

[Jeff Long]

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). 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