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.
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
