[time-nuts] GPSDO simulation tool
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 higher tau performance I think we want a higher degree loop.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 47921 bytes
Desc: not available
More information about the time-nuts