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