Tag propagation in GNU Radio blocks

GNU Radio
1

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

2

On Mon, Nov 5, 2012 at 4:11 PM, Nowlan, Sean
[email protected] 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

3

On Mon, Nov 5, 2012 at 5:48 PM, Nowlan, Sean
[email protected] 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

4

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.