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

On Thu, Jun 26, 2014 at 3:52 PM, Andy Walls <andy@silverblocksystems.net> wrote:

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).

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