Re: [Discuss-gnuradio] Filter delays and direction of time.

[Eric Blossom]

On Thu, Jan 20, 2005 at 10:59:42PM -0500, Achilleas Anastasopoulos wrote:
> > Yes this is correct.  If you're using a non-symmetric filter, you must
> > reverse the taps before handing them to gr_fir_filter.  For common
> > cases, it doesn't matter because the taps are symmetric.
> >
> Eric,
> 
> I am not sure if tap reversal solves the problem:
> 
> suppose I want to implement a simple
> filter that performes a delay by 2 samples.
> 
> The correct coefficients are [0,0,1].
> However, gnuradio will return
> y[k]=x[k+2]
> which is not what i want.
> 
> If I reverse the coefficients, I get [1,0,0]
> which when used in gnuradio will return
> y[k]=x[k]
> which is not what we want either.

I think there's a bit of an impedance mismatch between how you are
thinking and how GNU Radio works.  GNU Radio is not an isochronous
data flow engine.  We've got lots of implicit buffering between
blocks.  You have virtually no control over the amount of buffering
that's taking place between blocks.  Thus, implementing a delay with the
filter block isn't going to get you what I think you want.  You're
probably noticed that there's no "delay" primitive.  If you've got
something with a feedback loop in it, it needs to be implemented in a
single block.  E.g., PLL's.

What are you really trying to do?  What's the problem you're trying to
solve, or the computation you're trying to make?

FYIW, in the gr_hilbert_fc.{h,cc} block we implement the hilbert filter and
the parallel delay line in the same block, thus ensuring goodness.

Eric