# Test\_corr\_and\_sync example

**URL:** <https://www.ruby-forum.com/t/test-corr-and-sync-example/234424>\
**Category:** GNU Radio\
**Created:** [March 3, 2015, 11:31pm UTC](https://www.ruby-forum.com/t/test-corr-and-sync-example/234424 "2015-03-03T23:31:20Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\
**Post date:** [March 3, 2015, 11:31pm UTC](https://www.ruby-forum.com/t/test-corr-and-sync-example/234424/1 "2015-03-03T23:31:20Z")

</div>

Hi all,

I’m trying to figure out what the test\_corr\_and\_sync example (located  
…/src/gnuradio/gr-digital/examples/demod/test\_corr\_and\_sync.grc) is  
showing me. I see the tags added by the correlator, but they seem to  
jump  
around a bit. If I add some timing offset with the slider, I don’t see  
much  
relation to that and the time\_est tag value. I can’t find any  
correlation  
between the four sliders and any of the tag values.

I also see the constellation being smeared out considerably. It looks to  
me  
like the rrc\_taps variable might be set incorrectly. The number of taps  
portion of the filter does not match the constellation modulator number  
of  
taps (5_sps vs 11_sps). Though changing this to what I believe is  
correct  
does not help the smear all that much. Shrug.

If this is working as intended, what net effect does this have on the  
pfb\_sync and costas filters? Is it a considerable boost in sync  
performance?

Thanks,  
Rich

---

<div class="post-metadata">

**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\
**Post date:** [March 4, 2015, 5:23pm UTC](https://www.ruby-forum.com/t/test-corr-and-sync-example/234424/2 "2015-03-04T17:23:42Z")

</div>

On Tue, Mar 3, 2015 at 5:30 PM, Richard B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> me like the rrc\_taps variable might be set incorrectly. The number of taps  
> portion of the filter does not match the constellation modulator number of  
> taps (5_sps vs 11_sps). Though changing this to what I believe is correct  
> does not help the smear all that much. Shrug.
> 
> If this is working as intended, what net effect does this have on the  
> pfb\_sync and costas filters? Is it a considerable boost in sync performance?
> 
> Thanks,  
> Rich

The constellation “smearing” is partly some noise, partly some ISI, but  
mostly still settling issues of the loops.

But yes, the correlate\_and\_sync block makes a huge difference on the  
lock-in time of these blocks. Tracking loops aren’t great when you have  
burst signals like this, since they go off into the weeds when there’s  
not  
signal to track, so the start of each burst forces them to reacquire.  
The  
correlate\_and\_sync provides a good hint to the state they should be in,  
which gets them close, but they still need time to settle properly.  
Also,  
since the information is valid only at the correlation peak, which  
occurs  
at the end of the access code it’s correlating against, but I think that  
the constellation might be showing the entire packet including the  
access  
code, you’re seeing two parts of the packet in that display: the  
synchronized payload and the unsynchronized access code. The upper  
left-hand corner display shows you the received samples in time, and you  
can see some of the effects that occur there that would lead to the  
smearing.

Tom