[time-nuts] Thunderbolt Loop Damping
Tom Van Baak
tvb at LeapSecond.com
Tue Jul 8 12:48:26 EDT 2008
> Yeah, it's kinda flakey to rely on the device to compare
> its output signals to its own interpretation of GPS time,
> but it's free and requires no external equipment.
Just because something is free doesn't mean it has any
meaning. Stop and think about what your "statistics" are
> The adding of the 1.0 second to the error estimate values
> (and the multiplying of the OSC ppb value by 100) was to
You can't use the same ADEV algorithm for the TI values
as the ppb values; one is phase, the other frequency.
> simulate the values that an external time interval counter
> would produce if it was measuring the signals. Not really
> needed, but the code was lifted from another application
> and it was useful for doing some comparisons to some
> existing data. (BTW, the ADEV code was based upon
> your ADEV1.C)
I'm still confused and now also worried. The time interval
values that adev1.c takes as input are very small numbers,
like microseconds or nanoseconds. These are time *interval*
measurements, as one would obtain when comparing the
1PPS of a reference against the 1PPS of a GPSDO.
At best there is no need to add a fixed constant to these
numbers. Note that the adev code will effectively eliminate
a constant phase bias. But at worst, adding a constant that
is millions or even billions of times greater than your data
can cause floating point loss of precision errors.
So keep the numbers small; think time error measurements,
not time measurements. Second, use ADEV1 only on time
interval or phase data. If you have frequency data you need
to change the tool, or integrate frequency error back to phase
error before you run the tool.
More information about the time-nuts