Robin - with your insight I see that other users have addressed this on this mailing list. In this thread: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-June/057080.html the user reports that the B210 does not have this problem, even though it uses the same AD9361. Perhaps I will spend the money to test that radio because it's clear the B200 will not work for me.
On Fri, Jun 12, 2020 at 7:35 PM Robin Coxe <c...@quanttux.com> wrote: > 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
