In message <4e7cdeb0.8070...@earthlink.net>, Jim Lux writes:
>Actually, the really annoying one is where I have a good clock that's
>stable, but I need to keep adjusting "time" to match someone else's
>terrible clock. Most clock disciplining/time propagation models assume
>your bad clock is following a better clock.
That is exactly what happens when you put an OCXO or Rb in a computer
and run NTPD against a server across the internet :-)
I still have a hard time drawing a boundary about this next level up,
and maybe I'm misunderstanding you, so let me think out loud for
a moment:
Its pretty obvious that you can build a suitably general mathematical
model that will cover anything you can expect to encounter:
A polynomium of a dozen degrees will catch any PLL-like regulation
pretty well, add a fourier series for periodic terms like your
temperature variations and finally chop it into segments to
correctly deal with discontinuities from power failuers or
upsets.
But isn't that so general that it becomes meaningless ?
Determining two or three dozen Finagle constants doesn't sound like
anything close to "real-time" to me, and it all hinges crucially
on the mathematical model being expressive enough.
Something like the SOHO unthaw would be a really tough
challenge to model I think.
The opposite approach is accept that clock-modelling is not the
standardized operation, but representing the data to feed into the
clock-modelling software should be a standard format, to facilitet
model reuse.
Some of that data is pretty obvious:
Time series of clock offset estimates:
When
Which other clock
Uncertainty of other clock
Measured Offset
Uncertainty of Measured Offset
Craft orbital params
XYZT, model gets to figure out what is nearby ?
or
Parametric model (in orbit about, ascending node...)
And then it gets nasty:
Vehicle Thermal balance model
a function of:
Vehicle configuation
Vehicle orientation
Nearby objects (sun, planets, moon)
Wavelength
Clock model:
a function of:
vehicle temperature,
bus voltage
gravity
magnetic fields from craft
vibration (micrometeorites, think: Hipparcos)
clock age
random clock internal events
And the list probably goes on and on, until we come to individual
component failure effects.
Missing in this picture is the organizational boundaries:
The mission data comes from one place, and the clock model
or clock parameters are probably delivered by the manufacturer
of the specific device?
How many of these parameters you need to include will of course
depend on the exact vehicle and mission requirements. There is a
heck of a difference between a commercial geo-stationary comms
satelite and Gravity Probe B and Gaia.
One can always say "put it in XML and hope for the best" but
that's not much of a standard, is it ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
