# A question about function gr::block::set\_history() **URL:** \ **Category:** GNU Radio\ **Created:** [May 19, 2014, 2:15pm UTC](https://www.ruby-forum.com/t/a-question-about-function-gr-set-history/241214 "2014-05-19T14:15:39Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [May 19, 2014, 2:15pm UTC](https://www.ruby-forum.com/t/a-question-about-function-gr-set-history/241214/1 "2014-05-19T14:15:39Z")
Hi, I wrote a block using gnuradio history functionality. The block is inherited from gr::block (built by command “gr\_modtool add -t general my\_block”), with history set to a bit large number, 320. I then finished rest parts of the block. I run the flowgraph and output the input buffer of this block when the general\_work() function is called. Then I found the history of the block is stored at the end of the input buffer, which is not as what the tutorial said. For example, suppose my block is prepended by a delay block with delay value set to 16, the content of the input buffer of my block at the first time when general\_work() is called is 336 complex zeros. Then my block consume all 16 zeros by calling consume\_each(16) and return the number of output items. According the description of gnuradio history functionality, the content of the input buffer of my block at the second time when general\_work() is called ought to be 320 complex zeros (history) followed by some data items. Yet in fact, what I get at second time is some data items followed by 320 complex zeros! I have no idea why it happens. Could anyone help me please? Thank you! – View this message in context: [http://gnuradio.4.n7.nabble.com/A-question-about-function-gr-block-set-history-tp48313.html](http://gnuradio.4.n7.nabble.com/A-question-about-function-gr-block-set-history-tp48313.html) Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![qiank10](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/958977/32.png) [@qiank10](https://www.ruby-forum.com/u/qiank10)\ **Post date:** [May 19, 2014, 3:38pm UTC](https://www.ruby-forum.com/t/a-question-about-function-gr-set-history/241214/2 "2014-05-19T15:38:21Z")
On Mon, May 19, 2014 at 8:14 AM, Kun Q. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > general\_work() function is called. Then I found the history of the block is > general\_work() is called ought to be 320 complex zeros (history) followed > by > some data items. Yet in fact, what I get at second time is some data items > followed by 320 complex zeros! > > I have no idea why it happens. Could anyone help me please? Thank you! Take a look at the PDF that I posted here: > **[Explaining the GNU Radio Scheduler — Rondeau Research](http://www.trondeau.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html)** > > The most important and distinguishing piece of GNU Radio is the underlying scheduler and framework for implementing and connecting the signal processing blocks. While there are many other libraries of DSP blocks available, it's GNU Radio's scheduler... Specifcally slide 24. That might show you what’s going on with the set history concept. In reality, it sets the read pointer history()-1 items back when the flowgraph starts, so you’ll have that many zeros, which then allows the block to read ahead. Tom ---
**Author:** ![qiank10](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/958977/32.png) [@qiank10](https://www.ruby-forum.com/u/qiank10)\ **Post date:** [May 19, 2014, 5:50pm UTC](https://www.ruby-forum.com/t/a-question-about-function-gr-set-history/241214/3 "2014-05-19T17:50:23Z")
Thank you for your quick answer! I think I get how gnuradio works with history from your slides: 1. When flowgraph starts, the read pointer of input buffer is set history()-1 items back. 2. After calling work()/general\_work() function, gnuradio scheduler get the number of consumed items of that input buffer and move the read pointer forward by that number. Then scheduler wait until next time calling work()/general\_work() function. Is it right? And I think I find the error. In gr::block::general\_work(), the parameter ninput\_items equals to the _sum_ of _noutput\_items of previous block_ and _history()-1_, isn’t it? I thought ninput\_items equals to noutput\_items of previous block when I built the block. – View this message in context: [http://gnuradio.4.n7.nabble.com/A-question-about-function-gr-block-set-history-tp48313p48333.html](http://gnuradio.4.n7.nabble.com/A-question-about-function-gr-block-set-history-tp48313p48333.html) Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![qiank10](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/958977/32.png) [@qiank10](https://www.ruby-forum.com/u/qiank10)\ **Post date:** [August 9, 2014, 11:57am UTC](https://www.ruby-forum.com/t/a-question-about-function-gr-set-history/241214/4 "2014-08-09T11:57:27Z")
2014-08-08 16:25 GMT+08:00 Lei [via GnuRadio] \< [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\>: > ``` > Sorry to bother you.I have some confusions on general_work(). > 1.What's the mechanism of the general_work()? I've no idea about > > ``` > > how to > find the material on it,and the site of gnu radio has too little > information on it. The function _general\_work_ is the place where a block processes input items and generates output items according to its functionality (such as filter). Besides the functionality, you have to tell the invoker how many items from each input port are consumed by invoking function _consume_ or _consume\_each_ and how many items for each output port are generated through return value. ``` 2.Is the method general_work() called automatically ?It seems ``` that > the function can consume the data automatically.How or whether can I > control the > execution of general\_work()? Exactly, _general\_work_ are all automatically invoked by gr-scheduler, one of the core component of gnuradio, which handles runtime stuff of whole flow graphs. So, you don’t have to control the execution of general\_work(). The following PDF gives a brief introduction about gr-scheduler, including _general\_work_ function: > **[Explaining the GNU Radio Scheduler — Rondeau Research](http://www.trondeau.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html)** > > The most important and distinguishing piece of GNU Radio is the underlying scheduler and framework for implementing and connecting the signal processing blocks. While there are many other libraries of DSP blocks available, it's GNU Radio's scheduler... ``` Thanks.Looking forward to your reply ``` ---
**Author:** ![qiank10](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/958977/32.png) [@qiank10](https://www.ruby-forum.com/u/qiank10)\ **Post date:** [May 20, 2014, 11:14am UTC](https://www.ruby-forum.com/t/a-question-about-function-gr-set-history/241214/5 "2014-05-20T11:14:49Z")
On 19.05.2014 17:48, Kun Q. wrote: > And I think I find the error. In gr::block::general\_work(), the parameter > ninput\_items equals to the _sum_ of _noutput\_items of previous block_ and > _history()-1_, isn’t it? I thought ninput\_items equals to noutput\_items of > previous block when I built the block. That’s right. Everything in the input buffer is described by ninput\_items, and that includes history. M