[time-nuts] GPSDO control loops and correcting quantizationerror

[Bob Camp]

Hi

If the objective is to build a GPSDO that *needs* a 32 bit D/A as opposed to a 16 to 20 bit part, there are some things you have to consider.

The output of your GPS has jitter on it. How much jitter is a "that depends" sort of thing, but there's always more jitter than on the output of a good OCXO or Rb. The idea is to get the short term stability of the OCXO or Rb and the long term stability of the GPS. To do that, you are going to set the cross over between the GPS and OCXO at some magic point. Exactly where depends on the actual noise plots of your OCXO and your GPS. With a good DOCXO you can easily have a cross over out in the 1,000 to 5,000 second range. With a Rb the cross over is likely to be in the 100,000 to 200,000 second range. If it's closer in you degrade the short term stability of the OCXO or Rb. 

If the cross over is at 100,000 seconds, everything that happens quicker than 100,000 seconds is ignored by the PLL. Stuff that happens more slowly than 100,000 seconds is corrected by the PLL. No, it's not exactly a brick wall, but it does fundamentally work that way. 

What ever happens with the DAC quicker than the cross over, passes straight through to the OCXO or Rb. In the case of a 100,000 second cross over, daily temperature cycling in the lab winds up as short term instability and is not corrected by the PLL. Hourly cycles (think HVAC cycles) very much will show up as short term issues that are not corrected. If indeed 32 bits matters, then instability at the 32 bit level will show up. Indeed temperature is not the only issue, noise on the DAC output is also a concern. Johnson noise is one source, there are others. 

No free lunch…

Bob



On Sep 15, 2012, at 3:36 AM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> 
> I did some experiments with a charge-transfer D/A and at least as far
> as I can see, that has the potential to go beyond 30 bits.
> 
> The key observation is, as others have pointed out, that we only really
> care about relative local linearity, the PLL loop will take care of
> everything else.
> 
> What I did was take a large-ish low-leakage capacitor and put a voltage
> follower after it, to drive the EFC pin.
> 
> The PLL loop, implemented in software, controlled two fet-switches
> which would deliver positive or negative pulses to the capacitor
> through matched resistors.
> 
> The software involvement allows for trivial calibration of any
> unbalance between the switches & resistors, and even, if you manage
> to measure and model it, I didn't, the capacitors leakage current.
> 
> By controlling the length of the pulses, you can get incredibly small
> "steps" in your output voltage while retaining a wide dynamic range.
> 
> The neat thing is that you do not need a particularly precise or stable
> reference voltage for this design.
> 
> Ideally you would want to drive the switches with constant current
> sources, but if you put an 10bit ADC on the voltage followers output,
> so you know the approximate voltage over the capacitor, it is trivial
> to model the charge delivered per unit time in software.
> 
> At the time I had not read the HPJ article about the 3458A, and if
> I do it again, there are several tricks from there I would employ:
> Balanced pulses to linearize switch-noise and multiple drivers of
> different strengths for faster capture.
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.