Re: Interpolating FIR Filter - sample delay

[Marcin Puchlik]

Hi Daniel,

Thank you for your detailed response. Indeed, that's what I do now is to set the Sample Delay equal to: filter group delay divided by an interpolation factor. One thing I don't understand in your response is: "However, I don't think this is a very good solution, because it forces

the output delay to be a multiple of the interpolation factor. Typically
we'd like to set the output delay to the FIR group delay, which is
(len(taps)-1)/2. This need not be a multiple of the interpolation factor."

But that is the current situation, to compensate for the improper delay introduced by the FIR filter you have to divide the Sample Delay by the interpolation factor - that's how it looks right now. 

Your proposal is correct IMO, and works but current behavior of the block is misleading and at least should be noted in the documentation or wiki. 

Cheers,

Marcin

niedz., 24 kwi 2022 o 10:45 Daniel Estévez <daniel@destevez.net> napisał(a):

El 22/4/22 a las 11:32, Marcin Puchlik via GNU Radio, the Free &
Open-Source Toolkit for Software Radio escribió:
> Hello
> I was playing with the Interpolating FIR Filter Block and noticed that
> the mentioned filter delays tags not properly. What I mean is that when
> the interpolation factor is different than 1, then the filter delays the
> tags by the /Sample Delay * Interpolation factor/ value. In my opinion
> this is not correct behavior. Group delay of the filter is constant and
> the interpolation factor shouldn't affect the process of delaying the
> tags. Below, I am attaching the plot and GRC flowgraph which demonstrate
> the problem and where you can see the observed behavior.
> Number of the taps in RRC filter used in the simulation: 41
> Group delay: 20
> Actual group delay: 40
> What do you think?

Hi Marcin,

I've done a small flowgraph to test this and agree with what you've
found. Looking at how this is handled in code, I see that the sample
delay in the GRC block is used to call the declare_sample_delay() method
of the block.

https://github.com/gnuradio/gnuradio/blob/main/gr-filter/grc/filter_interp_fir_filter_xxx.block.yml#L46

This sets the delay referred to the input:

https://github.com/gnuradio/gnuradio/blob/main/gnuradio-runtime/lib/block.cc#L68

Basically, delays for tags seem to be considered at the input always:

https://github.com/gnuradio/gnuradio/blob/main/gnuradio-runtime/lib/buffer_reader.cc#L138

So I can see why for an interpolator block you would get sample_delay *
interpolation_factor at the output.

A way to fix this would be to modify the GRC block to call

self.${id}.declare_sample_delay(${samp_delay}//${interp})

However, I don't think this is a very good solution, because it forces
the output delay to be a multiple of the interpolation factor. Typically
we'd like to set the output delay to the FIR group delay, which is
(len(taps)-1)/2. This need not be a multiple of the interpolation factor.

I think that the proper solution would let us set the output delay with
a granularity of one output sample. It seems this would require more
work. I'm not sure whether the tag propagation schemes already support this.

Best,
Daniel.