I was able to test the B210 today and I confirmed that it also has a random delay that is related to 1/master_clock_rate.
Marcus, I wonder if I misunderstood your email, because I thought it would work. I am only transmitting with one channel. Do I have to utilize the other channel in some way to resolve the random delay? Thanks, Aaron On Fri, Jun 12, 2020 at 8:19 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 06/12/2020 10:07 PM, Aaron Smith via USRP-users wrote: > > 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. > > Indeed, the B210 uses the AD9361, which has TWO channels that are > inherently mutually-coherent, since they're fed with the same LO, so > there's very little opportunity for any phase ambiguity. > > Where you run into trouble is trying to maintain phase coherence, and > predictable-and-hopefully-zero mutual phase offset among multiple > devices. It's NOT just a matter of feeding them a common reference > clock and 1PPS. Things are much more nuanced than that. > > This Knowledge-Base article goes into some of this: > > https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices > > I had posted some pointers about RF synthesizers on this list a few days > ago, due to a similar query. If you've never really encountered > RF synthesis before, it's illuminating to study the matter. > > > > 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 > listUSRP-users@lists.ettus.comhttp://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
