[USRP-users] time_spec_t GPS Time or UTC?

Peter Witkowski pwitkowski at gmail.com
Wed Dec 10 16:02:45 EST 2014


Thanks for the info thus far.  That explains a lot and at least I know I
don't have to worry about conversions from UTC to GPS time.

So now that it looks like the USRP is using UTC, when I get a time_spec_t
structure back from it (or pass it one as a start time in
issue_stream_cmd()), what does the time_spec_t structure hold?  UTC seconds
after Unix epoch or something else entirely?

Note all this assumes that the GPSDO is working properly and locked.

On Wed, Dec 10, 2014 at 3:32 PM, Perelman, Nathan via USRP-users <
usrp-users at lists.ettus.com> wrote:

> 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
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>


-- 
Peter Witkowski
pwitkowski at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141210/f42d14ba/attachment-0002.html>


More information about the USRP-users mailing list