A question about function gr::block::set_history()

GNU Radio
1

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
Sent from the GnuRadio mailing list archive at Nabble.com.

2

On Mon, May 19, 2014 at 8:14 AM, Kun Q. [email protected] 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:

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

3

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
Sent from the GnuRadio mailing list archive at Nabble.com.

4

2014-08-08 16:25 GMT+08:00 Lei [via GnuRadio] <
[email protected]>:

    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:

    Thanks.Looking forward to your reply
5

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