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 v/r, Rich On Thu, Apr 23, 2015 at 7:23 AM, Tom Rondeau <t...@trondeau.com> wrote: > On Wed, Apr 22, 2015 at 11:17 PM, Nick Foster <bistrom...@gmail.com> > 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. >> >> --n >> >> On Wed, Apr 22, 2015 at 4:29 PM, Richard Bell <richard.be...@gmail.com> >> 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. >>> >>> v/r, >>> Rich >>> >> > > 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. > > Tom > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
