Re: [Discuss-gnuradio] Tags through Rate Change Blocks

[Richard Bell]

Tom,

Yes I will give that a try and get back to you.

Rich

On Tue, Jan 26, 2016 at 1:14 AM, Tom Rondeau <address@hidden> wrote:

On Mon, Jan 25, 2016 at 2:32 PM, Richard Bell <address@hidden> wrote:

Hi all,

It's been a while since I've seen discussion on this. I'm interested to know if this is still a non-deterministic problem or if there is a workaround?

For those not familiar, in the past you could either lose a tag completely through a rate change block or the location of the tag could be in the wrong place at the output of the rate change.

For me right now, I've narrowed a system issue down to tags coming out of the Polyphase Clock Sync block being off by 1 on occasion. Most of the time the tag is in the right spot, but not always. The tags are placed into the stream by the Correlation Estimator block, and they are always in the same place. It is only at the output of the Clock Sync block that the tag moves to the wrong spot, which is a rate change block.

My workaround is to use a second correlator after the clock sync block to generate another tag once all rate changes are completed.

A lot of words sorry, I'm just interested to know the current state of affairs regarding this.

Rich

Rich,

You might be just the guy I was looking for. I have a branch which I believe solves this issue:

https://github.com/trondeau/gnuradio/tree/tags_and_rate_changing_blocks

There are four commits that I think should explain the issue. Basically, the relative_rate used to update the tag placement changes /within/ work, so a single value after work can never be correct for all tags. This now moves the tags itself during work. Can you try this and see what your results are?

I'm afraid it'll likely add a bit more overhead to these blocks. But on the other hand, the behavior being right here is more important.

Tom