How are Spacecraft Event Times (SETs) managed; to what timescales are they linked?

Question

Spacecraft Event Time explains the importance of remembering just how darn slow light is; it takes minutes, hours, and in a few cases almost a day for light to travel one way between humans and their furthest clocks!

As an example only, Wikipedia's Curiosity (rover) says Landing date: August 6, 2012, 05:17:57 UTC SCET (7, 8) screenshot) because the spacecraft used its onboard clock when reporting its own landing.

Other answers here (looking for them now, I might be remembering this complete answers in the form of a comment^†) have mentioned that a deep space spacecraft's clock is in some cases updated by the ground from time to time, though I'm not sure if that's necessary. If we know the offset and we're the only viewer of the clock (it's not the Grand Central Terminal clock for example).

Questions:

1. Are deep space spacecraft event time clocks reset at regular or even irregular intervals to keep them "up to date" somehow, or are they generally left free-running (i.e. if it's not broke, don't fix it)?
2. If they are, to what timescale are they linked or reset referenced to? (e.g. UTC versus JD and uniform timescales like TAI, TT, and TDB (also see answers to Is GPS time at least “really close” to TAI (International Atomic Time)?)

---

^†Comment

Bottom line: accelerometers give down, Sun gives azimuth. On-board ephemerides of Earth, Mars, and the location of the rover on Mars, all of which are kept up-to-date by the operations team, allow the HGA to be slewed to track Earth in the sky. There is one more critical instrument and calibration required: the current time.

Answer 1

From my experience:

1. Ground operators work with UTC. All events are time tagged with UTC time stamps. This is a bit of a hassle for programmers who have to deal with leap seconds, but makes everything more organized and understandable for people.

2. Onboard computers have onboard clocks, which normally count ticks (or seconds) since last reset. The offset between this clock and some epoch time in an absolute time scale is computed and stored somewhere, and might need to be recomputed over time or with resets. In some cases, it is necessary to correct drift from the onboard time scale (which is also noisy) with respect to the absolute time scale.

3. Nowadays, it is fairly practical to chose GPS time as the absolute scale, but TAI would also work.

4. Because UTC is used by operators, it might be better to convert an UTC time stamp automatically to either of the scales the onboard computer users (which is either that of the onboard clock or the chosen absolute time scale). Conversion to UTC onboard might also be a hassle due to leap seconds. The automatic conversion could be done on ground or onboard the spacecraft.

5. JD would also be a hassle because a lookup table would be needed to convert two Julian dates to an elapsed time in SI seconds. But, it is nonetheless used onboard if needed to compute earth/sun/moon accurate ephemeris.

6. My overuse of the word "hassle" is not on purpose, but does express my discontent with these time handling quandaries.

7. Onboard clocks are normally only reset if the whole computer is reset, which depends a lot on the operator and software design, it should not be needed as routine. But the offset parameter may be updated rather often.

Answer 2

I work with one of the Mars orbiter spacecraft. On this particular one, we don't try to control the spacecraft clock, but we do measure it so we can convert to UTC or something like it. We manage the clock as follows:

• The spacecraft clock counts in a 32-bit count of seconds and a 16-bit count of subseconds (65536 subseconds in 1 second). All spacecraft events run on this spacecraft clock, and all spacecraft commands reference this clock only. The spacecraft neither knows nor cares about UTC or any other time scale. The clock is driven by an on-board ultra-stable oscillator, which to my understanding is a precise (and expensive) quartz crystal oscillator with various systems such as temperature-control ovens to make it as stable (constant frequency) as possible. Even though the oscillator is "ultra-stable", it isn't perfect and therefore doesn't tick at precisely 1 second per second. When the clock increments by 1 "second", it is as measured by the oscillator, which means it is close to but not precisely one SI second.
• The spacecraft was powered off during launch and turned on upon separation. When the spacecraft computer booted up, it initially set its clock to zero. However, soon after, the startup script jammed a particular time value. Nominally, this will set the clock to seconds since midnight on 2000-01-01 (the epoch of the JPL Spice time scale) but it doesn't really matter. As it happens, our spacecraft launched a couple of days late, but the startup script was not changed (because the spacecraft was powered down) so the clock was jammed with the "wrong" time by over 100,000 seconds. This doesn't matter, because we take that into account while commanding the spacecraft.
• Since that initial startup, the spacecraft clock has run free, without reference to GPS or any other radio signals. If the spacecraft computer were to shutdown and restart, that would reset the clock (to the setting it used at launch), but this hasn't happened to the spacecraft since launch.
• One of the navigation tasks is "time correlation". The ground station sends up a command to send back the current value of the clock on board. There are dozens of factors that make time correlation complicated, including where Mars is relative to Earth, where the spacecraft is relative to Earth, light speed delay, Doppler, general relativity, etc, etc, etc. One of the most important things is how long it takes the spacecraft to receive, decode, interpret, and respond to this command. It's not instant, but it was carefully measured on the ground and is designed to be constant. Time correlation allows us to measure the clock drift, but we don't try to control it and we never reset the clock.
• The mission operations center (MOC) uses this time correlation to compare the time on the spacecraft to the time on the ground. Since all teams on the spacecraft use the JPL Spice library, the MOC produces a table in the form of a spacecraft clock kernel. This is a table for converting spacecraft times to ephemeris time, which can be thought of as UTC which takes into account relativity etc and is therefore applicable across the whole solar system. Ephemeris time can be converted to UTC on Earth. The table is in the form of a piecewise linear function. For several Ephemeris times, the spacecraft clock readout and tick rate are used to create a linear time offset.

So, if we want to take a picture of Mars at noon UTC, the mission ops team uses the spacecraft clock kernel to convert to a spacecraft clock, say 712345678:01234. They encode that spacecraft clock count into the command script, send that up to the spacecraft, and then when the clock on board reaches the appropriate time, the command is issued and the picture is taken.

Other spacecraft teams may choose to control the clock. They can update the epoch, but they can also sometimes tune the oscillator, say by running it at a different temperature. Or they can say that the spacecraft computer should count 24,000,001 oscilator cycles as 1 second instead of exactly 24 million. These things together are referred to as "clock steering".