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.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
