# Stream tags **URL:** \ **Category:** GNU Radio\ **Created:** [March 24, 2011, 11:31am UTC](https://www.ruby-forum.com/t/stream-tags/204901 "2011-03-24T11:31:33Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\ **Post date:** [March 24, 2011, 11:31am UTC](https://www.ruby-forum.com/t/stream-tags/204901/1 "2011-03-24T11:31:33Z")
Hi, I’ve tried the new stream tags and like them, but when I’ve a block in my flowgraph that change the stream rate I’m not sure how the absolute sample number is calculated. Consider the flowgraph below where B0, B1 and B4 are gr\_sync\_block and B2 is a gr\_block that increases the stream rate in the flowgraph. B0 -\> B1 -\> B2 -\> B4 If I set tags on sample 0 and 200 in block B0 and check the tags in block B1 everything is correct, I find them at sample 0 and 200. But if I check the tags in block B4 I find them at 0 and 400 while I expected to find them on 0 at 527. The B2 block consumes 200 samples and produces 527 samples, this is a rate of 2.635 and the tag absolute sample number is increased by a ratio of 2. How is the absolute sample number calculated? I found that it is possible to change the policy of how the tags propagate between blocks. My default setting was TPP\_ALL\_TO\_ALL. When I changed it to TPP\_ONE\_TO\_ONE I got the following error “gr\_block\_executor: propagation\_policy ‘ONE\_TO\_ONE’ requires ninputs == noutputs”, I tested it on the flowgraph above. With the TPP\_ONE\_TO\_ONE policy, shouldn’t the tags only propagate from B0 to B1? BR, Patrik E. ---
**Author:** ![Patrik\_E](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7c8e57/32.png) [@Patrik\_E](https://www.ruby-forum.com/u/Patrik_E)\ **Post date:** [March 25, 2011, 4:38pm UTC](https://www.ruby-forum.com/t/stream-tags/204901/2 "2011-03-25T16:38:39Z")
On Thu, Mar 24, 2011 at 6:29 AM, Patrik E. \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > wrote: > If I set tags on sample 0 and 200 in block B0 and check the tags in block > B1 everything is correct, I find them at sample 0 and 200. But if I check > the tags in block B4 I find them at 0 and 400 while I expected to find them > on 0 at 527. The B2 block consumes 200 samples and produces 527 samples, > this is a rate of 2.635 and the tag absolute sample number is increased by a > ratio of 2. How is the absolute sample number calculated? Patrik, glad you’ve gotten into using the stream tags. To answer your question, the sample numbers are changed based on the relative rate you set for your block. When you use a gr\_sync\_decimator with a decimation rate of D, the relative\_rate of that block is set in the constructor to be 1.0/(float)D. Likewise, when using a gr\_sync\_interpolator, the relative rate is set to (float)I. When a stream tag is passed between blocks, the schedule looks at the relative rate, and if it is not 1.0, it will adjust the value by multiplying by relative\_rate. It strikes me that possible block B2 is having its relative\_rate set incorrectly. It could be a casting problem that has truncated the math to 2 instead of 2.635. You can ask a block it’s rate with relative\_rate() to see what it thinks its rate is. > I found that it is possible to change the policy of how the tags propagate > between blocks. My default setting was TPP\_ALL\_TO\_ALL. When I changed it to > TPP\_ONE\_TO\_ONE I got the following error “gr\_block\_executor: > propagation\_policy ‘ONE\_TO\_ONE’ requires ninputs == noutputs”, I tested it > on the flowgraph above. With the TPP\_ONE\_TO\_ONE policy, shouldn’t the tags > only propagate from B0 to B1? Yes, you are correct in how it should work, so I can’t say why it is failing. Basically, if you have a graph with a single path, then TPP\_ALL\_TO\_ALL should function the same as TPP\_ONE\_TO\_ONE. The differences occur when you have multiply inputs and multiply outputs. For example, a block with 1 in and 2 outs will not work with TPP\_ONE\_TO\_ONE, but with TPP\_ALL\_TO\_ALL, all tags appearing on input(0) will be sent to output(0) and output(1). The TPP\_ONE\_TO\_ONE says that if you have 2 inputs and 2 outputs, then tags flow: input(0) → output(0) input(1) → output(1) While the TPP\_ALL\_TO\_ALL would send this: input(0) → output(0) input(0) → output(1) input(1) → output(0) input(1) → output(1) We have code that checks both cases out, but either something is wrong or not obvious in your case. If you can provide more details about what you are doing, we can work to track this down. BR, > Patrik E. Thanks! Tom ---
**Author:** ![Patrik\_E](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7c8e57/32.png) [@Patrik\_E](https://www.ruby-forum.com/u/Patrik_E)\ **Post date:** [March 29, 2011, 9:06am UTC](https://www.ruby-forum.com/t/stream-tags/204901/3 "2011-03-29T09:06:24Z")
On Thu, Mar 24, 2011 at 6:29 AM, Patrik E. \ wrote: Hi, I’ve tried the new stream tags and like them, but when I’ve a block in my flowgraph that change the stream rate I’m not sure how the absolute sample number is calculated. Consider the flowgraph below where B0, B1 and B4 are gr\_sync\_block and B2 is a gr\_block that increases the stream rate in the flowgraph. B0 → B1 → B2 → B4 If I set tags on sample 0 and 200 in block B0 and check the tags in block B1 everything is correct, I find them at sample 0 and 200. But if I check the tags in block B4 I find them at 0 and 400 while I expected to find them on 0 at 527. The B2 block consumes 200 samples and produces 527 samples, this is a rate of 2.635 and the tag absolute sample number is increased by a ratio of 2. How is the absolute sample number calculated? Patrik, glad you’ve gotten into using the stream tags. To answer your question, the sample numbers are changed based on the relative rate you set for your block. When you use a gr\_sync\_decimator with a decimation rate of D, the relative\_rate of that block is set in the constructor to be 1.0/(float)D. Likewise, when using a gr\_sync\_interpolator, the relative rate is set to (float)I. When a stream tag is passed between blocks, the schedule looks at the relative rate, and if it is not 1.0, it will adjust the value by multiplying by relative\_rate. It strikes me that possible block B2 is having its relative\_rate set incorrectly. It could be a casting problem that has truncated the math to 2 instead of 2.635. You can ask a block it’s rate with relative\_rate() to see what it thinks its rate is. Thanks Tom! I found it in the source code how the sample number was calculated. The problem I had was that my relative rate was casted to 2 instead of being the float value, just as you said. I found that it is possible to change the policy of how the tags propagate between blocks. My default setting was TPP\_ALL\_TO\_ALL. When I changed it to TPP\_ONE\_TO\_ONE I got the following error “gr\_block\_executor: propagation\_policy ‘ONE\_TO\_ONE’ requires ninputs == noutputs”, I tested it on the flowgraph above. With the TPP\_ONE\_TO\_ONE policy, shouldn’t the tags only propagate from B0 to B1? Yes, you are correct in how it should work, so I can’t say why it is failing. Basically, if you have a graph with a single path, then TPP\_ALL\_TO\_ALL should function the same as TPP\_ONE\_TO\_ONE. The differences occur when you have multiply inputs and multiply outputs. For example, a block with 1 in and 2 outs will not work with TPP\_ONE\_TO\_ONE, but with TPP\_ALL\_TO\_ALL, all tags appearing on input(0) will be sent to output(0) and output(1). The TPP\_ONE\_TO\_ONE says that if you have 2 inputs and 2 outputs, then tags flow: input(0) → output(0) input(1) → output(1) While the TPP\_ALL\_TO\_ALL would send this: input(0) → output(0) input(0) → output(1) input(1) → output(0) input(1) → output(1) We have code that checks both cases out, but either something is wrong or not obvious in your case. If you can provide more details about what you are doing, we can work to track this down. Okey, propagation policy was not as I first thought! I was thinking about how to limit the number of blocks that the stream tags would propagate to. As it is now the stream tags is visible in all blocks in the flowgraph. Is it possible to introduce some function like consume\_stream\_tag(stream\_tag) that ensures that a certain stream tag would not propagate further. Or some policy for tags that the stream tag should only propagate X blocks down stream? It was just a thought… The reason why I got the error with TPP\_ONE\_ONE is that I have a block down streams that doesn’t use stream tags but have 1 inputs and 2 outputs. BR, Patrik E. Thanks! Tom ---
**Author:** ![Patrik\_E](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7c8e57/32.png) [@Patrik\_E](https://www.ruby-forum.com/u/Patrik_E)\ **Post date:** [March 29, 2011, 5:26pm UTC](https://www.ruby-forum.com/t/stream-tags/204901/4 "2011-03-29T17:26:05Z")
On Tue, Mar 29, 2011 at 3:05 AM, Patrik E. \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > wrote: > > > > relative rate, and if it is not 1.0, it will adjust the value by multiplying > instead of being the float value, just as you said. Great! Glad you got it. I found that it is possible to change the policy of how the tags propagate > occur when you have multiply inputs and multiply outputs. For example, a > input(0) → output(0) > As it is now the stream tags is visible in all blocks in the flowgraph. Is > it possible to introduce some function like consume\_stream\_tag(stream\_tag) > that ensures that a certain stream tag would not propagate further. Or some > policy for tags that the stream tag should only propagate X blocks down > stream? It was just a thought.. > > The reason why I got the error with TPP\_ONE\_ONE is that I have a block down > streams that doesn’t use stream tags but have 1 inputs and 2 outputs. We discussed that, but the solution that we came up with is to use a third policy (the TPP stands for tag propagation policy), which is TPP\_DONT. If you create a block that uses this policy, it does not pass on any tags. Instead, if you want to pass on tags, you basically have to do it yourself. It’s really the opposite of what you are saying: instead of cherry-picking to remove tags, you cherry-pick which tags to continue to propagate. I’m willing to entertain the idea of creating a method to remove tags from the list, but I’ll have to think about it some. Largely, there isn’t much of a body of work built up that uses these tags, yet, so we implemented it one way under some assumptions about their uses. Mainly, we said that there won’t be that many tags overall, so it’s easy enough to pick which ones to propagate if you are a TPP\_DONT block. That said, as you and others use the tags in other ways and build up some working knowledge about what you want to do with them, we can review these kinds of things. Thanks, Tom