On 24/09/11 00:13, Jim Lux wrote:
On 9/23/11 2:00 PM, Chris Howard wrote:
Seems like a lot of unknowns. You would have to
have sensors monitoring the sensors.
I think the "clock model" (insofar as variations in the oscillator) are
outside the scope, as long as the effect of that variation can be
represented cleanly.
For example, with a simple 2 term linear model t = clock/rate + offset,
you can describe the *effect* of a rate, and if the rate changes, the
model changes. As long as you keep track of the rates and offsets you've
used in the past, you can reconstruct what "clock" was for any t or vice
versa.
Which is more or less what calibration records is about.
Infact, how all these measures are intended to be used to provide a
corrected measure with uncertainty bounds is not very well covered in
the papers. It's scattered around.
As for the model at hand... the optimum 2-term model and its update log
might not provide best performance with parameteres directly
interchangeable with the optimum 3-term model. That being said, meaning
that the phase error, frequency and drift does not provide a good source
for phase error and frequency and vice versa.
You might consider to standardise the models in order to provide the
quality in interchange of measurements. You might require to have
support for several models and essentially provide a frame-work standard
for transporting model data. Interconnecting models might need
additional tought.
I need to think about that one.
A clock model predictor might use all those factors to better estimate
the rate. Having a high order polynomial model might let you not need to
update the model parameters as often. That's a tradeoff the user could
make: Do I use a 2 or 3 term clock to time transformation, and update it
once a minute, or do I use a 20 term transformation, and update it once
a month.
A 20 term model requires fairly high precision and good rate
measurements to become meaningfull. Irregular updates as such is not a
problem, as long as you can induce precission into the system when needed.
OK, so if you wanted an output from your Time API that gave you a
"estimated uncertainty of time" (think like the accuracy estimates from
GPS receivers), what would that look like?
Estimated parameters:
timeoffset, frequencyoffset, driftoffset
Uncertainty matrix
Just look in the manual of a better GPS and you essentially see the
Kalman filter model and its parameters popping out.
Do you give a 1 sigma number? What about bounding values? (e.g. the API
returns "the time is 12:21:03.6315, standard deviation of 1.5
millisecond, but guaranteed in the range 12:21:03 to 12:21:04)
You do not want bounding values, noise forms makes it hard. one-sigma
values help. In all this, I keep thinking Kalman filter (or the like).
If you want a standard way of present numbers, you will have to build
that ontop on standard models.
It would be interesting to see what a combination of mutual
synchronisation within a constellation and central synchronisation would
yield. Your constellation would maintain contact with each other and
pull eachother to some form of average time (according to arbitrary
time-scale) and then use the earth link to provide long term
corrections. A good mutual synchronisation strategy would allow the
constellation to shrink and grow without falling completely appart.
If you provide ranging mechanisms within the constellation path delays
can naturally be compensated out of time.
I would expect that a fancy implementation might return different
uncertainties for different times in the future (e.g. I might say that I
can schedule something with an accuracy of 1 millisecond in the next 10
minutes, but only within 30 milliseconds when it's 24 hours away)
This is true, but if you need higher certainty at a particular time you
can schedule a synchronisation event or two where uncertainties can be
reduced. If you have the Kalman state and state-vector, you can run the
predictor into the future.
The mechanics of how one might come up with this uncertainty estimate
are out of scope, but the semantics and format of how one reports it are
in scope for the architecture.
I think you will need to look at the clock models being used. It may be
that the models all belong to Kalman types, but with different model
sizes... but then someone needs a particle filter model... what if the
IMU model is used... time and position.
At least a survey over feasable models needs to be done to see what can
be done.
Cheers,
Magnus
_______________________________________________
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.
