Filters in GNU Radio

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

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 B. [email protected]

Yes you will need history set yourself.

Just look at how the actual existing FIR block does it …

Cheers,

Sylvain

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs