On Thu, Jun 26, 2014 at 3:52 PM, Andy Walls <[email protected]> wrote:
> On Wed, 2014-06-25 at 10:09 -0400, Tom Rondeau wrote: > > On Tue, Jun 24, 2014 at 2:15 PM, Andy Walls > > <[email protected]> wrote: > > Hi, > > > > I have a Polyphase Arbitrary Resampler block in a flow graph and > I want > > to set the "Sample Delay" parameter so GnuRadio delays tags > properly. > > > > With the following parameters: > > > > Input Sample Rate: Fs > > Resampling Rate: r = output_rate / Fs > > Number of Filters: N > > Taps: taps=firdes.low_pass_2(N, N*Fs, ..., ..., > ...,) > > > > The best I can figure is to set: > > > > Sample Delay: int(round((math.ceil(len(taps)/N) - > 1.0)/2.0)) > > > > because GnuRadio applies this "Sample Delay" as offset to the > tags > > before scaling the tag offsets by the resampling rate r. > > > > Can anyone confirm this is correct, or is there something I'm > missing? > > > > Thank you. > > > > Regards, > > Andy > > > > > > Andy, > > > > > > Take a look at pfb_arb_resampler.cc. In the constructor, it calculates > > the sample delay. It's close to what you're thinking, but scaled for > > the polyphase filterbank partitioning. > > > > Hi Tom, > > Thanks for the response. > > Yes, I did look at the pfb_arb_resampler.cc for my starting point. :) > The 'N' above takes into account the scaling for the polyphase banks > (N=32 filters in my specific case). > Oops, overlooked that. > I verified by inspection that > gnuradio/gnuradio-runtime/lib/block_executor.cc:propagate_tags() does > take care of the multiplication by rrate (my 'r' above), so that should > not be in the sample delay expression. > Yep. > I built a test flowgraph to check my equation, using an input sawtooth > and peak detectors and burst taggers on each side of the > pfb_arb_resampler block. (See attached PNG.) The tags lined up to within > 4 samples on the output side, and given that I didn't heavily tune the > peak detector configuration, I think I'm good. :) > > Regards, > Andy > Great! Yes, getting exact peak detection is always hard. Glad things are working as well as they are, though. Tom
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
