Re: Interpolating FIR Filter - sample delay

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.