On 11/11/2020 08:34 PM, Dustin Widmann wrote:
Hey Marcus,
I'm using UHD 4.0.0;;
[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_106700; UHD_4.0.0.0-1-
gcf570707
I had stumbled on the "tune twice" thing quite accidentally (I don't
think I ran into any documentation on it, I was just trying to test for
repeatability with a single frequency, and noticed the first time was
always wrong), but now that you mention it, I guess it kind of makes
sense. I don't know how deep the command queue depth is, but I expect a
tune on the twinrx would ostensibly need to e.g. set the preselector
filter, enable/disable the low frequency pre-amp, select high band/low
band, tune the first stage lo, tune the second stage lo, select high
band first stage oscillator, and maybe another few things that I'm
missing. The only bit about that which I'm not sure is what the minimum
acceptable delays should be to ensure stability in this double-tune
operation. As it stands presently I am taking about ~500ms to retune
the receiver, it would be great if I could get that down some, though I
have bigger fish to fry as of yet.
10s of ms should be more than adequate.
Given that you're using LO-sharing (I didn't realize this), then you may
be running up against
a regression in the code base. The 90/180/270 offsets are suggestive
of a re-synch problem
not with the RF synthesizers, but with the quad-rate real-to-complex
converter that's in the
FPGA codebase.
You could try this against UHD 3.15.X
Unless I'm mistaken and more is required, I'm already using LO sharing
between the channels (but that doesn't seem to be enough...). For
clarity, my initialization function does this: (modified for brevity,
but in order).
_usrp = uhd::usrp::multi_usrp::make(args);
_usrp->set_clock_source("internal",0);
_usrp->set_rx_subdev_spec("B:0 B:1",0);
_usrp->set_tx_subdev_spec("A:0",0);
_usrp->set_rx_antenna("RX1",0);
_usrp->set_rx_antenna("RX2",1);
_usrp->set_tx_antenna("TX/RX",0);
_usrp->set_rx_lo_source("internal", uhd::usrp::multi_usrp::ALL_LOS, 0);
_usrp->set_rx_lo_source("companion", uhd::usrp::multi_usrp::ALL_LOS,
1);
_usrp->set_rx_rate(100e6, 0);
_usrp->set_rx_rate(100e6, 1);
_usrp->set_tx_rate(400e3, 0);
_usrp->set_tx_gain(0,0);
_usrp->set_rx_gain(65,0);
_usrp->set_rx_gain(65,1);
_usrp->set_rx_bandwidth(100e6,0);
_usrp->set_rx_bandwidth(100e6,1);
_usrp->set_tx_bandwidth(100e6,0);
_usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));
I had thought all I needed to do was the "set_rx_lo_source" bit to
enable the LO sharing. Have I done that correctly or have I missed
something? If that is correct, do I need to change how I go about
tuning (detailed in the first email in the chain)?
Dustin
On Wed, 2020-11-11 at 19:52 -0500, Marcus D. Leech wrote:
On 11/11/2020 06:20 PM, Dustin Widmann wrote:
Thanks for the quick response Marcus!
It seems to be fairly frequency dependent. I'm attaching a link to
a
data file so y'all can take a look at what I mean. I ran a dense-
ish
sweep several times to try to get a feel for how reproducible
things
were /etc. The transmitter was retuned at each frequency, but the
receiver was only retuned every 10MHz.
https://u.pcloud.link/publink/show?code=XZviezXZGl5Ypkv46LSVf9l9n1YtOV05z92k
in this file:
* blue or green text = range of datapoints that seem to have
reproducible phase offsets (I alternated between blue and green
when I
noticed a "jump" in the value ;; sometimes these jumps were
90/180/270
degree, but often not, and were reproducible regardless)
* orange text = phase offset is off in some consistent manner
(90/180/270 degree jump) and/or reproducible aberrant value
* red text = phase offset seems to be random/garbage
* red background = invalid datapoint (either tone is at unexpected
bin
on channel 1, channel 2, or both ;; this is one of the other
questions
I was alluding to in my first email, I'm presuming its a separate
issue, but maybe not. It's worth noting that when the tone is
observed
at the wrong frequency, the frequency where it is observed is often
a
multiple of the reference clock instead)
Dustin
What version of UHD are you using?
I spoke with the original developer of the TwinRX driver, and the
preferred approach to tuning if you want coherence
is to tune it twice with timed commands. The reason for this is
that
the number of transactions required to tune the
TwinRx exceeds the size of the X310 command queue, but various
things
get cached, so the second attempt will have
fewer commands in the queue, and will go through with all the
appropriate timing.
Since this is on a single X310 platform, and it's TwinRX, you might
consider instead using LO sharing:
https://kb.ettus.com/TwinRX#New_Multi_USRP_Functions
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
