After looking through the manual, I see there is a buffer version of fir filter. Documentation is pretty light on these, but I'm guessing my previous email is not correct. The delay line values in the non-buffered filter are not stored in the memory space created when we called new kernel::fft_filter_fff in the constructor. I would have to use set_history (I think?) to maintain coherence between work calls.
On Wed, Aug 19, 2015 at 2:20 PM, Richard Bell <[email protected]> wrote: > Am I correct in concluding when I use fir_filter_fff to filter, that > because it uses its own memory space, I don't need to use set_history and > worry about boundary crossing between calls to work? Will the output of the > filter behave as expected across work call boundaries if I keep passing > samples to the filter? > > As an example, suppose the following: > 1) complete input data set to be filtered, 10 samples long: [1 2 3 4 5 6 7 > 8 9 10] > 2) noutput_items = 2 always > 3) filter is 3 taps long with values: [1/3 1/3 1/3] > > for(int nn = 0; nn < noutput_items; nn++) > { > out[nn] = d_shape_filter->filter(&in[nn]); > } > > Will this snippet produce what you would think should be produced, a > running average over the latest three input values? > > Rich >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
