[USRP-users] Synchronisg GPS and PPS
stoledo at tau.ac.il
Sun Oct 4 06:13:18 EDT 2015
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
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.
On Sun, Oct 4, 2015 at 9:21 AM, Sivan Toledo <stoledo at tau.ac.il> wrote:
> 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:
>> 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.
>> Which version of UHD are you using? The latest versions don't
>> automatically synchronize device time to GPS time because it's not reliable
>> 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
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users