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) <muel...@kit.edu> > 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) <muel...@kit.edu> > > 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 <linda20...@gmail.com> > > wrote: > > > > > > Use the rational resampler module (12/25). Decimation 25; > > interpolation: 12 > > > > > > > > > > > > On Mon, May 28, 2018 at 7:44 PM, Carlo Manfredini <carloman > > fredin...@gmail.com> 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 > > > > > > > Discuss-gnuradio@gnu.org > > > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Discuss-gnuradio mailing list > > > > > Discuss-gnuradio@gnu.org > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio