Re: [Discuss-gnuradio] Proper setting for sample delay for polyphase arbitrary resampler?

On Wed, 2014-06-25 at 10:09 -0400, Tom Rondeau wrote:
> On Tue, Jun 24, 2014 at 2:15 PM, Andy Walls
> <andy@silverblocksystems.net> 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).

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.

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