Looking back over the thread, I thought there might be some confusion about what I am trying to accomplish.
My goal is to get a radio (and only 1 radio) to transmit at a specified time. I don't care what the front end transmit delay of the radio is, I just want it to be consistent so I can calibrate it out of my system. To test the stability of the transmit time, I am using 1 radio connected to an external 1 PPS and 10 MHz reference. I have the radio directly connected to a receiver through a coax cable. The radio and the receiver share the 1 PPS and 10 MHz reference, and the receiver is well calibrated, so it timestamps data very precisely. If I align the radio's clock to align to an external 1 PPS, and then use a timed transmission to transmit on the 1 PPS, the time of arrival of my signal at the receiver, relative to the PPS, should be: TOA = front end tx delay + RF cable delay between the receiver and USRP. At first I tested a B200 and noticed, after many transmissions, the TOA = front end tx delay + RF cable delay between the receiver and USRP + Uniform(0,1/master_clock_rate). This morning I observed the same random delay with the B210. I have tested an X310 and N210 and they did not have the random delay. They gave a very reliable TOA. I would like to know ifthe B2x0 hardware is capable of what I'm trying to do, or do I need to buy a more expensive radio? Thanks for your help. On Mon, Jun 15, 2020 at 11:13 AM Marcus D Leech <patchvonbr...@gmail.com> wrote: > I think I need more information on what you’re doing. > > Are you starting a timed transmit sequence on both B200 and seeing a > timing difference between the two? > > More details on your exact setup will help us all help you. > > Sent from my iPhone > > On Jun 15, 2020, at 1:09 PM, Aaron Smith <aarsmit...@gmail.com> wrote: > > > 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
