[prev in list] [next in list] [prev in thread] [next in thread] 

List:       usrp-users
Subject:    Re: [USRP-users] B205 External Reference issue
From:       Marcus_Müller_via_USRP-users <usrp-users () lists ! ettus ! com>
Date:       2018-09-30 17:04:15
Message-ID: cb234b62b1578623aab0ed5917657d6a9c5e9d4e.camel () ettus ! com
[Download RAW message or body]

Hm, there's beauty to that, but also there's beauty in not letting the
oscillator drift of indefinitely after you've locked once.
So, the classical fastlock at startup/loss of reference lock, and then
increasingly reduced loop filter bandwidth would probably be even
better.
But that means relatively intrusive changes; you'd make `PFD_PERIOD_*`
adaptive, you adapt the `err` clip boundaries, `lock_margin` and so on;
the values used in b205_ref_pll are pretty certainly results of
physical-reality-based verification ¹. That's the point where you'd
spend serious point characterizing the long-time behaviour of something
that probably depends a lot on the characteristics of your clock source
(unless that clock source is way superior to anything on the USRP).
Also, that'd probably be the point where one would have to think about
replacing the well-understood rational ratio PFD control loop with
something more complex (and thus harder to make meet timing at
acceptable resource usage and quantization loss) like an extended
Kalman that can take the nonlinearities of the system into account. 
To be perfectly honest, I don't see either happen very soon.

So, something like extending the state machine in b205_ref_pll to
another state that has a larger threshold until it drops back into an
adjusting state and adding a settings register to manually fiddle with
the state would be the quick and potentially hazardous solution here,
I'd guess.

Best regards,
Marcus

 ¹ a.k.a. experimentation  
On Sun, 2018-09-30 at 11:34 +0200, Sylvain Munaut via USRP-users wrote:
> Hi,
> 
> I didn't see the screenshots (not posted to the list ?)
> 
> But if absolute precision of the clock doesn't matter, you might be
> better off disabling the servo loop once it's "close enough". That
> will require fpga modifications to expose the refpll control though.
> Actually I think this would be a nice improvement in general for the
> b205 to have the DAC value exposed in UHD and allow to enable/disable
> the servo loop, just a thought :p
> 
> Cheers,
> 
>     Sylvain Munaut
> _______________________________________________
> 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

[prev in list] [next in list] [prev in thread] [next in thread]