Re: [Discuss-gnuradio] block history question

[Andy Walls]

From:   Harper, Andrew
Date:   Fri, 29 Apr 2016 21:29:42 +0000
> 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?
> 

I like your efforts to clearly explain things to others.  So please
don't take the comments below as throwing stones; they are just what I
see wrong.
  

Slide 1:
"The scheduler *requires* the data input buffer to be processed
piecewise ..."

A block really doesn't have much choice in the matter. :)


Slide 1:
"Let’s say the first 3 work calls give *ninput_items[0]* values ..." 

The general case block gets supplied both a vector of ninput_items and
an noutput_items.  For synchronous blocks, the value noutput_items and
the declared block interpolation or decimation rate imply
ninput_items[].
Since you're focusing on history() and the effects on the number of
input items, you should explcitly use ninput_items[] in your
dissussion.


Slide 1:
You should rename your red bracket in the picture from "noutput_items"
to "ninput_items[0]".  You should also right align that short bracket
with the buffer.  Making it clear that the history() (or in this case
the initial 0 history()) samples are old, repeated input data. 


Slide 2, "2nd call to work":
Same thing: change to "ninput_items[0]" and right align.  You want to
emphasize that items 9 and 10 are repeated items that were available in
the previous call to work.


Slide 3, "3rd call to work":
Same thing.


Slide 4:
"... This is done by providing the n-1 last items from the previous
call to work() at the beginning of the current call to work().  At
flowgraph start, the n-1 initial items are zero-valued." 


Slide 4, bullet 1:
*ninput_items[input_connection_number]* Don't use noutput_items unless
you are specifically talking about a synchronous 1:1 block.


Slide 4, bullet 2:
The statement about block latency is not true in the general case,
although it can be true in specific cases.  Latency is determined by
the algorithm the block is implementing.


Slide 4, bullet 3:
Output tags can be set on tag offsets nitems_written(0) to
nitems_written(0) + 'items produced' - 1.  Tagging "backward in time"
is not a correct way to think about it, since you're tagging the
output, which can in a trivial example case be just a delayed copy of
the input (e.g. FIR filter with taps [0, 0, 0, 1, 0, 0, 0]).  It's
really called "not accounting for algorithm delay properly when
propagating tags from input to output".

I did rework the guts of a block (the corr_est block) that does
conceptually tag "backward in time", since that was its functional
requirement: tag the beginning of a correlation sequence once you've
found the correlation peak.  The GNURadio runtime does not allow
tagging of output items with offsets less than nitems_written() in a
call to work(), so the corr_est block uses history() to artifically
delay the primary output port so it can do this tagging "backward in
time".    The restriction here though is nitems_written() on the
subject output port, and not really about the input items.    

Regards,
Andy


> 
> Many thanks!
> 
>  
> 
> Andrew Harper
> 
> Research Engineer
> 
> Georgia Tech Research Institute