Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink

[Josh Blum]

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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>