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 > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
