[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Correlation Estimation Block Oddity

From: Richard Bell
Subject: Re: [Discuss-gnuradio] Correlation Estimation Block Oddity
Date: Thu, 23 Apr 2015 15:38:38 -0700

I have another question on tag placement for the correlation estimation block. In the screenshot I've attached, you'll see that the corr_start tag is placed well before the preamble actually starts. If I use the 'delay tag' field to move it to the end of the preamble where I need it, it stops delaying, no matter how big I make the delay, before it reaches the end of the preamble. This is shown in the picture. I need this tag to denote the start of the header for the Header Payload Demux block.

My question is, given the situation in the screenshot, is there a way I can delay just the tag in grc using a block? I'm not sure how to get the tag positioned where I need it at this point.

Help is greatly appreciated



On Thu, Apr 23, 2015 at 7:23 AM, Tom Rondeau <address@hidden> wrote:
On Wed, Apr 22, 2015 at 11:17 PM, Nick Foster <address@hidden> wrote:
Short answer: use corr_est as your tag. The corr_start tag is undelayed by the matched filter length, and intended for other purposes (data-aided equalizers, etc.). Andy Walls can say more, but it's enough to say the later three tags are the ones that match the peak of the correlation in the output symbol stream. See corr_est_cc_impl.cc lines 206-214.


On Wed, Apr 22, 2015 at 4:29 PM, Richard Bell <address@hidden> wrote:
Hello all,

I'm using GR 3.7.8. I'm trying to work the new Correlation Estimation block into my design. I'm seeing what looks like unintended behavior for the tag placements. Sometimes the corr_start tag is placed on the same sample as the corr_est, time_est and phase_est tags, but sometimes the corr_start tag is placed a sample earlier then those three tags.

I've attached a screenshot showing this behavior. In the same running flow graph the tag placement will go back and forth between being on the same sample or being off by one sample. As long as the corr_start tag is always on the correct sample I guess this won't break anything, but I figured I'd let you all know what I'm seeing.

I don't have the full design working yet so I can't say myself that the block works.


Aside from what Nick said, another issue that we've seen in the scheduler is propagation of tags through blocks that have changing sample rates. The clock sync blocks (either the PFB or M&M) for example don't have a strict N:M input to output ratio, but can have N:M+/-d depending on the state of the signal. Jeff Long and I worked out a mediocre solution to help with this, but it's not perfect and we can still see the problem occurring on occasion. Generally, this settles down quickly and provides a constant offset of where the tag is relative to where it really should be, and it might move plus or minus 1 sample every now and then. The corr_est block has the "Tag marking delay" which among other reasons can also help with this problem.

The problem that I'm referring to doesn't seem to have a simple answer, either, and I've challenged a few people who are good at this sort of thing to try and sort it out, but we still don't have a solution. The "good enough" solution that's in there so far has indeed proved to be good enough for most purposes.


Attachment: tag position.png
Description: PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]