[time-nuts] seeking a time/clock software architecture
jimlux at earthlink.net
Sat Sep 24 00:08:14 UTC 2011
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.
> 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.
More information about the time-nuts