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 <[email protected]> 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" <[email protected]> > To: "Discussion of precise time and frequency measurement" > <[email protected]> > 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 -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
