[USRP-users] time_spec_t GPS Time or UTC?

Ian Buckley ianb at ionconcepts.com
Wed Dec 10 18:21:21 EST 2014


OK, I agree that the term 'time spec' is getting a little overloaded here w.r.t that documentation.

The background to this is that internally to the USRP H/W, time is counted with different quanta based on what the actual sample rate pass to/from the ADC/DAC is.
Thus time_spec_t exists to provide a device independent representation of time counted in seconds and fractions of seconds.

When power is applied to the actual USRP's, each will start counting time immediately from an initial value of 0. This is the default unless you choose to do something explicitly to re-write the current time (set_time_*). If an internal GPSDO is present then during boot, after the GPSDO starts emitting NMEA strings UHD will extract a UTC coordinated time and use the PPS signal to accurately transfer that time to the USRP in a one-time operation. UHD won't however then continue to make sure that the USRP continues to track UTC time, the golden time reference in the system is that incrementing value in the USRP, so your application should create all time specs (as time_spec_t!) to schedule events relative to that internal USRP counter and not some independant external source of UTC time at some point in the future (since I guess it could drift due to some rare calendar correction event).


So the "reference" when reading docs should always be assumed to be the value of that internal USRP time counter. Make sense?


On Dec 10, 2014, at 2:42 PM, Peter Witkowski <pwitkowski at gmail.com> wrote:

> 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 list
>>> 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
>> 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/9cd7b248/attachment-0002.html>


More information about the USRP-users mailing list