On Mon, Mar 10, 2014 at 4:16 PM, Nowlan, Sean
<sean.now...@gtri.gatech.edu> wrote:
>>On Mon, Mar 10, 2014 at 5:55 AM, Martin Braun <martin.br...@ettus.com> wrote:
>>> On 03/10/2014 01:08 AM, Nowlan, Sean wrote:
>>>> I'm using get_tags_in_range with bounds outside the absolute sample
>>>> offsets presented in each work function. I'm using this to add
>>>> end-of-burst tags at offset K-1 for every start-of-burst tag that I
>>>> find at offset K (except the very first K).
>>>>
>>>> I just want to confirm that this is valid. All my tests have shown
>>>> that it is, since I believe the underlying deque is completely
>>>> independent of the data stream except that offsets are used for both
>>>> absolute sample offsets and tag bookkeeping.
>>>
>>> I think you're right, but only if you do this *after* the current
>>> bounds, not before.
>>>
>>> M
>
>>Yes, the scheduler prunes all tags before the window after work is done.
>>Basically, since we're tagging a data sample, if that sample is no longer
>>available to you, neither is it's >tag. You'll have to get them and store
>>them locally for your uses later.
>
>>Tom
>
> Ok, that makes sense; I'd be unable to read tags from the past. But what
> happens if I *create* a tag on a past data sample? Will it be propagated or
> ignored?
>
> ( A ) { B }
> (0 1) { 2 3 4 } 5 ...
>
> Let's say section ( A ) is from a previous call to work. Let's also say { B }
> is the current work window, i.e., nitems_read(0) == 2 and noutput_items == 3.
> If I find a start-of-burst tag on absolute offset 2, is it impossible to
> create a new tag on absolute offset 1?
>
> The vast majority of the time, this would not be a problem. The boundary
> condition is really the only source of trouble. I suppose I could use
> set_history(2) so that I can always see the tags at the offset range
> endpoints. Do you advise this? Does history ensure the scheduler doesn't
> prune tags from the history region?
>
> Sean
Yeah, if you set a tag to a time in the past, the following blocks
will (likely, based on the dynamics of the scheduler) prune it before
your follow-on block can process it.
I'd have to double check and think about the case where you use
set_history for this. It seems like it should work, but just remember
that set history really just initializes your read pointers back by
history()-1 number of items. So the tag wouldn't go on item-2 in the
stream since index 0 of the buffer /is/ item-2 already.
But something like this, if not exactly, should work, yes.
Tom
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
