On Jun 15, 2020, at 1:09 PM, Aaron Smith <aarsmit...@gmail.com
<mailto: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 <mailto: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 <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 <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
