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

[Nowlan, Sean]

>-----Original Message-----
>From: address@hidden [mailto:address@hidden On Behalf Of Tom Rondeau
>Sent: Monday, November 05, 2012 5:16 PM
>To: Nowlan, Sean
>Cc: address@hidden
>Subject: Re: [Discuss-gnuradio] tag propagation in GNU Radio blocks
>
>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

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.