I installed a fresh verison of gnuradio 3.7.2.1 and was testing some of
the
new features including the “correlate and sync”- A must from burst
modems.
I am using the “test_corr_and_sync.grc” example. Constellation and rest
of
the output looks fine. However, when I plot the “phase” output of
“polyphase clock sync” its look like during burst time phase does not
get
lock. Phase output just keep on changing, please see the attached
picture
of phase output. Well, real performance test should include a packet
encoder and decoder etc to evaluate BER. But before trying that I
thought I
should try the example that comes with gnuradio, is the phase
outputlooks
ok?
On Mon, Dec 16, 2013 at 11:21 AM, bob wole [email protected] wrote:
–
Bob
Yeah, that actually looks fine to me. It definitely wiggles around a
few states of phase due to the step size response to the error
function. You can possibly turn down the loop bandwidth of this block
to see it reduced even farther. With the initial hint of from the
correlate_and_sync block, it might still converge fast enough to be
useful. And don’t get confused by those spikes. That’s just wrapping
from filter 0 to filter 31 and back; those are only different by
2pi/32 radians.
Then again, I could be wrong and someone might be able to provide a
patch that helps this converge even more.
What I have done with this instead of a full-on packet encoder/decoder
(which I agree would be useful) is just plot the received bits and
appropriately-delayed input bits against each other (or subtracting
one stream from another) to see that they match. With real hardware in
the loop, the delays change and I wasn’t doing anything so clever as
correlating to find the offset; I would just tune the delay by hand.
The intent was not to get a real BER but to make sure that it wasn’t
completely misbehaving.
Tom