[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Filter in rational resampler

From: Jeff Long
Subject: Re: [Discuss-gnuradio] Filter in rational resampler
Date: Tue, 28 Oct 2014 07:58:52 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 10/28/2014 07:47 AM, Andy Walls wrote:

Jeff Long
Re: [Discuss-gnuradio] Filter in
rational resampler
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

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


I was studying the code of the rational resampler block in
gnuradio/gr-filter/pythoin/rational_resampler.py and I have a
about the low pass filter generated by the design_filter()

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

Can someone point me to a relevant explanation?

Thanks a lot. Cheers,


I just had occasion to use the rational resampler for a 25 Ksps ->
Ksps resampling and low-pass filtering all in one step, with a LPF
cut off frequencies higher than 3000 Hz.  I started by using this
_expression_ for the taps, following the filter design in

         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
~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


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

Section 12.6 on page 691 of this book has a nice explanation:

I'll submit a bug to the issue tracker.


I already put a bug report in last night. Fix default filter, plus maybe documentation of what user taps really means.

- Jeff

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

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


      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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]