[time-nuts] GPSDO control loops and correcting quantizationerror

Bob Camp lists at rtty.us
Sun Sep 16 12:12:51 UTC 2012


Hi

If your definition of timing accuracy is "within 100 ns of GPS time ten minutes after lock" then a faster crossover is a better idea. A faster loop will track GPS better. If your GPS noise is on the order of  10 ns, your time error will be pretty low. An example: 100s loop and 10 ns GPS, => 1x10^-10 noise. 

If your definition of timing accuracy is "best short term stability plot" then picking a long crossover is the way to do it. You want the PLL to only kick in once it's going to do no harm to the noise signature. An example: 10,000s loop and 10 ns GPS => 1x10^-12 noise.

If your GPS noise is lower / higher, the numbers obviously will change accordingly. If your GPS noise is dimensioned in one set of units and your OCXO noise in another set of units, that's going to require a units conversion (pk-pk != rms != 3 sigma etc). 

Bob

On Sep 16, 2012, at 12:40 AM, Tom Van Baak <tvb at LeapSecond.com> wrote:

> I worry in your example about the long cross-over time. This may be ideal for frequency stability, but probably is not good for time accuracy. If one is using the GPSDO as a timing reference, I would think a shorter time constant will keep the rms time error down. Has anyone on the list done work optimizing the timing accuracy rather than the frequency stability?
> 
> /tvb
> 
> ----- Original Message ----- 
> From: "Bob Camp" <lists at rtty.us>
> To: "Discussion of precise time and frequency measurement" <time-nuts at febo.com>
> Sent: Saturday, September 15, 2012 9:46 AM
> Subject: Re: [time-nuts] GPSDO control loops and correcting quantizationerror
> 
> 
> 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
> 
> 
> 
> _______________________________________________
> 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.





More information about the Time-nuts_lists.febo.com mailing list