[USRP-users] time_spec_t GPS Time or UTC?

Marcus D. Leech mleech at ripnet.com
Wed Dec 10 19:13:48 EST 2014


On 12/10/2014 06:05 PM, Peter Witkowski wrote:
> Hi Marcus,
>
> Thanks for this.
>
> To reiterate (and correct me if I'm wrong), in the general case, 
> system time on the USRP is totally arbitrary.  With a GPSDO attached, 
> the system time synchronizes to UTC via NMEA messaging from the GPSDO 
> and counts seconds after Unix epoch (basically it's just Unix system 
> time at this point).
>
> I'm assuming that any time_spec_t value passed to/from the USRP must 
> as a result follow this reference.  Sure there are applications that 
> can use an arbitrary clock, but for the GPSDO case, the time_spec_t 
> values I pass to/from the USRP should be Unix system time.
>
> Note that my understanding of GPS (and I could be wrong here) is that 
> the satellite broadcasts include the information necessary to convert 
> from GPS time to UTC time.  Therefore, the GPSDO should be able to 
> stay true to UTC in it's internal conversions from GPS time to UTC time.
>
> As a result, it might be a little misleading calling the sensor name 
> "gps_time" since it's using UTC as a reference and not actual GPS time.
Perhaps "gps_time_referenced_to_UTC_and_made_Unixy" would be a better 
sensor name, but somewhat long.

It was felt that having the TOD clock on the USRP, when you have a GPSDO 
produce time, that is consistent with what a time_t on the host
   (from, perhaps, a time(&time_t)) would contain was important for a 
lot of applications.   But it was also felt that the TOD clock hardware 
shouldn't
   actually "know" anything about calendar time.  That allows 
applications that have no notion (nor care about) calendar time, but 
just want all boxes
   to have a common notion of time when they start streaming--there are 
many such applications.

In fact, applications where the ability to reference some specific 
sample timestamp, to a time as seen by some unrelated observer who uses 
conventional
   calendar time, are probably a smaller population than those who 
simply require that all the USRPs "agree among themselves".




>
> On Wed, Dec 10, 2014 at 5:43 PM, Marcus D. Leech <mleech at ripnet.com 
> <mailto:mleech at ripnet.com>> wrote:
>
>     On 12/10/2014 05:24 PM, Ian Buckley wrote:
>>     time_spec_t is nothing more than a container for a highly
>>     accurate count of seconds and fractions there of. It measures
>>     from no reference …that entirely down to you to decide what
>>     seconds is relative to.
>>     The USRP doesn't care about calendars, if you set time from a UTC
>>     coordinated source and then an event like a leap second occurs
>>     then the USRP will no longer be coordinated with UTC.
>     Also, in addition:
>
>     http://files.ettus.com/manual/page_gpsdo.html
>
>     The "gps_time" sensor will return a format suitable for use as a
>     Unix epoch time, and that is what the TOD registers in the USRP
>     will be initialized to
>       automatically when you have a built-in GPSDO.
>
>     But, like Ian says, the TOD registers and logic in the USRP know
>     nothing of Gregorian calendars, etc.   A time_spec_t of '0' is
>     interpreted however
>       you want to interpret it, although the Unix epoch-time is
>     certainly convenient, and that's what it gets set to when you have
>     a GPSDO, and what
>       the "gps_time" sensor returns, and what the
>     uhd::time_spec_t::get_system_time() method will return on POSIX
>     systems, the hardware really
>       doesn't care.  It just takes whatever is stuffed in there
>     initially, and just keeps incrementing  it at an appropriate
>     rate.  If you call the get_time_now()
>       uhd::multi_usrp method it will return a time_spec_t, upon which
>     you can call get_ful_secs(), which will be a time_t.  If the USRP
>     has been initialized
>       with a Unix-epoch type time, then that time_t should correpond
>     to Unix-epoch time.
>
>
>
>
>
>>
>>     On Dec 10, 2014, at 1:37 PM, Peter Witkowski via USRP-users
>>     <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>>
>>     wrote:
>>
>>>     Hi Marcus,
>>>
>>>     I've looked at the documentation (prior to sending my original
>>>     mailing list message) and am still lost.  Let me rephrase my
>>>     question.  Since time_spec_t just holds a seconds count, when
>>>     did the count start (assuming the USRP is synched to UTC via the
>>>     GPSDO)?  Restated once more, if I get back 0, what time is it?
>>>
>>>     I'm assuming that once synched, the USRP is just using seconds
>>>     after Unix epoch (this would be logical), but would like to
>>>     confirm this.
>>>
>>>     On Wed, Dec 10, 2014 at 4:11 PM, Marcus D. Leech via USRP-users
>>>     <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>>
>>>     wrote:
>>>
>>>         On 12/10/2014 04:02 PM, Peter Witkowski via USRP-users wrote:
>>>>         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.
>>>>
>>>         http://files.ettus.com/manual/classuhd_1_1time__spec__t.html#a2bd6c4c8ad7209d219c3ca5ae238fb6e
>>>
>>>
>>>
>>>
>>>>         On Wed, Dec 10, 2014 at 3:32 PM, Perelman, Nathan via
>>>>         USRP-users <usrp-users at lists.ettus.com
>>>>         <mailto: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
>>>>             <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
>>>>             <mailto: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 <mailto:pwitkowski at gmail.com>
>>>>
>>>>               
>>>>
>>>>               
>>>>
>>>>             _______________________________________________
>>>>
>>>>             USRP-users mailing list
>>>>
>>>>             USRP-users at lists.ettus.com  <mailto: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  <http://www.sbrac.org/>
>>>>
>>>>
>>>>             _______________________________________________
>>>>             USRP-users mailing list
>>>>             USRP-users at lists.ettus.com
>>>>             <mailto:USRP-users at lists.ettus.com>
>>>>             http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>>
>>>>
>>>>         -- 
>>>>         Peter Witkowski
>>>>         pwitkowski at gmail.com <mailto:pwitkowski at gmail.com>
>>>>
>>>>
>>>>         _______________________________________________
>>>>         USRP-users mailing list
>>>>         USRP-users at lists.ettus.com  <mailto:USRP-users at lists.ettus.com>
>>>>         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>         _______________________________________________
>>>         USRP-users mailing list
>>>         USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>>>         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>>
>>>     -- 
>>>     Peter Witkowski
>>>     pwitkowski at gmail.com <mailto:pwitkowski at gmail.com>
>>>     _______________________________________________
>>>     USRP-users mailing list
>>>     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>>>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
>
> -- 
> Peter Witkowski
> pwitkowski at gmail.com <mailto:pwitkowski at gmail.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141210/24d51fe2/attachment-0002.html>


More information about the USRP-users mailing list