The phase ambiguity is introduced by the divide-by-2 in the PLLs of the Analog Devices AD9361 RF integrated transceiver on the B200. These dividers randomly introduce a 0-degree or 180-degree phase shift when they come up.
On Fri, Jun 12, 2020 at 4:08 PM Aaron Smith via USRP-users < usrp-users@lists.ettus.com> wrote: > 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 >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
