Calibrating timing of astronomical images using navigation satellites
Calibrating timing of astronomical images using navigation satellites Overview of tools for asteroid observers on this site
Getting the timing right in astronomical imaging is both important and surprisingly difficult to do. The common tendency seems to be to say that you've corrected the time on your computer using GPS signals or NTP, and that therefore, the time written out in your image files must be that of the midpoint of the exposure.
Sadly, while your computer may indeed be synched to have almost exactly the right time, the time in your images can still be considerably off. I've seen cases where the times were for the beginning of the exposure. Or the end of exposure. Or, for reasons that passeth all understanding, one exposure duration too early. (Probably the camera returned a signal when it started the exposure, which the software took to mean the end of the exposure?) Or the time the image was written out to the hard disk.
It's relatively common for me to look at astrometric data and see that one observer is, relative to the others, "late" or "early" by a significant amount. Those are the good cases; I can just exclude their data. More pernicious are cases where the timing is just barely off, enough to bias all their observations a bit, but not enough for me to recognize the bias. To make it (much) worse, timing errors are usually systematic, not random.
About the only way to really verify that the image times are correct is to check them against a known object. Global Navigation Satellite Systems (GNSS) provide satellites that move about 40 arcseconds per second (some a bit faster or slower). If you image one and can measure the endpoints of its trail to within (say) two arcseconds, you've basically fixed the time at which the image was taken to within 1/20 second.
Positions are available for GNSS satellites from five systems: GPS (United States), GLONASS (Soviet Union/Russia), Galileo (Europe), BeiDou (China), and QZSS (Japan). The positions should be good to within centimeters, more than good enough for our purposes.
Note : there is an excellent outline of how to actually use these tools on Peter Birtwhistle's site. Unlike me, Peter is an actual observer (I'm more of a math/physics/software guy) and fills in some details on how you actually get all of this to work properly.
First, you'll need to get a list of GNSS satellites visible at your location for a given time. You can then pick out one or more to observe; I recommend choosing those at high elongations from the sun, but not actually in the earth's shadow. The brightness of these satellites tends to drop quickly when they're far from opposition. Also, for reasons discussed below, it's well to stick to those lacking an asterisk before the RA. You will generally have at least a dozen possible targets at any given time.
Then, for each satellite you wish to observe, you can create ephemerides for a particular satellite and go out and observe it. The difference between where you measure its position and the ephemeris position gives you your timing offset.
I recommend observing multiple satellites (to reduce the chances for error) and to use different exposure durations. This last point is significant. You could observe lots of satellites with, say, a ten-second exposure, and determine that your timing was off by seven seconds, and adjust your timing accordingly.
What you might fail to notice in this case is that a 20-second duration would be off by twelve seconds, if the time reported was that of the end of the exposure, plus two seconds while the image was downloaded from the camera. There are a lot of possible failure modes here. Also, with more observations, you can rule out spurious observations and just use the more reliable data.
Once you've gotten astrometry, you can upload your astrometry and find out how far off you were. The tool will figure out which object(s) you observed, the timing difference for each observation, and how far "cross-track" you were (that is, the difference between your measured position and the closest the object should have come to that position). You'll also get the average timing and cross-track residual errors, and their scatter (standard deviation).
• As mentioned above, Peter Birtwhistle has a page with thoughts on how to use these tools.
• Choosing exposure durations is a little tricky. It's easier to measure a short streak (and these objects move ~40"/second). But set too short an exposure time, and you won't get enough reference stars with enough SNR for a good astrometric solution. There's no one-size-fits-all solution here; you may just have to play around with exposure lengths until you "get it right" (and then you still should try a variety of exposure lengths to make sure the "time" you get is that of mid-exposure, and not start or end or something else.)
• Shutter movement can cause trouble as well. If your shutter moves left, then right, or is an iris-type that opens and closes, the mid-exposure time for all pixels will be identical (some pixels will get a longer exposure than others, which can foul up photometry, but your timing will be unaffected).
But some shutters move (say) right, stop during the exposure, then move right again; on the next exposure, the travel is to the left. That ensures that all pixels get exposed for the same amount of time, making photometrists happy. But it does mean that the exposure time is a function of where you are in the image.
Some people have compensated for this, figuring out how long it takes the shutter to move and making the reported time a function of (usually) the x-coordinate within the image. If you can't do that, the only thing I can suggest is getting the target as close to the center of the image as you can. (My thanks to Dave Tholen for bringing up both of the above points. Dave has to deal with the additional headache of not knowing at the beginning of the night if the shutter is on the left side or the right side.)
• Marco Micheli pointed out that some software has a nasty tendency of assuming that one-second precision should be good enough for anybody. So you can measure time to milliseconds, then have the time that's written out be rounded (or truncated!) to the nearest second.
• Rob Seaman has pointed out that you still really want to have a stable hardware clock. (Without one, your time will start to drift shortly after you calibrate it.) The TimeHat looks to be a high-quality, inexpensive solution... hobbled (as of late 2022) by supply-chain issues : it uses a Raspberry Pi, currently almost completely unavailable. I've also heard good things about the SiTech Time Server.
Note that use of an excellent clock doesn't relieve you of the need to check timing. The aforementioned issues of software or hardware mangling your precise timing still apply.
Usually, the tools on this site can just give you an accurate position for the GNSS satellites, and you can regard that as the answer you'd get if your timing was good to within 1/100 second or so, and possibly better (ten-millisecond accuracy has been tested; millisecond-level accuracy is expected, but I haven't figured out a way to test it yet.)
Positions at that level of accuracy are available a few days in advance for GPS and GLONASS satellites. For Galileo, BeiDou, and QZSS satellites, you only get that level of accuracy a few days late. These tools will give you positions for such satellites in those cases, usually good to within a few arcminutes. So you can go out, observe a BeiDou or Galileo satellite, then wait a few days for the precise ephemerides to become available. Once you've got them, you can use them to check how accurate your timing was.
I realize that this is somewhat annoying. Unfortunately, we seem to be stuck with it. I'm getting the "imprecise" positions from TLEs (Two-Line Elements). Without those, we'd have no idea where to look in advance for Galileo, BeiDou, or QZSS objects. We'd know exactly where they had been, but not where to point our telescopes tonight.
Fortunately, though, there are plenty of GPS and GLONASS satellites. You may find that limiting yourself only to those constellations is not, in practice, all that limiting.
The positions given for observatories are, with few exceptions, from a list of observatories maintained by the Minor Planet Center. (An extended version of the same list is available that adds a few details and explanations.) The MPC list provides, at best, a precision of about 6.4 meters in altitude and latitude (10-6 of the earth's radius). In some cases, one or even two fewer digits are given. When that happens, you get a warning message about the lack of precision.
The degree to which you should worry about this varies. At least one user of these tools is investigating errors at the millisecond level. In one millisecond, a GPS satellite moves about three meters. If your observatory positions is chopped off to 64-meter precision, you can still correct your timing to within about 40 milliseconds. For most people, that's more than good enough.
You may find an 'observatory code' in my errata to the MPC observatory list that gives correct precision. In particular, Mauna Kea is not only given to low precision; the position is for one telescope, probably the IRTF. As described at the above link, one can instead use 'codes' such as Sub for Subaru, Ke1 and Ke2 for the two Keck telescopes, and so on. Positions are also given for scopes at Cerro Tololo, Cerro Paranal, Kitt Peak, Haleakalā, La Silla, and some others that would be lumped into one position by MPC.
Also, you can send me your latitude, longitude, and altitude and I'll either correct the MPC's position or add an entirely new "MPC code" (unofficial, of course!) so you can get correct data.
The required timing accuracy depends largely on how fast the objects you observe are moving. Let's say you sometimes look at objects moving as fast as 0.2 arcseconds/second (= 12"/minute = 12'/hour), and your astrometry is good to 0.5 arcseconds.
In that case, if your timing was bad by 2.5 seconds, it would introduce an error of 0.5", meaning it would contribute as much error as your ability to measure the object's position. You really want to knock the error down to something much less than that. I would be inclined to worry about anything that adds more than about 20% to the astrometric error; for that, you'd want to get the timing error down to 2.5 * 20% = half a second.
Some would argue you should strive for still more accurate timing. The pernicious thing about timing errors is that they are likely to bias all of your observations by the same amount. In contrast, your astrometric errors will (usually) cancel out; you'll be off by +0.3 arcseconds the first time, -0.2 the next, and so on. Get enough data, and you'll gradually improve things.
Timing errors, on the other hand, are usually systematic, not random. If your clock is off by 2.5 seconds, and there's only a small random component to the timing errors, you'll be off by (say) +2.5 seconds, +2.4 seconds, +2.7 seconds... no matter how much data you gather, it'll all be biased the same way.
The tools on these pages really ought to let you knock down timing problems to be a tiny fraction of your overall errors, and I don't think you'll usually find it difficult to do so.
There are, depending on how you look at it, up to four different schemes by which GNSS satellites are designated, making it sometimes difficult to know about which satellite one is speaking.
• LNN - letter and two digits. The letter will be G for GPS, R for the (Russian) GLONASS satellites, C for the (Chinese) BeiDou satellites, E for (European) Galileo, J for (Japanese) QZSS satellites, or I for (Indian) INSS, with other letters doubtless to be added as other countries put up their satellites.
For GPS satellites, the two digits refer to the pseudo-random number (PRN) sequence used by that satellite. Some re-use occurs here, so (for example) G06 first was given to the satellite G003 = 1978-093A; in March 1994, the designation was passed on to G036 = 1994-016A; in March 2014, it was passed on to G049 = 2009-014A; in May 2014, it was again passed on to G067 = 2014-026A. So, one designation, but used by four satellites at different times.
Because of these reassignments, the LNN scheme has the drawback that you don't really know which satellite is meant, unless you have a date as well. However, it's widely used in the GNSS community.
• LNNN - letter and three digits. The letter will be the same as for the above system; the three digits will be different. This appears to be satellite-specific, and isn't passed around the way the letter/two-digit designations are.
• YYYY-NNNL - year, number, letter. This is the "international" satellite designation (of a sort used for all satellites, not just GNSS ones.) It gives the year of launch, followed by the number of the launch within the year. The letter specifies a particular piece from that launch (there might be, say, an A and a B piece that are satellites delivered by that launch, and a C piece which is the booster left as junk from the launch.)
• YYNNNL : the international designation is frequently abbreviated to a two-digit year with no dash. 'YY' of 57 or above is implicitly for 1957-1999. 'YY' of 56 or less is for 2000-2056. Presumably, our children will have to work out a solution for the Y2057 Crisis.
• I've written code to do precovery searches for GNSS sats: give it a list of where you took images over the years ("I got the following RA/dec rectangle at thus-and-such times"), and it will tell you where and when you got satellites.
The problem with this is that there are currently about 80 GNSS satellites, or about one in every 500 square degrees of sky. Go back a few years, and it's a lot less than that. If you're a big asteroid survey, you'll still have plenty of opportunities to spot-check your timing (i.e., you don't get checking on every image, but enough to see night-to-night variations). For smaller scale observers, you'll just get a spot-check at larger intervals.
One such check found 170 GNSS satellites found by the NEAT survey between 1996 to 2002, and I've run similar searches for three other telescopes. But the code is not particularly easy for anyone else to use at this point.
C and C++ source code for these tools is available on GitHub. As noted there, you probably don't really need it if you're just trying to fix your timing. I do see that a few people have downloaded the source. I will bet that most of them made use of the bits for puzzling out satellite positions for use in other projects, quite possibly not related in any way to astronomy or image timing. (Not, of course, that there's anything wrong with that.)
I can be reached at pоç.ötŭlpťсéјôřp@otúlm. If you're a human instead of a spambot, you can probably figure out how to remove the diacritical marks...