On Thu, Sep 8, 2011 at 6:22 PM, Martin Braun
<address@hidden> wrote:
On Thu, Sep 08, 2011 at 09:41:03AM -0700, Eugene Grayver wrote:
> Hello,
> I am starting to actively use stream tags and am finding them quite useful. I
> have one suggestion:
>
> Tags propagated through a block with a known delay (set_history) should be
> adjusted by that delay. For example, an input to an FIR filter gets reflected
> in the output after a delay. Since the GR executor has access to the delay
> info, there's no reason it should not use it.
>
> Comments?
An FIR filter is a good example why this is not always a good idea: The
group delay (which would be a sensible delay for a tag, I guess) is half
the delay GNU Radio knows about. Can stream tags be delayed w/ respect
to the sample position? That would be more useful, I guess.
MB
I don't think that changing the tag value by the history() amount is necessarily a good idea. When a block that has set its own history value receives a tag, the tag's item value would have been changed by adding history() to it. But usually, these blocks process data from history() to history()+noutput_items, so the stream going to the next block is basically "reset" to before the history() value. So now the tag doesn't make sense to the next blocks down the line.
In this case, I think it makes the most sense to just have each block take care of the history settings themselves when dealing with tags.
Also, I'm not sure this is entirely true. I mapped it out, but I could have missed something.
>
> On a separate note, I have observed a _rare_ case where tags get lost. The
> scenario involves an output attached to two inputs. The two inputs consume
> data in different (random) chunk blocks. It appears that if one of the inputs
> consumes items with the tag well before the second input gets to the tagged
> item, the second input sometimes does not see the tag. I have not debugged
> this enough to confirm that there's no bug in my code.
I think this is a similar bug to what Colby found. For synchronous blocks and blocks with known decimation and interpolation rates, the tags all work properly. When there is a more varied value in the rate change, it looks like there might be a bug that calculates the change in tag value wrong by a sample. When this is set wrong, it can be outside of the range of the next blocks window and so gets pruned.
It might just be a matter of using a ceil() (or maybe floor()) when propagating the tags between blocks with rate changes in gr_block_executor.cc, but I haven't looked into this to tell what the right answer is. You're the second person to observe this behavior, so it's starting to become a priority to fix.
> Eugene
> ________________________
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel:
310.336.1274
Thanks,
Tom