<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 4, 2015 at 1:13 PM, Sivan Toledo <span dir="ltr"><<a href="mailto:stoledo@tau.ac.il" target="_blank">stoledo@tau.ac.il</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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).</div><div><br></div><div> 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).</div><div><br></div><div>The third time, getting the GPS strings takes again 200ms and they are again fresh. </div><div><br></div><div>The behavior is repeatable and stays the same if I wait 500ms after the PPS.</div><div><br></div><div>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.</div><div><br></div><div>Thanks, Sivan</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 4, 2015 at 9:21 AM, Sivan Toledo <span dir="ltr"><<a href="mailto:stoledo@tau.ac.il" target="_blank">stoledo@tau.ac.il</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><font face="arial, helvetica, sans-serif">Marcus,</font><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">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."</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">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.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">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 "<span style="color:rgb(51,51,51);line-height:15.2727px;white-space:pre-wrap">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).</span></font></div><div><span style="color:rgb(51,51,51);line-height:15.2727px;white-space:pre-wrap"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><font face="arial, helvetica, sans-serif"><span style="color:rgb(51,51,51);line-height:15.2727px;white-space:pre-wrap">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 ("</span><span style="color:rgb(70,70,70)">The latest versions don't automatically synchronize device time to GPS time"), then </span></font></div><div><span style="color:rgb(70,70,70)"><font face="arial, helvetica, sans-serif">(1) <b><u>why isn't this change documented in the change log</u></b>? This lack of transparency over behavior changes is really troubling to me.</font></span></div><div><span style="color:rgb(70,70,70)"><font face="arial, helvetica, sans-serif">(2) <b><u>if recent versions don't synchronize, can you please provide a code sample that does synchronize reliably?</u></b> 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.</font></span></div><div><span style="color:rgb(70,70,70)"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><span style="color:rgb(70,70,70)"><font face="arial, helvetica, sans-serif">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?</font></span></div><div><span style="color:rgb(70,70,70)"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><span style="color:rgb(70,70,70)"><font face="arial, helvetica, sans-serif">Thanks, Sivan Toledo</font></span></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, Sep 30, 2015 at 3:42 PM, Marcus D. Leech via USRP-users <span dir="ltr"><<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div><div>
    <div>On 09/30/2015 08:32 AM, Taariqa Maharaj
      via USRP-users wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">Hi
        <div><br>
        </div>
        <div>Can you please supply me with the schematics for the <span style="color:rgb(70,70,70);font-family:NobileRegular,Arial,Helvetica,sans-serif;line-height:36px">Board
            Mounted GPSDO (OCXO) for the x310?</span></div>
        <div><font color="#464646" face="NobileRegular, Arial,
            Helvetica, sans-serif"><span style="line-height:36px">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.</span></font></div>
        <div><br>
        </div>
        <div><font color="#464646" face="NobileRegular, Arial,
            Helvetica, sans-serif"><span style="line-height:36px">Regards,</span></font></div>
        <div><font color="#464646" face="NobileRegular, Arial,
            Helvetica, sans-serif"><span style="line-height:36px">Taariqa</span></font></div>
        <br>
      </div>
    </blockquote>
    </div></div><font color="#464646"><font face="NobileRegular, Arial, Helvetica,
        sans-serif">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<br>
          device start-up.<br>
        <br>
        Ettus Research doesn't make those GPS modules, they're made by
        Jackson Labs, so Ettus cannot supply schematics.<br>
        <br>
        <br>
        Here's an e-mail from a couple of days ago on the subject of GPS
        time alignment, with newer UHD:<br>
        <br>
      </font></font><br>
    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.<br>
    <br>
    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.<br>
    <br>
    <br>
  </div>

<br></div></div>_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" rel="noreferrer" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>