[USRP-users] time_spec_t GPS Time or UTC?

Peter Witkowski pwitkowski at gmail.com
Wed Dec 10 20:02:41 EST 2014


Marcus/Ian,

Thanks for the help.  I follow now.

I agree that the end goal (for most applications) isn't calendar time, it's
just so that multiple USRPs are all clocked together (regardless of what "0
seconds" means).  It just a coincidence with the GPSDO that this clock is
seconds after epoch (Unix time).

Thanks again for the assistance.

On Wed, Dec 10, 2014 at 7:13 PM, Marcus D. Leech <mleech at ripnet.com> wrote:

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


-- 
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/9548041e/attachment-0002.html>


More information about the USRP-users mailing list