Hi Marcus I've given this a try, unfortunately I'm running into a problem with that. I've always gotten strange crashes with UHD 3.15 with this codebase (probably my fault, but I'm not sure why yet). I can collect around ~200 datapoints-ish (about 20-ish retunes of the receiver), before it crashes with one of these errors:
***** terminate called after throwing an instance of 'uhd::io_error' what(): EnvironmentError: IOError: [0/DDC_1] sr_write() failed: EnvironmentError: IOError: Block ctrl (CE_04_Port_70) no response packet - AssertionError: bool(buff) in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long unsigned int] at /home/sdrdev/uhd-3.15/host/lib/rfnoc/ctrl_iface.cpp:151 [1] 193504 abort (core dumped) LD_LIBRARY_PATH=/opt/qt- 5.15.1/lib:/opt/uhd-3.15/lib:/opt/boost-1.74.0/lib ***** ***** Receiver error: "ERROR_CODE_TIMEOUT" , continuing... 21:45:08.166 ## default.fatal ## static void UhdSdrVna::uhdLogger(), uhdsdrvna.cpp:866 [x300_fw_ctrl.cpp:53] [X300] 192.168.40.2: x300 fw communication failure #1 EnvironmentError: IOError: x300 fw poke32 - reply timed out [1] 193622 abort (core dumped) ***** Each time it errors out, a hard reset of the device is required, else it will error out immediately after the application is restarted with the second error above. This makes automation difficult. Nevertheless, I've run it several times focusing on areas that looked problematic in the previous dataset. Many (not all) of those problematic areas seemed unproblematic here, though they were only tried once so its difficult to say for sure. On the other hand, frequencies that were giving me invalid results before (no tone at the expected IF frequency on one or both of the channels, cell background color highlighted red in the attached files) are still problematic here however. https://u.pcloud.link/publink/show?code=XZ7KnzXZgqYQElUagKRRKSfugQPJ4yy65ToX Dustin On Wed, 2020-11-11 at 20:50 -0500, Marcus D. Leech wrote: > 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
