Re: [Discuss-gnuradio] FFT filter bug in GR3.7.4

[Marcus D. Leech]

> That's actually not surprising. The buffer is established when the 
> top_block is started and will be based on the size of the FFT you need 
> to run. Increasing the size of the filter will not increase the size 
> of the buffer. We'll have to figure out how we want the solution to 
> this to look. Might be we just refuse to increase the filter size 
> during runtime so you'll have to lock/unlock the flowgraph. Will think 
> more on this...
>
> Tom
It's counter to the experience with the regular dot-product FIR filters 
in that you can re-size them at runtime and it's just fine.  It 
certainly fails the
  "least astonishment" test when you have a filter that's configured 
for "pass-through" (1+0j single tap) and then later ask it to do some real
  filtering.

But this bug has been around for a long time, as I was reminded.  My 
other code has "hacks" to get around this, and when I was re-structuring
  for migration to GR3.7, it reared its unpleasant little head again.

Granted, my use case, in this case, is a bit weird--the filter can go 
from "passthrough" to "farking massive" in one swell foop, when the user
  turns on coherent dedispersion and suddenly that's a rather-large 
de-dispersion filter in the path.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org