It’s somewhat often that I see an astro-imager get befuddled with a time-related issue. Sometimes their mount will be found pointing 1 hour ahead or behind the target after being commanded to slew to the target’s coordinates. Other times an axis will inexplicably jump, or guiding will slowly degrade over time only to suddenly improve again. The mount’s sense of time is often a prime suspect in these cases, as time is a factor in many astrometric calculations, some of which may be done in real-time as part of tracking a sky model. This means that inaccurate time, and even drifting computer clocks, may introduce problems.
This article explores how some mount systems manage time and how the computers that control them can help provide an optimal solution regarding time accuracy.
How mounts handle time
All mounts need some sense of the current date and time in order to correctly compute where a given right ascension coordinate is in the sky as well as to calculate precession of a J2000 epoch to local-apparent, otherwise known as JNOW. The “J”, by the way, denotes the Julian calendar.
Mount electronics tend to be simple worlds, commonly ran using microcontrollers that depend on external sources of time in order to function as they lack a built-in RTC circuit that keeps track of time when the mount has no power. Some mounts do have a built-in RTC. Sometimes the RTC is in the hand controller, so that must be connected for it to keep time. Others may completely depend on a connected computer to get the time each time it the mount is turned on. There are several possible scenarios and what is required stem from decisions that are made when the mount is designed.
For the purposes of astro-imaging, it’s not uncommon to see the mount’s ASCOM driver or management application on your computer do time synchronization with the mount behind the scenes. This involves the ASCOM driver or management application reading the system clock’s time and setting the mount with it over its serial or network protocol command language. For mounts connected to via USB/serial or on the local network, any added delay in setting the mount’s internal clock is usually acceptable; under 1 millisecond in typical arrangements.
Users should always pay close attention to their mount’s documentation when it comes to setting the mount’s time. This may also involve corresponding settings in its ASCOM driver. If your mount has a coin cell battery that needs periodic replacement, this is an indication that it might have a built-in RTC circuit. A dead battery can cause time issues and it should be refreshed on a regular, vendor-recommended schedule.
Network time clients
You might have already heard of NTP, or Network Time Protocol. This is a widely-used TCP/IP network protocol, the current version of which is defined in IETF RFC 5905. All modern computer operating systems implement some form of NTP client. This client interacts with an NTP server from which time is queried and then applied to the computer’s clock. NTP servers in turn serve time from a variety of clock sources – atomic clocks, GNSS signals, shortwave radio stations, even other NTP servers. Billions of computing devices around the world utilize networks of NTP servers to keep clocks in somewhat close synchronization. Note that I use the word somewhat. I’ll explain why.
A full NTP client would typically be configured to stay in contact with a list of NTP servers; usually from 3 to more. It queries these servers every few seconds and uses standardized methods to calculate the quality of time it gets from each server. Aspects such as network latency between client and server, the jitter factor across multiple requests and their responses, and overall stability of the queries is measured. The server which exhibits the best quality is chosen by the client as its time reference and applies the time it gets from it to the computer’s clock, taking into account the measured factors. This assessment is constantly done, so the preferred NTP server might switch if the chosen one degrades or another one appears to have become better.
But not all NTP clients are full NTP clients. Many are SNTP clients, where the “S” means “Simple”. These are to be avoided for the purposes of timekeeping on astronomy control PCs. SNTP clients still use the NTP protocol, but only a subset of it. SNTP clients emit a single query to a single server and sets the system’s clock with the NTP server’s response. There is no assessment of quality and no compensation for round-trip delay and other factors. SNTP clients will get a computer close to accurate, but not constantly so. SNTP clients are simple to implement and configure. They are certainly sufficient for most home and office computers and their uses, but not for systems that require a higher level of constant accuracy. Enterprise servers generally utilize full NTP clients.
The problem with SNTP clients
Due to the simplicity of SNTP clients, they come with three notable drawbacks.
First, SNTP clients tend to query NTP servers and update the system clock on long intervals, on the order of several minutes to even a full week, as in the case of Windows’ SNTP client. This long interval between queries allows the PC’s clock to resume any drift and the longer interval between queries can mean the drift error can become substantial before it is corrected. On consumer PC hardware, drift amounts can range from a few seconds to multiple minutes over a few days. The severity of the drift varies with age, temperature, and quality of your PC’s clock components.
The second problem occurs when SNTP clients query the NTP server and apply the response. SNTP clients will “step” or “jam-sync” the clock forward or backward with the response they get from the NTP server. This can lead to time being skipped when a slow system clock is set ahead, or (and perhaps worse in some cases) the same time occurring again if a fast system clock must be set back. A full NTP client will instead slew the clock to the desired time. If the system clock is fast, the NTP client will slow the clock down until the desired synchronization is attained. If the system clock is slow and is behind the NTP server, the clock will be slightly sped up. Step adjustments can still happen, though, but this usually happens at the very beginning of the NTP client’s operation or if the system clock is on the order of several seconds’ difference from the NTP server, where slewing the clock would take impractically long. This happens at boot time, though, so likely well before any user or time-sensitive applications are started.
The third drawback is that an SNTP client is a one-shot, single-query client that does not assess the quality of the time it gets from any given server in relation to others. An SNTP client sends a time request to a chosen NTP server and receives the reply some (hopefully) short time later. The SNTP client can apply some basic logic using the response contents to account for the round-trip time of the query, but it has no notion of the quality of server being used – its relative offset, offset jitter, delay (latency), and other factors. Because network and server conditions change over time, the highest-quality server can and often does change. The full NTP client’s constant monitoring and trending of a list of candidate NTP servers will ensure the best one is utilized as the preferred time source.
Improving timekeeping on Windows
Astro-imaging applications which rely on accurate time (in addition to location) to calculate where something is in the sky can certainly do with a more reliable system clock and, by extension, a better method disciplining it than what SNTP can provide. The simplest improvement is to install n NTP client that exercises the full features and methods of the protocol. There are other ways to improve local timekeeping, and which method is best depends on your own situation and use cases. I will go through them below.
Activating Windows’ own NTP client
Upon the release of Windows 10, Microsoft finally realized that consumer computer clocks can be craptastic and the time service in Windows could be improved to operate as a normal, fully-capable NTP client instead of just SNTP. However, this is not on by default. Unfortunately, configuring it is a venture onto the command line and possibly even the registry, and it offers nothing readily available in the way of statistics or feedback regarding how well your PC is staying in sync. If you wish to read about this method, you can do so here. It works and does not require that you install anything additional onto the OS, but it is not my preferred way of dealing with accurate timekeeping on Windows. MS could have certainly done better here with a configuration UI.
Using a third-party NTP client
NTP.org is the home of the people who maintain both NTP as an IETF standardized network protocol, as well as the public domain reference software implementation of that protocol. Meinberg is a German company that produces network timekeeping products. One of the things they offer is a free Windows version of the NTP.org reference software, wrapped in a convenient Windows installer. You can download that here and the installer will walk you through the setup. This is the arrangement I used on my Windows systems.
Using a GNSS receiver with NMEAtime2
If you are able to string a USB or serial cable from your astro control PC to a USB or serial GNSS receiver that has an unobscured view of a large portion of the sky, you can sync time off the GNSS network (GPS usually, but other receivers can also support other GNSS networks such as Galileo, Baidu, and GLONASS, sometimes concurrently) using an application named NMEAtime2. This app costs $20.48 and offers a 30 day trial. It’s very straight-forward to set up and employ. It runs a service in the background that talks to the GNSS device and disciplines the PC’s clock with it. The GUI for it provides some nice stats.
One of the downsides of this arrangement is that only NMEAtime2 will be able to use the GNSS device’s COM port. This is because, in Windows, only one application can have a given COM port open at a time. This means that other apps, such as mount control programs that can talk to GNSS devices to get location information, will not be able to simultaneously utilize the GNSS device. You will need to provide a second GNSS device for them or input location information by other means.
Site-wide time server
Say you have a RoR observatory with a bunch of piers in the bay with associated control PCs and you don’t want to install and configure a GNSS receiver on each and so on and so forth. Or, you would just like to have all your PCs – Windows, Linux, Macs, whatever – use a single local time source because your site has a low-bandwidth/high-latency Internet connection and it would be better to keep NTP traffic local. In this case, you can roll your own NTP server that gets its time via GNSS, and then all your computers use their NTP clients to point to it. This gives them access to a local, low-latency stratum 1 time reference in conjunction with setting up time clients on them like I detailed above.
There are several sources of info online that detail how to create one, usually something based on a Raspberry Pi or other such mini-PC running Linux, but there are also embedded ideas, too. If you already run a small RPI system for an all-sky camera or SQM, you could add NTP duties to it. Of course there are also commercial GNSS NTP server solutions available for a range of costs, some include Rubidium clocks that are disciplined with GNSS.
When to use what?
- NTP clients (not SNTP clients!) that point to reliable NTP servers are absolutely fine. You don’t need to buy hardware or software to use them. You don’t need to worry about trying to figure out how to get a GPS antenna outside your dome, or what to do when the RoR is closed and the GNSS signal is too attenuated to use. As long as your system can reach the NTP server(s) you configure, they will have accurate time. However, if you are a mobile imager or image in places without Internet connectivity, using NTP will not work. Remember – avoid SNTP clients such as Dimension4 and NetTime.
- USB/serial GNSS receivers: If the receiver’s antenna can be placed where it will have a clear view of the sky, you can implement this with the mentioned NMEAtime2 app to get an accurate clock without having to deal with NTP. This is a good solution for mobile users or for observatories that lack reliable Internet connectivity. A downside of this is that dome observatory users may need to mount an external receiver antenna. RoR users may wish to do the same, as the GNSS signals may be blocked when the roof is closed.
- Roll your own stratum 1 NTP server: If you have more than 1 computer that you would like to keep time synced using a local GNSS receiver, and/or would like to offer all users/clients of your RoR pier farm a local stratum 1 NTP server to use, you can purchase or build your own NTP server that uses the GNSS receiver to serve time with. The homemade ones can be cheap enough such that having 2 can be considered, as NTP clients can utilize both concurrently and there will be a redundant source of time. Obviously, this is more oriented towards home or observatory situations.
A note about public NTP servers
Many things elect to use the public NTP.org server pool as a default. The NTP.org pool is a volunteer pool of independently-operated NTP servers around the world. For the most part, using the pool is fine. You’ll get reliable time and installing a proper NTP client will weed out anything of poor quality. Some sites might have security requirements that cannot allow time sources to be in other countries, or certain other countries, and using the generic “pool.ntp.org” address will never guarantee which locale in the world that your time will come from. There are regional pool addresses you can use which are detailed on their website.
Personally, in North America, the time servers I prefer to use are ran by NIST and the UNSO:
ntp-d.nist.gov(NIST HQ pool, Maryland)ntp-b.nist.gov(NIST Boulder pool, Colorado)tick.usno.navy.mil(US Naval Observatory pool 1, Washington DC)tock.usno.navy.mil(US Naval Observatory pool 2, Washington DC)
A note about using GNSS/GPS receivers
GNSS receives are participants in a dynamic network. As such, they need to be kept up to date with the state of this network and they do so by using almanacs of information. These almanacs expire and, after some time of not being in contact with the GNSS network, receivers will need to acquire a new one. This can take up to 15 minutes to do after being turned on and apps such as NMEAtime2 will not sync the time until the GNSS receiver updates its almanac and obtains a lock. For this reason, it is always best to have the GNSS receiver situated so that it’s always on and is receiving signal. Otherwise, you will need to take care of when NMEAtime2 reports that a lock has not been obtained, because that will mean your PC’s clock is not being synced.
The topic of a dedicated PPS signal may come up. The Pulse Per Second signal is traditionally implemented as a dedicated pin on a RS232 serial interface, usually a DB9 type connector or a separate coaxial signal feed. NMEAtime2 does not use this as it’s made to work rather generically with all sorts of commodity, consumer-grade GNSS receivers, most of which are USB-based these days. That means no dedicated PPS pin or output. As explained in NMEAtime2’s info page, it uses filtering to synthesize a PPS signal based on the GGA sentences that the GNSS unit emits. The result is still accurate enough for our purposes.
N.I.N.A. and mount time
Because I’m a contributor to the N.I.N.A. astro-imaging application, this article would be incomplete without mentioning what it tries to do to enforce some sanity regarding mount and PC time. When N.I.N.A. connects to a mount’s ASCOM driver, it queries the mount’s time via the ASCOM UTCDate property and compares when it gets to what the PC claims the time is. N.I.N.A. will raise a warning notification if the difference is more than 10 seconds. N.I.N.A. cannot tell which of the two clocks is more accurate, only that the two are substantially different. Optimally, they should be the same, at least within a few milliseconds of each other. How much of a difference is tolerable depends on your setup – longer focal lengths will be more sensitive than shorter ones. As always, refer to your mount or ASCOM driver vendor’s documentation regarding managing time.
Hi Dale, you have a lot of great info here. Is there a way of knowing how accurate the time needs to be?
I’m guessing very accurate for say satellite tracking. But what about photography? I use a gps with NEMAtime2 for a mobile setup with Mach2. I also do a Dec/arc model and centre on target (platesolve). I know I should only need rough time in reality but just to answer questions from club members when they ask.
The importance of time accuracy goes up with focal length. I honestly think this kind of question is not really worth the time spent attempting to divine to some exacting all-encompassing chart of temporal tolerances when the ability to get sufficiently accurate time under any amateur or scientific context is easily accomplished for none to little money. Use a proper NTP client if the system has sufficient network access and NMEATime2 plus a < $50 USB GPS if one doesn't.