Detecting underflows with uhd_usrp_sink

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).

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?

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.

juha

On 06/08/2013 02:26 PM, Juha V. 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

L = late packet, there was a time on the packet which was> time on
device when

There are two different “cases” for late packets happening.

The first is that you haven’t sent your packet far enough in advance to
account for latency variations on the host. Unfortunately, on a
general-purpose
OS like Windows or Linux, latency variability can be extreme, and for
long-running flow-graphs you might need to develop a good model to
determine
what the worst-case is and account for that.

The second is that the clock on the USRP and the clock on the host will
tend to drift apart over time, particularly if both of them are “free
running”.
So when you schedule timed bursts far enough in advance during the
start of a “session”, it’s entirely possible that after quite some time,
the
two clocks have drifted apart unfavourably in terms of allowing you
to schedule things far enough in advance, relative to the USRP clock.
PC clocks are terrible by themselves. They’ll drift significant
fractions of a second on a daily basis without any outside steering.
The USRP
clock, even free-running, is typically much, much better.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium