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

[Jim Lux]

On 9/23/11 4:01 PM, Poul-Henning Kamp wrote:
> In message<4E7D0353.2040704 at earthlink.net>, Jim Lux writes:
>
>> But as we move towards constellations of spacecraft with LONG light time
>> to earth, that whole time correlation process needs to be done
>> autonomously.  So the process of converting "local count" to "time in
>> some universally agreed scale" and back has to be done locally.
>
> Doesn't GR sort of make "universally agreed scale" a pretty interesting
> concept ?
>
> But more importantly, have you done any estimates of the precision/
> required input ratio for this ?

It would be nice to be able to synchronize events between spacecraft to 
a few milliseconds over a time span of a day, without needing a special 
time signal during that time.  Existing clocks, with very simple clock 
models can get this level of precision without too much trouble.  The 
trick is smoothly adjusting when we DO get a fix.

Within a given spacecraft, where there's no explicit need for tight time 
sync because of the instrument (e.g. if you're building an 
interferometer, some casual time scheme probably isn't going to get you 
there), microseconds over a time scale of seconds is probably good 
enough. (i.e. distributing a 1pps to everybody).. this is comparable to 
conventional laboratory practice with IRIG time code or 1pps.



>
> I would seriously look into broadcasting a usable time signal to
> the constellation of vehicles, to use as common reference, rather
> than have each of them attempt dead reckoning of their own clock
> to a paper timescale, which quickly runs into sensor input limitations.

Yeah but that's the way we've been doing it for the last 50 years, so 
everyone is familiar with it.  This newfangled thing of navigation 
constellations and broadcasting time references is just hard when you've 
got dedicated stovepipes to each spacecraft, each with their own message 
formats and time scales. Interoperate? Why should I spend my precious 
budget on helping YOU out? Buy your own darned USO in your own budget if 
you need good timing.
<grin>



>
> By broadcast I don't mean you have to build an antenna tower, there
> are plenty of suitable signals out there already.

Actually not. Consider the back side of the moon, or Mars, or Jupiter. 
In earth orbit, lots of sources (GPS, which is actually usable at the 
moon too, after a fashion)


>
> Presumably they are going to point an antenna back at earth, adding
> a small newtonian telescope with a long-IR sensor next to it, should
> give you a signal with a interestingly complex but mostly periodic
> waveform, which the vehicles in the constellation can use as
> "conductors baton".  Other candidates are Jupiters moons (always
> a favourite), pulsars (Probably needs to big antennae?) GRB's&c.

Adding an optical anything is a tough sell (mass, power, complexity, 
alien to people used to RF, etc.).  And in any case, if you're earth 
pointed for your comm link, then the signal from Earth can provide sync 
(it's how we do it now, granted in an ad hoc way).

X-ray Pulsars are the distant future approach (X-NAV) but we're waiting 
for someone to make a suitable sensor.

Jupiter's moons.. I heard a story at work that you can use an iPhone 
camera to see the moons a'la Galileo and hence can do time transfer by 
Newton's methods. (haven't tried it myself.. Jupiter isn't visible 
because of weather (night and morning low clouds and fog, which will be 
familiar to anyone in Southern California))


The general time transfer problem is to have a good clock on an orbiter 
(e.g. a relay orbiter around Mars like MRO or future s/c) and then be 
able to transfer time using that clock to a lander (e.g. a Mars rover) 
over a UHF link.  There's no direct path from Earth to the rover, and, 
in fact, it doesn't have an antenna big enough.  You might only be 
communicating with the orbiter once a week (or every few days).

So you get the "time" on the orbiter lined up with earth "time" (TAI, 
typically) and then use the stable clock on the orbiter to transfer that 
time to the orbiter.

A practical application for this is something like Mars Sample Return, 
where you want to launch a rocket with your 500g of precious Martian 
rocks and regolith into Mars orbit, where an orbiter can rendezvous with 
it and transfer the samples to a spacecraft that can send them back to 
Earth.   You need to know where the orbiter is (fairly straight 
forward), where the rocket launch site is (not quite as straight 
forward), and figure out when to "push the button" for the rocket.  The 
orbiter might not be in view of the rocket at launch time, and neither 
might be in view of earth, so you can't do a straight "remote control".. 
it's all done by canned sequence.

Since the orbiter is zooming along at a few km/second, a one second 
difference in launch time is a few km miss distance (which, in truth, 
isn't a huge deal.. we've already got to account for the tens of km 
uncertainty in the rocket's trajectory)

Since "mass on Martian surface" is very precious (although not as 
precious as mass back in orbit around Mars), nobody wants to try and 
land a USO (not to mention the vibration and shock loads of entry, 
descent and landing), so a scheme which keeps the "good clock" in the 
benign orbital environment is desirable.


Granted, we can do all this with ad hoc methods...but if it can be in 
the frame of a time architecture, all the better.