Re: [Discuss-gnuradio] tag propagation in GNU Radio blocks

[Tom Rondeau]

On Mon, Nov 5, 2012 at 4:11 PM, Nowlan, Sean
<address@hidden> wrote:
> 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


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