[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] tag propagation in GNU Radio blocks
From: |
Tom Rondeau |
Subject: |
Re: [Discuss-gnuradio] tag propagation in GNU Radio blocks |
Date: |
Tue, 6 Nov 2012 10:32:00 -0500 |
On Mon, Nov 5, 2012 at 5:48 PM, Nowlan, Sean
<address@hidden> wrote:
>>-----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?
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