On Mon, Dec 16, 2013 at 11:21 AM, bob wole <bnw...@gmail.com> wrote: > 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? > > -- > 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
