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 <richard.bell4@gmail.com> wrote:
RichWill this snippet produce what you would think should be produced, a running average over the latest three input values?3) filter is 3 taps long with values: [1/3 1/3 1/3]2) noutput_items = 2 always1) complete input data set to be filtered, 10 samples long: [1 2 3 4 5 6 7 8 9 10]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:
for(int nn = 0; nn < noutput_items; nn++)
{
out[nn] = d_shape_filter->filter(&in[nn]);
}
No comments:
Post a Comment