Proper setting for sample delay for polyphase arbitrary resampler?

GNU Radio
1

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

2

On Tue, Jun 24, 2014 at 2:15 PM, Andy W.
[email protected]
wrote:

Taps: taps=firdes.low_pass_2(N, N*Fs, …, …, …,)
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.

Tom

3

On Wed, 2014-06-25 at 10:09 -0400, Tom R. wrote:

       Resampling Rate:   r = output_rate / Fs
    Can anyone confirm this is correct, or is there something I'm missing?

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. :slight_smile:
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. :slight_smile:

Regards,
Andy

4

On Thu, Jun 26, 2014 at 3:52 PM, Andy W.
[email protected]
wrote:

    With the following parameters:

1.0)/2.0))

    Regards,

Hi Tom,

Thanks for the response.

Yes, I did look at the pfb_arb_resampler.cc for my starting point. :slight_smile:
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. :slight_smile:

Regards,
Andy

Great! Yes, getting exact peak detection is always hard. Glad things are
working as well as they are, though.

Tom