Re: [Discuss-gnuradio] filters

[Eric Blossom]

On Tue, Jan 29, 2002 at 12:27:36AM -0800, Matthew Ettus wrote:
> Since I needed it to do de-emphasis in hifi_fm, I'm working on rewriting
> the IIR filter template that's currently in the needs-work directory.  
> 
> I'd like to have a generic template in which the constructor takes a
> list of taps.  Then I'd like to have derived class templates like
> Butterworth, Bessel, etc. which basically override the ??constructor??
> and set up taps how they like.  However, there is also work which needs
> to be done in the constructors which is common to all the types.  Is
> this best done by overriding the constructors, or should I be using the
> initialize methods? Or something else?

Generally speaking, I think that we should separate the creation /
design of the filters from the actual code that executes them.  We
should come up with a type that describes the coeffs and then
(somehow) get them to the actual filter.  For a FIR, I'm leaning
towards vector<float> or vector<VrComplex> or vector<complex<float>>
etc.   For IIRs, perhaps vector<biquad_section<float>> or something
similar. 

One thing that we need to deal with is that the sampling rate is not
known in the constructor.  Hence, I don't think the constructor is the
place to pass the taps.  It may however make sense to pass a callback
and data (I *really* miss first class functions) that will be invoked
whenever the sample rate is determined and/or is changed and have it
return the coeffs.  I suspect that the callback should get the user
provided data and the sample rate as args.

Splitting the design from the evaluation of the filter should keep
things quite simple.  We can create as many different ways to design
filters as we like, and none of the underlying code should care.

> Eric -- is this how you're doing FIR filters?  

Not complete, but that's my plan.

On the general channel selection filter (son of VrComplexFIRfilter), 
I plan to have the callback build the prototype low pass, then tranform
it depending on the channel center frequency.  This will allow us to
"tune" on the fly.

> Have you gotten that SPUC code integrated?

Nope.  If you need it now, I'll get to it.

> Matt

I'm working on the RS stuff, and got a nice answer back from Phil Karn
on how to handle the (207,187) codec.  With the given API, I need to
prefix the message with 48 zeros.  This converts the (207+48,187+48)
into (255,235) which his code directly handles.  With an API change,
we could save a few cycles, since the 48 zeros could be skipped.

Eric