[USRP-users] B210 Second CODEC Loopback Fail - SOLUTION

Tom Wallace tom.wallace at vesperix.com
Thu Oct 1 11:52:50 EDT 2015

If anyone else is seeing the B210 second CODEC loopback test fail intermittently with UHD 3.9.x, as I was, the following change kills the problem for me:

diff --git a/host/lib/usrp/common/ad936x_manager.cpp b/host/lib/usrp/common/ad936x_manager.cpp
index 8c88978..60a09d3 100644
--- a/host/lib/usrp/common/ad936x_manager.cpp
+++ b/host/lib/usrp/common/ad936x_manager.cpp
@@ -94,7 +94,8 @@ class ad936x_manager_impl : public ad936x_manager
             boost::hash_combine(hash, i);
             const boost::uint32_t word32 = boost::uint32_t(hash) & 0xfff0fff0;
             iface->poke32(codec_idle_addr, word32);
-            // We do 2 peeks so we have enough idleness for loopback to propagate
+            // We do 3 peeks so we have enough idleness for loopback to propagate
+            iface->peek64(codec_readback_addr);
             const boost::uint64_t rb_word64 = iface->peek64(codec_readback_addr);
             const boost::uint32_t rb_tx = boost::uint32_t(rb_word64 >> 32);

This is probably the wrong way to fix it, of course - it could just fail again on a faster machine, unless there's some definite relationship between the time it takes a peek to complete and the amount of delay required. I'll leave the appropriate permanent fix to the Ettus guys.

Thanks to Ian Buckley for help in tracking this down.

  Tom Wallace (tom.wallace at vesperix.com<mailto:tom.wallace at vesperix.com>)
  Vesperix Corporation
  803 West Broad Street, Suite 520
  Falls Church, VA 22046
  Phone 703-224-4422   Mobile 703-220-8711

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151001/c7319088/attachment-0002.html>

More information about the USRP-users mailing list