[USRP-users] time_spec_t GPS Time or UTC?

Perelman, Nathan nperelman at LGSInnovations.com
Wed Dec 10 15:32:54 EST 2014


The time returned via get_mboard_sensor(“gps_time”) will be UTC already (assuming the GPSDO is locked). The GPSDO corrects for leap seconds. If you look up the GPRMC string, you can see that the time/date given are UTC.

-Nathan

 

From: USRP-users [mailto:usrp-users-bounces at lists.ettus.com] On Behalf Of Marcus D. Leech via USRP-users
Sent: Wednesday, December 10, 2014 3:18 PM
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] time_spec_t GPS Time or UTC?

 

On 12/10/2014 03:10 PM, Peter Witkowski via USRP-users wrote: 

Hello,

I have a question regarding the time reference used by the USRP (namely the x300).

If I call the following UHD API functions (see list below), what time reference is used (GPS or UTC)?  Does the USRP itself handle leap seconds and the delta between Unix time and the time it's getting from it's GPS receiver (assuming a GPSDO is installed and locked)?

1.  When I specify the time_spec_t value in issue_stream_cmd(), what time reference is the USRP expecting?  For example, do I pass it seconds after epoch (Unix time) or something else?

2. When I get time via get_time_last_pps(), what is the time reference?

3. Same question as above except for retrieving time via get_mboard_sensor("gps_time").

4.  When I get samples from the sensor using recv(), what time reference is used for the time_spec_t timestamp in the rx_metadata_t structure?  I understand that is the timestamp of the first sample, but is the timestamp seconds after epoch (i.e. Unix time) or based on something else?

Just wondering if I need to worry about translating between GPS seconds and Unix seconds or something similar.

Thanks in advance for the help.



-- 

Peter Witkowski
pwitkowski at gmail.com

 
 
_______________________________________________
USRP-users mailing list
USRP-users at lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

The USRP doesn't actually care, or know, about epoch-based time systems.   The TOD clock in USRPs is just a wide counter that increments at
  the master clock rate.

The only requirement in most cases is that everybody in a collection of USRPs agrees on the interpretation of time.  The gps_time returned in the
  sensor is just parsed from the NMEA data, as far as I know, without any further manipulation to make it consistent with (for example) Unix epoch
  time or any other time system.

In many cases, applications that don't care about time-as-it-relates-to-the-rest-of-the-world, they load the TOD registers in a cluster of USRPs
  with 0, so that the TOD clock becomes kind of a "mission elapsed timer".






-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141210/1f8f2152/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4327 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141210/1f8f2152/attachment.p7s>


More information about the USRP-users mailing list