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?
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.
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.
in the output after a delay. Since the GR executor has access to the
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.
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.