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) <[email protected]> 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) <[email protected]> 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 <[email protected]> wrote: > > > > > Use the rational resampler module (12/25). Decimation 25; > interpolation: 12 > > > > > > > > > > On Mon, May 28, 2018 at 7:44 PM, Carlo Manfredini < > [email protected]> 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 > > > > > > [email protected] > > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > > > > > > _______________________________________________ > > > > Discuss-gnuradio mailing list > > > > [email protected] > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
