|
| From: | Carlo Manfredini |
| Subject: | Re: [Discuss-gnuradio] Resampling rate method assistance |
| Date: | Wed, 30 May 2018 08:25:19 +1000 |
Hi Carlo,
if you're using GNU Radio's rational resampler, you're already using
that method!
Really, at your 100 kS/s rate... things should be trivial for your CPU,
even if they weren't implemented efficiently. I'm really not convinced
the resampling is to blame here!
Best regards,
Marcus
On Tue, 2018-05-29 at 22:03 +1000, Carlo Manfredini wrote:
> Hi Marcus,
> Thanks for that reply.
> The reduction in computation with the polyphase implementation sounds very tempting esp as I'm getting underflow errors at the moment.
> I will give it a try and see how it compares.
> Regards.
>
> On 29 May 2018 at 19:34, Müller, Marcus (CEL) <address@hidden> wrote:
> > 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
>
>
| [Prev in Thread] | Current Thread | [Next in Thread] |