[time-nuts] GPSDO simulation tool

Magnus Danielson magnus at rubidium.dyndns.org
Sun Mar 23 07:18:38 EDT 2014

On 23/03/14 06:16, Tom Van Baak wrote:
> Hi Lars,
> The dacbits and avg1 parameter are now enabled. Pick up a new copy of gpsim1.c / gpsim1.exe (http://leapsecond.com/tools/)
> Ok, I added a 400,000 second dataset of a plain M12 (no sawtooth correction): gps-m12m.txt.gz (http://leapsecond.com/pages/gpsdo-sim/)
> Note the 1PPS variation is about 40 ns vs 10 ns peak-to-peak (raw vs. corrected) or about 9 ns vs. 2 ns RMS. So, in general, M12 1PPS granularity improves by a factor of 4 or 5 with sawtooth correction.
> In Timelab, load both gps-m12m.txt (uncorrected sawtooth) and gps-m12cns2.txt (sawtooth corrected). Notice the ADEV plots are have picture perfect 15e-9/tau and 3e-9/tau slopes. Now see MDEV/TDEV. Surprised? Look what happens after about tau 300.
> Go ahead and make two virtual GPSDO runs, without and with sawtooth correction, using filter/PID defaults:
>      gpsim1 gps-m12m.txt ocxo.dat > gpsdo-m12.txt
>      gpsim1 gps-m12cns2.txt ocxo.dat > gpsdo-cns.txt
> In Timelab, load both gpsdo-m12.txt and gpsdo-cns.txt. Check phase, frequency, ADEV, MDEV, TDEV. Does it makes sense, with this OCXO, that sawtooth correction is completely *irrelevant*? Is this an error in simulation or an error in intuition?

As I played around with the parameters yesterday I concluded that the 
first level averaging is that of the loop bandwidth. The GPS/TIC 
averager then do additional averager down to the floor coming from the 
ocxo. This is the behaviour below the time-constant of the loop.
If you want to understand the impact of the resolution above the loop 
time-constant, look at the TDEV.

If you look at ADEV you will see that the raw m12m is above the m12cns2 
and that you only somewhat affect the deviation with the loop 
time-constant averaging. To see the averaging effect, swap between ADEV 
and MDEV, and you see how the MDEV tau-prefiltering closes the distance 
at about 100 s, which also happens to be the AVG1 pre-filter default value.

For longer taus, the pre-filtering is too short to do anything, but the 
loop fights the OCXO noise. It is clear that the performance is 
suffering due to the lack of filtering slope in the loop, as the noise 
is above that of the GPS noise.

* The loop bandwith/time-constant forms an average of GPS noise, pushing 
it down towards the noise of the OCXO.
* Filtering can reduce the in-bandwith/short-tau noise from the GPS down 
to the noise of the oscillator.
* Filtering thus allow the same noise performance of a loop for the 
shorter taus with a lower time-constant as that of a higher one.

If you look at the TDEV plot, the filtering of the loop bandwidth 
handles the flat-noise, but as you see, for lower taus it starts to go 
up, and that's what the pre-filter handles and the core loop was unable 
to handle.

To handle higher tau performance I think we want a higher degree loop.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gpsim7.png
Type: image/png
Size: 47921 bytes
Desc: not available
URL: <http://www.febo.com/pipermail/time-nuts/attachments/20140323/56f3dadc/attachment-0001.png>

More information about the time-nuts mailing list