[time-nuts] seeking a time/clock software architecture

Jim Lux jimlux at earthlink.net
Sat Sep 24 13:12:44 UTC 2011

On 9/24/11 1:58 AM, Magnus Danielson wrote:

> 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.

Precisely so.  I figure the whole "synchronization/syntonization of an 
ensemble of clocks of varying quality with aperiod updates" has probably 
been addressed in the literature in some way.

>> 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.

That is what I was thinking.


More information about the time-nuts mailing list