discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Resampling rate method assistance


From: CEL
Subject: Re: [Discuss-gnuradio] Resampling rate method assistance
Date: Tue, 29 May 2018 09:34:12 +0000

Hi Carlo, hi Linda:

as Linda said,the RR approach works really well and is numerically
relatively stable until you hit really ugly ratios (after, of course,
cancelling the fraction as far as possible).
But what is "ugly" here? 

In theory, rational resampling by M/N (note: M,N coprime!) would work
like the following

input --> insert (M-1) zeros between each sample
      --> low-pass 1/M-band filter to get rid of the images
      --> low-pass 1/N-band filter to avoid aliasing in next step
      --> throw away (N-1) of N samples --> output

Now, either of the 1/M and the 1/N-band filter doesn't do anything
useful, simply because the other is narrower.

So, we reduce that to 

input --> insert (M-1) zeros between each sample
      --> low-pass 1/max(M,N)-band filter against images and aliases
      --> throw away (N-1) of N samples --> output

and pay a bit of attention to the transition width of the filter (which
will become smaller the closer the ratio M/N becomes to 1).

This is all fine and dandy, but let's say max(M,N) is N=25.
A quick calculation[1] shows that this filter might have 220 taps,
which we need to apply to 12× the input sample rate, so that's 12·220,
that is ca 2600, multiply-accumulate operations per input sample –
ooof.

We avoid that by having an elegant polyphase implementation, which by
the
power of greyskull (or was it harris?) allows us to run this core
filter
at 1/N of the input rate (instead of M times the input rate!); so, we
get
220 / 25 = 9 multiply-accumulates per input sample - which is very
bearable, and thus, the rational resampler works very well in this
scenario.

With M,N coprime, we basically get two good cases:

1. N >> M (rational decimation): The core filter runs at a very low
rate of 
   1/N of the input rate, its length being proportional to M·N.
2. M >> N (rational interpolation): The core filter runs at a still low
1/M
   of the output rate, its length being proportional to M.

So, the efforts of an M/N and an N/M filter are very manageable,
because
either the filter isn't that long (no M factor in the length) or the
filter 
runs at a very low rate (1/N of the input).

A problem only occurs if M and N are relatively close to each other:

In that case, the transition width of the core filter becomes very
small, and
the inverse of transition width goes linearly into the necessary length
of a 
FIR filter; at the meantime, the polyphase saving don't balance that
out.
To make matters worse, a some point, having a polyphase decomposed
large filter
becomes a problem for your CPU: while a modern CPU can happily keep a
couple
hundred filter coefficients and the same amount of in- and of output
samples in
L2 (or even L1) cache, you can quickly get into trouble if the filter
becomes
so large that you regularly have to flush your cache; then you quickly
become
RAM bandwidth bound and performance plummets. Don't expect that to
happen before
ratios like 1023/1024 or so on your x86.

In these cases, just like in the finely adjustable ratio cases, an
arbitrary 
ratio resampler becomes the method of choice – but even then, you'd
often try to
get "as close as feasible" to the target rate with a rational
resampler, and then
only do the remainder that's really close to 1 with an arbitrary
resampler.

Best regards,
Marcus

[1] https://dsp.stackexchange.com/questions/31066/how-many-taps-does-an
-fir-filter-need#31077
    with δ_1 = 10^-2, δ_2 = 10^-6, and the transition width half an
alias distance, 
    i.e. f_s/50
On Tue, 2018-05-29 at 14:37 +1000, Carlo Manfredini wrote:
> Thanks, that works well.
> I'm pleased to be able to use the RR, and am using the default taps.
> 
> 
> On 29 May 2018 at 10:07, Linda20071 <address@hidden> wrote:
> > Use the rational resampler module (12/25). Decimation 25; interpolation: 12
> > 
> > On Mon, May 28, 2018 at 7:44 PM, Carlo Manfredini <address@hidden> wrote:
> > > Hi,
> > > I wish to transfer continuous data between two devices operating at these 
> > > two rates: 
> > > 100kSps and 48kSps
> > > I would appreciate some suggestions as to the "best " method or resampler 
> > > to use.
> > > I imaging the RR is not useful here.
> > > Im thinking some fractional resampler is best.
> > > Since these rates are quite low I imagine processing load is not an issue.
> > > 
> > > Also, how does one select the filter taps required ? Are there some 
> > > tutorials or "rules of thumb" I can follow ?
> > > 
> > > Thanks for hints.
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

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