All, A patch for this bug is now included in UHD-3.13. The root cause was a clock switching routine failing to re-initialize the daughterboard PLLs.
https://github.com/EttusResearch/uhd/tree/UHD-3.13 The specific fix is in 5286f1c. Cheers, -Daniel On Tue, Aug 7, 2018 at 9:36 AM, Rob Kossler <[email protected]> wrote: > I am not specifying MCR so it should be 125e6, I believe. > > On Tue, Aug 7, 2018 at 10:29 AM Daniel Jepson <[email protected]> > wrote: > >> Rob, >> >> That is indeed strange behavior. The GPSDO for the N310 has changed from >> previous products to produce a 20MHz reference instead of 10MHz. Either >> way, the PPS should arrive every 20e6 ticks of the reference clock from the >> GPSDO, whether it is locked or not. It appears that the PPS is around 8us >> (160 ticks at 20MHz and 1000 at 125MHz) short of a full second, if I'm >> deducing things correctly from your data. >> >> What master clock rate are you specifying? >> >> -Daniel >> >> On Thu, Aug 2, 2018 at 9:48 PM, Rob Kossler via USRP-users < >> [email protected]> wrote: >> >>> I am learning to use the gpsdo capability of the N310 and I stumbled >>> upon something strange. I have a capability in my software for displaying a >>> message every time the "last PPS" value changes. Note that during startup, >>> I set the clock to zero on a PPS trigger. >>> >>> If I set "time_source=internal,clock_source=internal", I get the >>> following expected behavior >>> Mboard 0 last PPS time: 3 >>> Mboard 0 last PPS time: 4 >>> Mboard 0 last PPS time: 5 >>> Mboard 0 last PPS time: 6 >>> Mboard 0 last PPS time: 7 >>> Mboard 0 last PPS time: 8 >>> Mboard 0 last PPS time: 9 >>> Mboard 0 last PPS time: 10 >>> Mboard 0 last PPS time: 11 >>> Mboard 0 last PPS time: 12 >>> Mboard 0 last PPS time: 13 >>> >>> But if I set "time_source=gpsdo,clock_source=gpsdo", I get the >>> following unexpected behavior >>> Mboard 0 last PPS time: 2.9998 >>> Mboard 0 last PPS time: 3.9998 >>> Mboard 0 last PPS time: 4.9998 >>> Mboard 0 last PPS time: 5.9997 >>> Mboard 0 last PPS time: 6.9997 >>> Mboard 0 last PPS time: 7.9996 >>> Mboard 0 last PPS time: 8.9996 >>> Mboard 0 last PPS time: 9.9995 >>> Mboard 0 last PPS time: 10.9995 >>> Mboard 0 last PPS time: 11.9994 >>> Mboard 0 last PPS time: 12.9994 >>> >>> Note that the time is slowly "walking". It seems that the PPS and 10MHz >>> (driving the clock ticking) aren't synced. Any suggestions? >>> >>> BTW, I verified that the sensor "gps_locked" was true before running >>> this code. I included the source code below for this functionality. >>> >>> stop_signal_called = false; >>> std::vector<double> dbl_vec(usrp->get_num_mboards()); >>> std::cout << "Press Ctrl + C to stop looping..." << >>> std::endl; >>> while (not stop_signal_called) { >>> for (size_t iboard = 0; iboard < >>> usrp->get_num_mboards(); iboard++) { >>> std::cout << boost::format("Mboard %d last PPS time: >>> %g") % iboard % usrp->get_time_last_pps(iboard).get_real_secs() << >>> std::endl; >>> dbl_vec[iboard] = usrp->get_time_last_pps( >>> iboard).get_real_secs(); >>> } >>> while (not stop_signal_called and >>> usrp->get_time_last_pps(0).get_real_secs() == dbl_vec[0]) >>> boost::this_thread::sleep(boost::posix_time:: >>> milliseconds(1)); >>> } >>> >>> >>> _______________________________________________ >>> USRP-users mailing list >>> [email protected] >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> >> >> >> -- >> >> Daniel Jepson >> >> Digital Hardware Engineer >> >> National Instruments >> >> >> >> O: +1.512.683.6163 >> >> [email protected] >> > -- Daniel Jepson Digital Hardware Engineer National Instruments O: +1.512.683.6163 [email protected]
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
