# FFT filter bug in GR3.7.4

**URL:** <https://www.ruby-forum.com/t/fft-filter-bug-in-gr3-7-4/240198>\
**Category:** GNU Radio\
**Created:** [April 1, 2014, 8:22pm UTC](https://www.ruby-forum.com/t/fft-filter-bug-in-gr3-7-4/240198 "2014-04-01T20:22:23Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\
**Post date:** [April 1, 2014, 8:22pm UTC](https://www.ruby-forum.com/t/fft-filter-bug-in-gr3-7-4/240198/1 "2014-04-01T20:22:23Z")

</div>

Tag: v3.7.4git-50-ga8f73d85

This demonstrates a horrible bug I found in FFT filters–change the size  
from “little” to “quite large”, and the scheduler goes running home to  
momma:

thread[thread-per-block[1]: \<block fft\_filter\_ccc (12)\>]: Buffer too  
small for min\_noutput\_items

I’ve attached a minimal GRC to show this.

---

<div class="post-metadata">

**Author:** ![Marcus\_DSLeech](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/74df32/32.png) [@Marcus\_DSLeech](https://www.ruby-forum.com/u/Marcus_DSLeech)\
**Post date:** [April 3, 2014, 12:03am UTC](https://www.ruby-forum.com/t/fft-filter-bug-in-gr3-7-4/240198/2 "2014-04-03T00:03:34Z")

</div>

On Tue, Apr 1, 2014 at 2:21 PM, Marcus D. Leech [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> I’ve attached a minimal GRC to show this.
> 
> –  
> Marcus L.  
> Principal Investigator  
> Shirleys Bay Radio Astronomy Consortium  
> [http://www.sbrac.org](http://www.sbrac.org)

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

---

<div class="post-metadata">

**Author:** ![Marcus\_DSLeech](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/74df32/32.png) [@Marcus\_DSLeech](https://www.ruby-forum.com/u/Marcus_DSLeech)\
**Post date:** [April 3, 2014, 12:10am UTC](https://www.ruby-forum.com/t/fft-filter-bug-in-gr3-7-4/240198/3 "2014-04-03T00:10:00Z")

</div>

> 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 L.  
Principal Investigator  
Shirleys Bay Radio Astronomy Consortium

> **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org)**
>
> Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami.

---

<div class="post-metadata">

**Author:** ![Marcus\_DSLeech](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/74df32/32.png) [@Marcus\_DSLeech](https://www.ruby-forum.com/u/Marcus_DSLeech)\
**Post date:** [April 3, 2014, 12:18am UTC](https://www.ruby-forum.com/t/fft-filter-bug-in-gr3-7-4/240198/4 "2014-04-03T00:18:46Z")

</div>

On Wed, Apr 2, 2014 at 6:08 PM, Marcus D. Leech [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> >

Agreed that it’s counter intuitive based on experiences with the  
fir\_filters. But that’s the difference between the overlap-and-save  
algorithm that you need to process it a chunk at a time. Unless you want  
us  
to put in an internal buffer to store the data while it streams in  
(which  
should make Philip jump in here and scream about adding another memory  
copy  
operation).

Tom