[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_lists.febo.com mailing list