Forum: GNU Radio tag propagation in GNU Radio blocks

How does tag propagation work in these 3 cases? Up until now I've only 
been dealing with tags on streams running at the output rate of a USRP 
sink. I've stated the assumed answers, but haven't tested...

1) gr_sync_block (interpolation by factor L): tag on incoming sample x 
will be moved to sample x*L in output stream

2) gr_sync_block (decimation by factor M): tag on incoming sample x will 
be moved to sample FLOOR(x/M) in output stream

3) gr_block with arbitrary relationship: user has to move tags 
him/herself in general_work.

Another question: does the scheduler re-number absolute sample offsets 
after every rate-changing block, or does it work backwards from a sink 
block all the way to the source block so that absolute offsets are 
relative to the output? I can see this getting more hairy when multiple 
source and sink blocks are used.

Thanks,
Sean

On Mon, Nov 5, 2012 at 4:11 PM, Nowlan, Sean
<Sean.Nowlan@gtri.gatech.edu> wrote:
> moved to sample FLOOR(x/M) in output stream
> the way to the source block so that absolute offsets are relative to the
> output? I can see this getting more hairy when multiple source and sink
> blocks are used.
>
>
>
> Thanks,
>
> Sean


Sean,

Yes, you've pretty much got it. All blocks have a relative_rate. For
interpolating blocks (by L), realative_rate=L, decimating by M
relative_rate=1/M. Any other block that has a rate change should set
the relative_rate.

When a tag is moved to a block, the propagation of the tag handles the
changing of the item number based on the relative rate. This happens
each time the tag is moved between blocks. Since there's no state
known about the rates of any other blocks, we cannot make a call on
that when the tag is actually read or used.

There are some tricky blocks that don't have a static relative rate
that can cause problems with this concept. It's for this reason that
we created the TPP_DONT tag propagation policy. This tells the
scheduler not to automatically pass tags along. In these cases, we
expect the block itself to handle (or not) the proper manipulation of
the tag numbers.

Tom

>> sink. I've stated the assumed answers, but haven't tested...
>>
>>
>
>When a tag is moved to a block, the propagation of the tag handles the changing 
of the item number based on the relative rate. This happens each time the tag is 
>moved between blocks. Since there's no state known about the rates of any other 
blocks, we cannot make a call on that when the tag is actually read or used.
>
>There are some tricky blocks that don't have a static relative rate that can 
cause problems with this concept. It's for this reason that we created the 
TPP_DONT tag >propagation policy. This tells the scheduler not to automatically 
pass tags along. In these cases, we expect the block itself to handle (or not) the 
proper manipulation of >the tag numbers.
>
>Tom

Ok, so the "absolute sample index" at a particular block boundary is 
really the nitems_written at the output of that block, and there is no 
absolute index mapping maintained across a chain of blocks?

Thanks for clearing that up! I see in gr_block.cc that the default tag 
propagation policy is ALL-TO-ALL, and the corresponding behavior in 
gr_block_executor.cc is that tags are moved according to tag.offset = 
tag.offset * relative_rate.

On Mon, Nov 5, 2012 at 5:48 PM, Nowlan, Sean
<Sean.Nowlan@gtri.gatech.edu> wrote:
>>> sink. I've stated the assumed answers, but haven't tested...
>>>
>>>
>>
>>When a tag is moved to a block, the propagation of the tag handles the changing 
of the item number based on the relative rate. This happens each time the tag is 
>moved between blocks. Since there's no state known about the rates of any other 
blocks, we cannot make a call on that when the tag is actually read or used.
>>
>>There are some tricky blocks that don't have a static relative rate that can 
cause problems with this concept. It's for this reason that we created the 
TPP_DONT tag >propagation policy. This tells the scheduler not to automatically 
pass tags along. In these cases, we expect the block itself to handle (or not) the 
proper manipulation of >the tag numbers.
>>
>>Tom
>
> Ok, so the "absolute sample index" at a particular block boundary is really the 
nitems_written at the output of that block, and there is no absolute index mapping 
maintained across a chain of blocks?

That's correct. The blocks (actually, the buffers attached to the
blocks) keep track of the item counts. We try to minimize state across
a flowgraph unless it's directly related to the flowgraph operation
itself. We want to keep blocks as independent as possible.

> Thanks for clearing that up! I see in gr_block.cc that the default tag 
propagation policy is ALL-TO-ALL, and the corresponding behavior in 
gr_block_executor.cc is that tags are moved according to tag.offset = tag.offset * 
relative_rate.

Yep, you got it!

Tom