Re: Interpolating FIR Filter - sample delay

[Daniel Estévez]

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.

OpenPGP_signature
Description: OpenPGP digital signature