# Block keeps buffering data

**URL:** <https://www.ruby-forum.com/t/block-keeps-buffering-data/242935>\
**Category:** GNU Radio\
**Created:** [August 8, 2015, 6:05pm UTC](https://www.ruby-forum.com/t/block-keeps-buffering-data/242935 "2015-08-08T18:05:12Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\
**Post date:** [August 8, 2015, 6:05pm UTC](https://www.ruby-forum.com/t/block-keeps-buffering-data/242935/1 "2015-08-08T18:05:12Z")

</div>

Hi,

I’ve written a Python block to feed some binary data into my QPSK  
transmission. This block is supposed to grab the data according to the  
1200 baud rate I have set up for the transmission. Well, so I thought.

GNU Radio keeps calling the work() function inside the block even  
though the upstream flowgraph does not need the data yet. This results  
in my block providing too much stale buffered data.

Is there a way to make the block work() function only being called  
when the connected block really requests data? I thought I could use a  
Throttle block but that does nothing either.

Suggestions?

Thanks,  
Wolfgang

---

<div class="post-metadata">

**Author:** ![Wolfgang\_Nagele](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/e495f1/32.png) [@Wolfgang\_Nagele](https://www.ruby-forum.com/u/Wolfgang_Nagele)\
**Post date:** [August 8, 2015, 6:39pm UTC](https://www.ruby-forum.com/t/block-keeps-buffering-data/242935/2 "2015-08-08T18:39:40Z")

</div>

Hi Wolfgang,

well, GNU Radio is not really based on a “requesting data” model – it’s  
mainly buffer driven.  
This means that as long as there’s space in your block’s output buffer,  
GNU Radio might (and will) call your work() function. Typical buffer  
sizes are e.g. 8192 items. So, GNU Radio uses backpressure to limit the  
rate at which things run.  
You can try gr::block::set\_max\_output\_buffer, but please heed the  
warnings in [1]: This kind of breaks a lot of assumptions about “good”  
buffer sizes.

On a different note, this sounds like a hint of architectural problem in  
your transmitter. I assume 1200 bd means that you take x bits, generate  
y symbols out of these, and package these into z samples. These z  
samples are then fed to SDR hardware, consuming at a constant sampling  
rate. Now, since the ratio of y/x is fixed, and so is the ratio z/y,  
normally the hardware sampling rate simply defines how many bits are  
consumed in a given time; GNU Radio then just makes sure this happens as  
soon as possible (i.e. to keep the items flowing as far as possible).  
That is typically very good – because it a) means that transmit samples  
are computed as early as possible, so that “hiccups” upstream are hidden  
by the full buffers, and b) so that the slowest part in your signal  
processing chain (which _should_ be the SDR hardware) defines the speed  
at which things happen.

Now, there’s some cases where that doesn’t apply, mainly “bursty” data  
– I don’t know whether yours is one of these, but in case it is:  
Have a look at Tim O’Shea’s gr-eventstream [2]; it doesn’t change the  
way GNU Radio works (ie. your buffer sizes define the latency between a  
burst of samples being injected into the otherwise continuous 0-sample  
stream and that burst reaching your SDR hardware), but it makes working  
with bursty data more intuitive and allows for non-continuous data to be  
fed into GNU Radio.

Best regards,  
Marcus

[1][http://gnuradio.org/doc/doxygen/classgr\_1\_1block.html#ae2405dc2f6c84bb8e59aab56e4ce9d84](http://gnuradio.org/doc/doxygen/classgr_1_1block.html#ae2405dc2f6c84bb8e59aab56e4ce9d84)  
[2] [http://oshearesearch.com/tag/gr-eventstream/](http://oshearesearch.com/tag/gr-eventstream/)

---

<div class="post-metadata">

**Author:** ![Wolfgang\_Nagele](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/e495f1/32.png) [@Wolfgang\_Nagele](https://www.ruby-forum.com/u/Wolfgang_Nagele)\
**Post date:** [August 9, 2015, 7:15am UTC](https://www.ruby-forum.com/t/block-keeps-buffering-data/242935/3 "2015-08-09T07:15:37Z")

</div>

Hi Marcus,

Thanks for the detailed response - this helped me clear a few things up.

Firstly it made me understand why GNU Radio when run with low sampling  
rates (\<32k) seemed to behave “erratic”.

My problem was that the buffer kept being filled but my input source  
block was dependent on input data that is changed over time (think  
telemetry). Thus if the buffer keeps filling it basically fills with  
data all of the current instant instead of the data as it changes over  
time.

I have been battling with eventstream as well and it was actually  
having the same issue. Now that I understood this buffering behaviour  
I just had to adjust the buffer down so it would be relevant to a 1200  
baud flowgraph (the standard buffer is massively too big).

Cheers,  
Wolfgang