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

Marcus D. Leech mleech at ripnet.com
Mon Apr 29 17:01:17 EDT 2013

On 04/29/2013 04:55 PM, Josh Blum wrote:
> On 04/29/2013 03:51 PM, Marcus D. Leech wrote:
>> On 04/29/2013 04:08 PM, Josh Blum wrote:
>>> On 04/29/2013 01:56 PM, Sean Nowlan wrote:
>>>> On 04/29/2013 02:37 PM, Josh Blum wrote:
>>>>> Can I ask what version of UHD you are running? A few weeks ago I
>>>>> fixed a
>>>>> bug on the master branch related to GPSDO time,
>>>> Hi Josh, can you point me to that commit? was it just a fix to
>>>> query_gpsdo_sensors or something in the driver/gpsdo control code?
>>> It was a fix to the gpsdo control code:
>>> https://github.com/EttusResearch/uhd/commit/31f0e964aa54a2c8e4d299432513623d2c49bbf0
>>> -josh
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> Is it not the case that GPS time is strictly-linear, whereas UTC (which
>> is what is carried by NTPD) has leap-second compensation.   Or do the GPSDO
>>    units produce a leapsecond-corrected timestamp?
> The time in seconds in the GPGGA string as reported by the GPSDO unit is
> UTC time. So it should match the PC clock to the second. However, the
> GPS time is actually about 16 seconds off compared to UTC because it
> doesnt adapt with leap seconds.
> -josh
Here are some interesting notes with respect to GPS time-keeping 
functions on typical recievers, vs UTC (as delivered by NTPD).  Now, this
   makes me wonder how GPSD on Linux deals with this.


Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

More information about the USRP-users mailing list