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

[Andy Walls]

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

delay_test.grc.png
Description: PNG image