[USRP-users] time_spec_t GPS Time or UTC?

Peter Witkowski pwitkowski at gmail.com
Wed Dec 10 17:42:57 EST 2014


Hi Ian,

I understand that time_spec_t is relative to whatever I make it relative
to.  I can have it start at my birthday, midnight yesterday, the time at
which I had to take my first aspirin (due to dealing with the UHD API), etc.

In terms of implementation with the API, I'm concerned with four function
calls (as I outlined in my original e-mail).  For example, when I receive a
rx_metadata_t structure back from a recv() call to bring data into my
application, what does that time_spec_t represent?  Similarly, I want to
set a start time in a stream_cmd_t structure (which has a time_spec_t
inside of it), what time reference am I working with there?  Certainly this
is not arbitrary or whatever I decide because the USRP has to understand
what I'm sending it.

To highlight my frustration, this is what the documentation says about
time_spec_t as it relates to issue_stream_cmd():

"The stream now parameter controls when the stream begins. When true, the
device will begin streaming ASAP. When false, the device will begin
streaming at a time specified by time_spec."

No where it is defined how to set time_spec or if this time is absolute or
relative.  Let's say I pass in a value of 3.  How does the USRP react?

On Wed, Dec 10, 2014 at 5:24 PM, Ian Buckley <ianb at ionconcepts.com> 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.
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141210/a071650c/attachment-0002.html>


More information about the USRP-users mailing list