-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 George Nychis wrote: > What general_work() would do is use the first ntaps() samples as > "history" and start producing output at in+ntaps(). I would then > consume ninput_items-ntaps() to then keep those last ntaps() samples in > the input queue as the "history" for the next series of input. > > I'm sorry if my logic is slightly or completely off. But then I look at > most of the FIR filters, and see the use of set_history(), great! This > sounds like it is exactly what I want. Furthermore, looking at the > documentation it states that it is what I want: > http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/runtime/gr_block.h#L62
What set_history actually does is prepend that many zero samples. But it still adds forecast(noutput_items) samples to the input buffer before calling work... So when work() is called with noutput_items, history+forecast(noutput_items) samples are ready in the input buffer, starting from index 0. If you look at the implementation of filterN, it reads at samples 0..ntaps-1. So when you call filterN with noutput_items as the length parameter it will eventually read items 0..noutput_items+ntaps-1. Here you've set ntaps = history. In the normal code in the trunk, this works just as expected. But when you make your custom vectors, you only pull noutput_items out of the input buffer, not noutput_items+history. Also, my understanding of a normal matched filter is that it does the normal complex multiplication (by the conjugate, but I'm assuming you've done that already before building the taps), not the real-wise and complex-wise ... inner product, I guess? ... as you've defined it. - -Dan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHqXwCy9GYuuMoUJ4RApVoAKDC3Xrm7spiGzCZZNaS5tvYuPXzzwCfbQzN pjjttuBVpMgY4vPo6l5/KLc= =QVtD -----END PGP SIGNATURE----- _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
