Re: [Discuss-gnuradio] Resampling rate method assistance

[CEL]

I'd assume this might not be a computational issue, but more of a
hardware or hardware interfacing issue, or maybe something
algorithmically off. Care to save a picture of your flow graph (File-
>Screen Capture) and upload it (e.g. imgur.com)?

Thanks,
Marcus
On Wed, 2018-05-30 at 08:25 +1000, Carlo Manfredini wrote:
> Hi Marcus,
> I see. I thought you were referring to the "Polyphase Arbitrary
> Resampler"  block for a polyphase implementation.
> 
> Having that optimisation in the "Rational Resampler" is excellent,
> and thank you for the detailed explanation. Very helpful.
> 
> I'll look further into why I was getting underflow issues as
> resampling between 100kSps and 48kSps using 12/25 ratios should be no
> problem for my i7 based PC.
> ( I assume that what I was getting: aUaUaU...being printed onscreen
> in GRC..and some breaks in the continuous signal)
> 
> Regards.
> 
> On 29 May 2018 at 23:19, Müller, Marcus (CEL) <address@hidden>
> wrote:
> > 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 <carloman
> > 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
> > > 
> > >
> 
>

smime.p7s
Description: S/MIME cryptographic signature