Re: Interpolating FIR Filter - sample delay

Hi Marcin,

What I mean is that currently we need to entering

group_delay // interpolation_factor

in the Sample Delay field. And that number needs to be an integer. So
unless group_delay is divisible by interpolation_factor we won't get
exactly the correct delay in the output (just consider what happens if
we increase group_delay by 1 because we added 2 taps to the filter).

Best,
Daniel.

El 25/4/22 a las 10:35, Marcin Puchlik escribió:
> 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
> <mailto: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
> <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
> <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
> <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.
>