Johnathan Corgan wrote: > It does mean that I can't do a generic "adaptive_fir" class that can be > subclassed and specialized into classes like cma_equalizer, > noise_reduction, etc. Instead each one will end up being unique. I > guess that's the price you pay for speed.
Well, I've gone back to the original idea of a base class for an adaptive fir filter with a derived class overriding the error and tap update methods to create a particular type of adaptive filter. This has been checked in. The adaptive FIR class is complete but unoptimized. Instead of using an existing gr_fir_xx class, it internally implements a generic dot product for the FIR output calculation. It presently is only implemented for _ccf signature but it would be possible to make it into a template. I've created a constant modulus filter skeleton with null error and tap update methods. The default taps start with 1.0 and the remainder are zeros so the output is identical to the input. I'll be working on the CMA class tomorrow. Depending on speed it may make sense to eliminate the base class, but I'm hoping not to have to. -Johnathan, AE6HO _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
