On 2022-05-20 07:00, Jim Palladino wrote:
Hello,
I believe I've figured out what is causing the TDC errors. I (or one
of my coworkers) will created an "issue" in the UHD github repo, but I
wanted to post some more info here if someone else runs into this.
I found that I could reproduce the TDC measurement errors at least
somewhat consistently with the following command:
while true; do uhd_usrp_probe
--args="force_reinit=1,master_clock_rate=200000000"; done
I don't think the master clock rate matters -- that is just what I
selected, but the force_reinit forces the clocks to get setup each
time. That was the important part in reproducing the error. If I let
this run while the UHD 4.1.0.4 or prior filesystem is installed on an
N320, I have not been able to reproduce the TDC error ever. Using the
filesystem from UHD 4.1.0.5-rc1 and later and running the above
command results in ocassional TDC errors. They occur randomly, but if
I leave it running, I'll usually see at least a few per hour. I tended
to leave it running over night and I'd check for errors the next morning.
It looks like the problem is related to a change made in the LMK04848
configuration in MPM. In UHD
commit d7ee3dcf4a7478a17a094a1be2cba37b98843963, it looks like some
register writes were changed to decrease PLL lock time. It looks like
these registers set the amount of time that the phase detector error
must be within a certain window before Lock Detect is asserted. I'm
guessing that the reduction in time required to declare lock (number
of clock cycles) might be too aggressive. It works most of the time,
but not always.
Making the following edits
to /usr/lib/python3.7/site-packages/usrp_mpm/dboard_manager/lmk_rh.py
seems to fix the issue. Note that this file must be edited on the N320.
Replace:
(0x15B, 0xC7), # PLL1 PFD: negative slope for active
filter / CP = 750 uA
(0x15C, 0x0F), # PLL1 DLD Count [13:8]
With:
(0x15B, 0x27), # PLL1 PFD: negative slope for active
filter / CP = 750 uA
(0x15C, 0x10), # PLL1 DLD Count [13:8]
This just undoes the change made in the commit mentioned above and
requires more time before the LMK04848 to declares lock. Maybe some
value in between would be a better choice, but I'm leaving it this way
for now. I haven't seen any TDC errors so far.
Thanks,
Jim
Thanks very much, Jim.
I've forwarded your comments to the team at Ettus who have been looking
at this issue.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
