Re: [Discuss-gnuradio] block history question

[Marcus Müller]

Hello Andrew,

Excellent visualizations!
I'd like to comment on your "summary" slide:

Setting history to n increases the number of items available to the work
function in any given work call by n-1.

Exactly! The idea is that you get the n-1 "last" items of last call to work…

This is done by giving n-1 zero-
value items at the beginning of the first work call.

… and because there's no "last call" before the first call, these get zero-initialized.

History of length n means:
• The n-1 items beyond noutput_items can be processed in the
work call

In fact, this feels like talking about semantics, but: the idea really is that your "current" input to work() starts at input_items[n-1], and input_items[0,…,n-1] are history that your block still needs.

• Block latency of n-1 of items
• Tags can be set in the first noutput_items giving the appearance of
tagging backward in time

So this might now get hairy!

noutput_items as handed over to your work function is the maximum number of items your block is allowed and asked to produce (which means it'll end up overwriting them in the output buffer. Generally, noutput_items is mostly limited of how much of the output buffer has already been read by the downstream block, so that you don't overwrite stuff that the downstream block hasn't yet consumed).

If we now modify your visualization:



so that it reflects the semantics of "history" being the first part of your input:



then things become a bit easier to explain.

First of all, it's labeled "noutput_items" in your figure, but what it really means is "new input items available". The fact that the number of input items available and items you're allowed to produce on the output are the same is because you're using a sync block, where it is said that for every input item you produce exactly one output item – so there's no need for GNU Radio to tell your block how much input is available in addition to how much output space is available – it just uses the smaller of these two numbers and gives you noutput_items. You can produce up to that amount of items, which means you won't read more than that amount of items, so one number is sufficient here. By the way, you don't have to produce all noutput_items, anything smaller is fine, too!
In the general gr::block case, you get both – a number of maximum items you're allowed to produce, and a list containing how much input is ready on each input port. So let me re-label that:




So now to the question of stream tags:
Tag offsets are specified relative to the item number of the stream they are written to. Imagine all your block does is copying new in- to output, and adding a stream tag to the first item of every work() "chunk" containing the value of the oldest item in history squared – i.e. "in[0]²".
Then, the first item you'd copy in your first call to work would be the value "1", and it would be tagged with "0". The first item you'd copy on your second call would be 11, and it would be tagged with "81". Notice that understaning history as something prepended means that you're not "tagging in the past" on the output, but just keep counting from the first item of output you produce. That point of view (at least for me) conserves the idea of causality.

I hope that cleared things up a bit, and really: thanks for asking such questions in great detail!

Best regards,
Marcus

On 29.04.2016 23:29, Harper, Andrew wrote:

Hello all,

 

We’re exploring the nuances of the block feature “history.” We’ve created a couple slides based on information we’ve gathered from the mailing list and our own experimentation. It outlines how we believe this function works. Can anyone confirm or deny the correctness of the information in our slides?

 

Many thanks!

 

Andrew Harper

Research Engineer

Georgia Tech Research Institute

 

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio