Test_corr_and_sync example

GNU Radio
1

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 (5sps vs 11sps). 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

2

On Tue, Mar 3, 2015 at 5:30 PM, Richard B. [email protected]
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 (5sps vs 11sps). 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