# Get\_tags\_in\_range **URL:** \ **Category:** GNU Radio\ **Created:** [March 10, 2014, 1:10am UTC](https://www.ruby-forum.com/t/get-tags-in-range/239670 "2014-03-10T01:10:37Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [March 10, 2014, 1:10am UTC](https://www.ruby-forum.com/t/get-tags-in-range/239670/1 "2014-03-10T01:10:37Z")
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. Sean ---
**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\ **Post date:** [March 10, 2014, 10:56am UTC](https://www.ruby-forum.com/t/get-tags-in-range/239670/2 "2014-03-10T10:56:43Z")
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 ---
**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\ **Post date:** [March 10, 2014, 2:02pm UTC](https://www.ruby-forum.com/t/get-tags-in-range/239670/3 "2014-03-10T14:02:07Z")
On Mon, Mar 10, 2014 at 5:55 AM, Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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 ---
**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\ **Post date:** [March 10, 2014, 4:18pm UTC](https://www.ruby-forum.com/t/get-tags-in-range/239670/4 "2014-03-10T16:18:35Z")
> > > 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 ---
**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\ **Post date:** [March 11, 2014, 2:27pm UTC](https://www.ruby-forum.com/t/get-tags-in-range/239670/5 "2014-03-11T14:27:38Z")
On Mon, Mar 10, 2014 at 4:16 PM, Nowlan, Sean [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > > absolute sample offsets and tag bookkeeping. > > > > 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 ---
**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\ **Post date:** [March 11, 2014, 4:58pm UTC](https://www.ruby-forum.com/t/get-tags-in-range/239670/6 "2014-03-11T16:58:51Z")
> > > > > independent of the data stream except that offsets are used for > > 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. Ok, I guess I should go poke around the prune\_tags logic and see how it works. If it respects history(), it wouldn’t prune tags from any item that is available at the start of the read pointer, including history. If it doesn’t, tags may be abandoned/pruned even though I have access to history()-1 number of previous items, and I’m still stuck. Functionally speaking, if I can read a sample, I should be able to read its associated tags. But history() only involves input buffers, not output buffers, so perhaps I’m still falling into the trap mentioned above, i.e., the tag may be pruned before the downstream block can see it. > But something like this, if not exactly, should work, yes. I’m trying to determine an “exact” solution. This is another way to work around PFB arb resampler tag propagation issues (discussed in issue #652). Basically I’m adding a start-of-burst tag to the first sample of a stream pre-resampler, and then once things have been resampled, I go back and fill in end-of-burst tags. This avoids having to know when the PFB arb resampler adds +/- 1 samples. This block I’ve written is a sync\_block that simply does a memcpy of samples and the tag processing mentioned above. Now I’m thinking a workaround could be to return noutput\_items-1 items. This way I get to check the last item of a work input buffer, nitems\_read(0)+noutput\_items-1, for a start-of-burst tag and place an end-of-burst tag at nitems\_read(0)+noutput\_items-2. At the next call to work, that last item of the previous input buffer is the first item of the input buffer, and I can put an end-of-burst tag at nitems\_read(0) if I find a tag at nitems\_read(0)+1. Makes sense in my head, at least… > Tom Sean