What programs do astronomers use to ensure their observatory control computer has accurate time?

Question

Somewhere I've seen that especially those observing asteroids, in order to provide accurate observations, use timing servers that sync to atomic clocks. What software can be used to do that?

Answer 1

There are two needs for accurate time in modern telescopes and instruments:

1. A source of UT1-UTC for telescope pointing,
2. An accurate source of UTC for timestamping of acquired data in cameras/instruments.

For 1) an accurate value of UT1 is needed for telescope pointing as this should really be thought of as an Earth Rotation Angle rather than a time and so an accurate and up-to-date value is needed to correctly point the telescope. In the past, UT1=UTC was often assumed as the inserted leap seconds keep the difference (DUT1) $UT1-UTC<0.9s$ or broadcast time signals were used to give the value of DUT1 to 0.1s accuracy. With the rising cost of operation of large professional telescopes, more accurate pointing is desired and so many modern telescope control systems query a service such as the International Earth Rotation Services' Bulletin B which contains measured and predicted values of $UT1-UTC$ to $\sim$microsecond precision. A figure of merit to keep in mind is that 1" pointing accuracy, which could the size of your spectrograph slit or fiber on a large telescope, requires knowing UT1 to $\sim0.06\,$s.

For part 2) an accurate timestamp of the shutter open and close events within the instrument control computer is needed (for extreme accuracy such as in measuring low mass exoplanets, what you actually want is the photon-weighted midtime of the exposure i.e. the time when 50% of the exposure's photons have arrived but measuring this requires a parallel exposure meter to record the variation of the astronomical flux with time).

This is normally done using Network Time Protocol (NTP) for which clients are available for most operating systems, including Windows, to synchronize the instrument computer's clock with known good timeservers. Most often the observatory will have a time/NTP server with a GPS receiver (e.g. the Syncserver line of products as an example but a Raspberry Pi plus a GPS hat can work just as well for less demanding applications) to provide this source of time, and often 1 Pulse Per Second (1PPS) or higher frequency time signals such as IRIG-B for telescope axis control. Observatories such as radio observatories and interferometers with more stringent timing requirements may have a local caesium clock or hydrogen maser clocks for extra accuracy and stability.

NTP can compensate for the network delays between the instrument computer and the time servers, can identify and remove bad timeservers to provide a stable source of time and can compensate for the drift of the clock crystal inside the instrument computer. This typically produces an accuracy and jitter of $\sim 2-3\,$millisecond on a fairly quiet Ethernet network of an observatory with local timeservers (worse if the timeservers are over the general Internet). To improve this, NTP can also use the 1PPS signal from time servers/GPS receivers to improve the jitter to $\sim 10-20\,$ microseconds (This is easiest with a real serial port, but there are workarounds for those without). Doing better this is likely to require PTP/IEEE1588 cards in the computer or special timing cards as is done at e.g. the CERN LHC but this nanosecond level timing is rarely needed in astronomy outside of pulsar timing or high frequency radio interferometry e.g. the Event Horizon Telescope.

For asteroids, high accuracy is needed mostly for Near Earth Objects (NEO) as their high rate of motion near close approach to the Earth will directly relate to uncertainties in their positions. With the recent releases of the Gaia astrometric catalogs, uncertainties in the star positions are no longer the dominant source of uncertainty in asteroid positions. If we take the case of a nearby NEO which could be moving at 100"/min, then in order not to introduce more uncertainty than a typical star positions's uncertainty of say 0.1", then you need to know the midtime of your exposure to $\lesssim0.06\,$s. This can be done fairly easily with regular NTP, but with the regular drifting clock crystal of a typical PC which can a drift of tens to hundreds of PPM. The International Asteroid Warning Network ran a campaign on the close-passing/fast-moving NEO 2019 XS to test people's timings and the results are available in the (open access) PSJ paper

Answer 2

You’re not in the subfield of ‘Time Transfer’, I see. No software is necessary; how do you think work got done before ~1950?

Local oscillators were quite good before electronic computing, much less networked systems. The issue was clock drift over long (-enough) timescales, which could be days to weeks for a nice chronometer in a typical use case. This was handled by ‘synchronizing watches,’ you know? Ever see spies or commandos synchronize their watches in old films? You know, film?

For observatories, which sought remote locations, time transfer was provided by a service, typically a phone line recording, or for even more remote sites, a radio recording- time service stations. Speaking for the United States, NBS (now NIST) provided WWV time service.

Later, time service got duplicated by other media. The US Naval Observatory has a website providing time reference, which you can pick up with their API. Still later, GPS has a time signal (that’s the point) whose decoding gets baked into every GPS receiver.

“ especially those observing asteroids, in order to provide accurate observations, use timing servers”

Clearly you don’t recall occultation observers, calling out their contacts by voice for recording on tape. You know, audio tape?