[USRP-users] Still problems with USRP time from GPSDO

Josh Blum josh at ettus.com
Tue Apr 30 14:53:44 EDT 2013

> GPS Locked
> USRP Locked to GPSDO 10 MHz Reference.
> GPS and UHD Device time are NOT aligned. Try re-running the program. Double
> check 1 PPS connection from GPSDO.
> Printing available NMEA strings:
> $GPGGA,131823.00,3206.7878,N,3448.4199,E,2,09,1.0,59.3,M,17.6,M,,*6B
>  PS_GPRMC: $GPRMC,131824.00,A,3206.7878,N,3448.4199,E,0.3,0.0,300413,,*01
> GPS epoch time: 1367327902 seconds
> UHD Device time: 1367327902 seconds

So, notice the times 1367327902 are the same, but you see the error
above. Thats actually a floating point rounding thing where the
fractional seconds are nominally one. This check was a simple one line
fix for this app, so its nothing to worry about:


> Done!
> 1367327904

Is this print 1367327904 the result of time(NULL)? If so, I think some
of the extra time comes from the fact that GPGGA and GPRMC are queried
after the time is read and before the time is printed. This may account
for one second, even two -> since the messages are scheduled to come
form the gpsdo @ PPS.

Now in another email it looked like the utc time on your system may have
been one second off:

> usrp->get_time_now(): 1367237083:0.517574
> usrp->get_time_last_pps():  1367237082:1.000000
> metadata time stamp of recent RX samples:   1367237083:0.510384
> utime() on Linux:   1367237084:0.517167

So it looks like there is perhaps a difference of about 1 second in the
time reported by UTC PC clock vs GPRMC value from the GPSDO. I cant say
that I have seen this. Could you perhaps run the same app but with this
code from the master branch? It has the UTC time print added. I wonder
if there is a one second offset in this case as well...



More information about the USRP-users mailing list