All of the devices share a 10 MHz reference that is generated from the same source as the 1 PPS.
When you say it's a phase ambiguity, are you suggesting that it's a problem with the 10Hz reference or something inherent in the radio hardware that I will have to deal with? Or is there a software fix? On Fri, Jun 12, 2020, 4:05 PM Nick Foster <bistrom...@gmail.com> wrote: > The change in time of arrival with B200s is due to phase ambiguity. Do you > have a 10MHz reference shared between your devices as well? > > Don't know why N210 has that off-by-one timestamp. I'm guessing that > there's an extra flop in the logic for the PPS timing chain somewhere -- as > in, the clock starts ticking on the first tick after PPS comes in. I've > made that error about half a million times, myself. > > Nick > > On Fri, Jun 12, 2020 at 2:23 PM Aaron Smith via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hello all, >> >> I have two separate, but related, questions. >> >> I am trying to trigger an RF transmission every second, and I am >> receiving the transmission with a receiver that has very precise time >> stamps. I am driving the receiver with the same 1 PPS source as the B200 >> and N210. For my simple test, I want the time of arrival at the receiver to >> register at 1 PPS + propagation delay of the RF coax cable + the USRP front >> end delay. In all cases I am running UHD 3.15.LTS >> >> With the N210 I can achieve this. However when I call >> >> usrp->set_time_next_pps(uhd::time_spec_t(0.0)); >> >> and poll the last pps time, I see that it is consistently 20 ns before a >> second. That is, the pps shows at: >> >> 999999980 ns >> 1999999980 ns >> 2999999980 ns >> >> If I call usrp->set_time_next_pps(uhd::time_spec_t(20.0e-9)); then the 1 >> PPS registers on the second. It's almost like the clock is biased by 20 ns. >> I have observed this across 3 different N210s. What could be causing this? >> >> With the B200, every time I destroy and recreate the >> uhd::usrp::multi_usrp there is a random change in the time of arrival at >> the receiver that appears to be uniformly distributed between 0 and >> 1/master_clock_rate. Is this expected? The Ettus website says "All >> functions that directly interact with the AD93xx (tuning, gain change, etc) >> are subject to the scheduling of the AD93xx. The determinism of these >> operations are not guaranteed. " >> >> Is this what I am experiencing? >> >> Thank you for the help! >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
