Filter taps and delays

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs