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
