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
<mailto: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 <mailto: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 <mailto: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
<mailto: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
<mailto: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 <mailto: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
