I am not qualified to answer your specific questions but our N310 had some bugs when using 3.13.0.0. There are a few N310 specific bug-fixes in 3.13.0.2.
## 003.013.000.002 * N3xx: Fix issue where changing the clock/time source could result in clocks becoming unlocked * N3xx: Improve error messages for invalid clock/time settings * N3xx: Add support for Rev G mboard * MPM: Add function parameter to support holding AD9371 in reset * Docs: Add section on building fs/SD images for N3xx * Docs: Fix Doxygen warnings ## 003.013.000.001 * N3xx: Fix UIO usage in Aurora BIST * N3xx: Fix EEPROM parsing (for upcoming hardware) * UHD: Fix install path for Python API On Fri, Aug 31, 2018 at 8:59 AM, Tillson, Bob (US) via USRP-users < usrp-users@lists.ettus.com> wrote: > Running on Windows with 3.13.0.0, porting some apps from X310 3.9.7. > > > > 1) lo_locked never seems to go true > > > > Have some basic apps that poll/sleep until lo is locked after a tx tune, > never proceed past this point. > > > > Used tx_waveforms to also verify, assertion fails on lo_locked check. > > > > Is this something you are aware of? > > > > 2) Is there a way in 3.13 to programmatically disable dc offset > correction? > > > > When function is called message comes out saying not possible on this > device. > > > > would a way to disable it be through mpm.conf? This is a bit more > permanent than I would like, is there a different API to control this? > > > > Thanks, > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
