[USRP-users] Synchronisg GPS and PPS

Michael West michael.west at ettus.com
Mon Oct 5 15:48:57 EDT 2015


Hi Sivan,

We appreciate your comments on the matter.  Ettus engineering has received
them.  Having an example of how to set the time to the GPS time is
definitely a good idea.  We may add it in a future release.  The code
around the GPSDO has been evolving over time and your frustration over the
change in behavior is understandable.  We do our best to make sure any
significant changes are included in the release notes, but this one just
got by us due to the large number of other changes made between 3.8.x and
3.9.x.

I'm glad you got it all working.  As you have discovered, the NMEA
sentences are cached by UHD and considered "fresh" for 1 second since they
are produced once a second.  As you have also discovered, there is an issue
where the start time of the "freshness" begins when there is a query for
the string and not when the string is actually produced.  This means that
there must be a minimum of 1 second between queries to guarantee the string
is accurate.

Until we have a formal example available, here is example code that should
work to set the device time to the GPS time:
    for (uhd::time_spect_t t = usrp->get_time_last_pps(); t ==
usrp->get_time_last_pps();) {}    // wait for PPS edge
    boost::this_thread::sleep(boost::posix_time::milliseconds(200));    //
sleep to allow NMEA string to propagate
    uhd::time_spec_t next_gps_time =
uhd::time_spec_t(usrp->get_mboard_sensor("gps_time").to_int()+1);  // get
the GPS time
    usrp->set_time_next_pps(next_gps_time);    // set the time

Please let us know if you have any other issues or questions.

Best regards,
Michael E. West
Senior Software Design Engineer
Ettus Research

On Sun, Oct 4, 2015 at 6:32 AM, Sivan Toledo via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Waiting for 3 seconds before starting (to make sure no cached values are
> fresh) and spacing out the 3 trials 2 seconds apart (as opposed to every
> second) seems to do the trick, since the GPS sentences get too old to be
> reported twice. Figuring this out required reading and
> understanding gps_ctrl.cpp.
>
> I still think that is necessary to document the behavior of these
> functions so that users can synchronize the radio's clock to GPS and to
> ensure that if the behavior changes, the UHD change log reports the change.
>
>
>
> On Sun, Oct 4, 2015 at 1:13 PM, Sivan Toledo <stoledo at tau.ac.il> wrote:
>
>> I tested this again in 3.8.5. The behavior is different (and the
>> difference is not documented in the change log), but is still weird to the
>> extent that this is hard to implement Marcus's suggestion with confidence.
>>
>> I wait for a PPS change, wait 200ms, and then poll for GPGGA and GPRMC.
>> The first time, it takes 200ms to get them. They are correct (the value is
>> the second at last PPS).
>>
>>  I repeat and wait again for a PPS change, wait 200ms, and poll for the
>> NMEA strings. I get the first strings again. This takes almost no time
>> (they appear to be cached).
>>
>> The third time, getting the GPS strings takes again 200ms and they are
>> again fresh.
>>
>> The behavior is repeatable and stays the same if I wait 500ms after the
>> PPS.
>>
>> Is there a way to know that the GGA and RMC strings are fresh and not
>> cached? I can retrieve them before the PPS and make sure they changed, but
>> this seems like a hack.
>>
>> Thanks, Sivan
>>
>>
>> On Sun, Oct 4, 2015 at 9:21 AM, Sivan Toledo <stoledo at tau.ac.il> wrote:
>>
>>> Marcus,
>>>
>>> I am trying to follow your advice but this does not really work. You
>>> wrote "We recommend polling on multi_usrp::get_last_time_pps() to wait for
>>> the PPS edge and then sleeping 200 ms before calling that line to allow the
>>> GPRMC message to propagate to the host."
>>>
>>> I implemented this code. I wait for a change on the value returned by
>>> get_time_last_pps. Then I sleep for 200ms. Then I
>>> call get_mboard_sensor("gps_gpgga") and get_mboard_sensor("gps_gprmc").
>>> These two calls take 2 seconds. For some reason, if I only request
>>> gps_gprmc, this takes 1.2s. In any case, it does not seem that the NMEA
>>> strings "propagated to the host" and can be queries quickly. This makes you
>>> strategy, if I understood it correctly, impossible to implement, because it
>>> requires associating a PPS with an RMC from the same second.
>>>
>>> I am using UHD 3.5.1 with an N200 with a GPSDO, but in the changelog I
>>> don't see any relevant changes. (I see "Fixed issue where ZPU would
>>> report empty NMEA strings from GPSDO" in the list of changes for 3.7.2, but
>>> I don't get empty strings).
>>>
>>> In 3.5.1 the USRP does synchronize it's time to GPS time, and I am
>>> relying on this feature. If you later removed it, as you wrote ("The
>>> latest versions don't automatically synchronize device time to GPS time"),
>>> then
>>> (1) *why isn't this change documented in the change log*? This lack of
>>> transparency over behavior changes is really troubling to me.
>>> (2) *if recent versions don't synchronize, can you please provide a
>>> code sample that does synchronize reliably?* You dropped the feature
>>> and as far as I can tell, you replaced it with the advice you gave in your
>>> post, which does not work.
>>>
>>> In general, I think that the interaction of the GPSDO and the USRP
>>> should be documented. Right now I am not aware of any documentation. What
>>> is the meaning of the "gps_locked" sensor (that also take a second to
>>> poll)? What is the meaning of "ref_locked". How old are the NMEA messages?
>>>
>>> Thanks, Sivan Toledo
>>>
>>> On Wed, Sep 30, 2015 at 3:42 PM, Marcus D. Leech via USRP-users <
>>> usrp-users at lists.ettus.com> wrote:
>>>
>>>> On 09/30/2015 08:32 AM, Taariqa Maharaj via USRP-users wrote:
>>>>
>>>> Hi
>>>>
>>>> Can you please supply me with the schematics for the Board Mounted
>>>> GPSDO (OCXO) for the x310?
>>>> I am trying to synchronize the GPS time with the PPS time, but seem to
>>>> off by 2-3 seconds. I have a 5V active antenna connected. The GPS time and
>>>> my PC time align but not the device time.
>>>>
>>>> Regards,
>>>> Taariqa
>>>>
>>>> Which version of UHD are you using?  The latest versions don't
>>>> automatically synchronize device time to GPS time because it's not reliable
>>>> during
>>>>   device start-up.
>>>>
>>>> Ettus Research doesn't make those GPS modules, they're made by Jackson
>>>> Labs, so Ettus cannot supply schematics.
>>>>
>>>>
>>>> Here's an e-mail from a couple of days ago on the subject of GPS time
>>>> alignment, with newer UHD:
>>>>
>>>>
>>>> Yes, the feature automatically setting the time to GPS time was also
>>>> removed.  The time was getting set before GPS lock was obtained, so the
>>>> time was more often wrong than correct, and the device initialization was
>>>> completing before the next PPS edge, so the time was not actually set and
>>>> there were numerous issues with applications using timed commands or trying
>>>> to set the time.  So, yes, the time will need to be explicitly set using
>>>> multi_usrp::set_time_next_pps().  We recommend polling on
>>>> multi_usrp::get_last_time_pps() to wait for the PPS edge and then sleeping
>>>> 200 ms before calling that line to allow the GPRMC message to propagate to
>>>> the host.
>>>>
>>>> I do agree that a single API call to set the sources and synchronize
>>>> the time to the GPSDO would be convenient.  I will pass the suggestion
>>>> along to R&D.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151005/3e880e61/attachment-0002.html>


More information about the USRP-users mailing list