Hi Guys,
If I use interp_fir_filter_ccc(3, [1, 2, 3, 4, 5, 6]) on a vector
source containing [1, 0, 0, …] then I get [1, 2, 3, 4, 5, 6, 0, 0,
…] as expected. However, if I use interp_fir_filter_ccc(3, [1, 2, 3,
4, 5]) then I get [0, 1, 2, 3, 4, 5, 0, 0, …] so the samples are
shifted to the right by one. For taps of length divisible by 3 there
is no delay, and for others there is 1 or 2 sample delay introduced by
the interpolation filter. Why is this?
Also, maybe related to this, I see filter.declare_sample_delay(0) in
generated code, and I do not know what it does and if it is strictly
necessary.
Miklos
On Sun, Jan 5, 2014 at 4:39 PM, Miklos M. [email protected]
wrote:
Hi Guys,
If I use interp_fir_filter_ccc(3, [1, 2, 3, 4, 5, 6]) on a vector
source containing [1, 0, 0, …] then I get [1, 2, 3, 4, 5, 6, 0, 0,
…] as expected. However, if I use interp_fir_filter_ccc(3, [1, 2, 3,
4, 5]) then I get [0, 1, 2, 3, 4, 5, 0, 0, …] so the samples are
shifted to the right by one. For taps of length divisible by 3 there
is no delay, and for others there is 1 or 2 sample delay introduced by
the interpolation filter. Why is this?
Good catch, Miklos. I’ve identified the problem. I’ve put it into a
queue of patches that will be pushed soon.
Also, maybe related to this, I see filter.declare_sample_delay(0) in
generated code, and I do not know what it does and if it is strictly
necessary.
Miklos
No, that has nothing to do with it. That is a very specialized
function to instruct the scheduler how to handle tags when passing
through blocks with delay. The documentation of that function tells
you that it doesn’t do anything with the signal processing of the
block:
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#acad5d6e62ea885cb77d19f72451581c2
Tom