On Thu, 2020-11-12 at 13:25 -0500, Marcus D. Leech wrote: > On 11/11/2020 11:11 PM, Dustin Widmann wrote: > > 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 > > > > > Sigh, OK, so let's stick with UHD 4.0. > > I'll note that given the numbers you've provided, you're only > observing > for about 10 samples/frequency. That's not enough time > for the hardware to "settle"--at least given the 100Msps you're > using. The command-time for tuning is the time at which > tuning will be *initiated*--there'll be some latency due to things > like SPI/I2C bus latency, and the vagaries of analog hardware > changing equilibrium, PLLs locking into place, etc. > >
Marcus et al., 10 samples/frequency? No, I'm collecting about 2^17 samples for each datapoint (gives a frequency resolution of about 763Hz, which is probably overkill for my purposes, but I've noticed I get consistent results this way and it seems to be faster than using smaller FFTs and doing averaging). Roughly what I've been doing is this: ** start a tx streamer in a separate thread that is always running ** start a rx streamer in a separate thread that is always running (discard if not currently collecting samples i.e. most of the time) ** for each frequency where I want to measure **** Tune the TX **** Tune the RX (if needed) ****** timed command 100ms in future ****** issue tune command ****** timed command 350ms in future ****** issue tune command again ****** wait for 600ms. for timed commands to be issued and RX/TX to settle **** if the RX wasn't tuned, wait for 50ms for TX to settle **** collect one FFT worth of samples (2^17 in this case) **** process that data Dustin _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
