[USRP-users] Synchronisg GPS and PPS

Sivan Toledo stoledo at tau.ac.il
Sun Oct 4 02:21:12 EDT 2015


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151004/98e99b1a/attachment-0002.html>


More information about the USRP-users mailing list