On 06/08/2013 02:26 PM, Juha Vierinen wrote: > Hi, > > I've recently been working with a coded CW radar system that just loops > over a fairly long IQ vector. It works all fine for a while, but after a > few days, the transmission timing has drifted away from where it should be. > I'm comparing the leading edge of the transmit waveform with the PPS > provided to the USRP to detect drifting of the waveform. I'm wondering what > could cause this. While the drifting occurs both when I see the letters U > and L, and sometimes when I don't see them at all (this is correlated with > the GPSDO losing lock).
U = underflow (not fed enough samples to device which causes a gap in transmit) L = late packet, there was a time on the packet which was > time on device when > > First of all, is there any way to ask the uhd_usrp_sink if there have been > overflows or underflows that cause a need for resyncronizing? There is actually an async usrp block in gr-uhd that can post these indications to a gr msg queue. > > Second, what would be the optimal method to implement a continuously > repeating IQ vector fed to a uhd_usrp_sink block that needs to stay in > sync? On receive, sample counting works, so I would assume this to be the > case also on receive. > Perhaps you could react to the async indications and reset some upstream logic. -josh > juha > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
