On Mon, Nov 21, 2005 at 08:52:24PM +0000, Robert McGwier wrote: > > Your latter suggestion (do it in blocks) with a once per block > integrator makes perfect sense and would save many ticks. > Mathematically, it is nearly identical. Since we are taking a perfect > average for the block, we would have to change the integration time > constant on the IIR to accomodate varying block sizes, but I see this as > no problem would be a computational win. > > Thanks, > Bob
> Martin Dvh wrote: > > >You could use a decimating fir with no window (use all samples) > >and taps (1.0/ntaps,1.0/ntaps,1.0/ntaps,1.0/ntaps, .....) > >and decimation==ntaps > >followed by a single pole IIR (running at a much lower rate) > >What you win by this is the more efficiant SIMD implementation of FIR > >versus IIR. > >You could also make a block which just adds up a whole block of samples > >Then divide the result by the number of samples, followed by a single pole > >IIR. This way you avoid the tap multiplication. > >(I used this once for DC-removal in a test gnuradio ADC frontend) These are all good ideas. Absent any measurement data that says that any of this matters, I suggest we ignore the issue (premature optimization...) The single pole IIR is implemented inline and requires 2 multiplies and 1 add per sample, versus 1 procedure call, 1 multiply and 1 add for the FIR. I doubt the DC removal is above 1% of the CPU consumption of the receiver. oprofile would give us real data. Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
