Click here for an explanation of what this page is and why it exists, and for links to related tools.
Cut and paste astrometry in the MPC's 80-column astrometric reporting format and/or in ADES format (PSV and/or XML), and click 'Process observations'. (ADES is recommended, because of its better time resolution.) The program will figure out which GNSS satellite(s) you observed and tell you how far off you were in along-track seconds and cross-track arcseconds, for each observation. (The object designations can be anything you like; they'll be ignored.) At the bottom, you'll get averages and standard deviations.
There are several other tools for asteroid observers on this site, including a tool to list GNSS satellites visible from a given site and a tool to generate ephemerides for a given satellite.
As described on the privacy page for this site, data entered into this form and others on this site are kept for as short a time as possible and are not shared with anyone. (That usually includes me, unless an error log indicates I ought to check something out and fix it... which does happen every now and then.) If nothing else, when somebody else uploads data, yours is overwritten.
However, it's occurred to me that we might be able to learn some things from these observations. The International Asteroid Warning Network (IAWN) had an observing campaign in November 2021 to measure timing errors by observing the asteroid 2019 XS. Another IAWN campaign to measure timing errors, this time by observing 2005 LW3, is afoot. The 2019 XS data resulted in an analysis of observatory timing errors. A similar analysis based on observations of navsats might be interesting, and give some useful insights about this method of timing correction and about how timing errors tend to work.
I can't promise that such a paper will occur. However, if you check the above permission box, your data will be stored and made available for analysis on request.
Another possible use for such data : Dave Tholen has done a 'reverse GPS' sort of analysis, using navsat astrometry to determine where the 2.2-m telescope on Mauna Kea is. (This was accurate enough to enable us to detect a ~26-meter error caused by use of a geoid height where an ellipsoidal height should have been used.) It would be interesting to try the same trick with other observatories. In fact, I've been thinking about having a 'best fit observatory position' be part of the output of this tool.
Usually, you can just cut-and-paste astrometry into the above form, click 'Process Observations', and you'll get back data on how good your timing was. The precision of the times in the MPC's optical observation format is a millionth of a day, or 86.4 milliseconds. (If you specify the time to six places! If you only give five places -- which many people do -- the precision is a measly 0.864 seconds, and the software will warn you about that.)
For most people, "microday" precision is good enough. (Click here for a discussion of what 'good enough' timing means.) But even that is not enough for everybody. Somewhat to my surprise, I've encountered situations where people are testing timing down to the ten-millisecond level. In some cases, it's curiosity. Others really have data so precise, on objects moving so quickly, that the motion over 0.01 seconds would cause a noticeable error.
If you're one of these people, you'll have to go beyond the MPC's format.
There are two different ways to do so. You can provide data in the new ADES format, in either XML or PSV format. Click here for details on astrometric data formats accepted by this tool.
If you aren't ADES-ready yet, you can just modify the date/time shown in the MPC formatted record to include extra precision. Click here for an example of extended-precision observations. Here's the first observation in that example, shown first in the way MPC would expect (to six decimal places in the day) and then to nine places, and finally in hour/minute/second form to millisecond precision. Note that because all the data has to fit in the columns assigned for the date/time, spaces and colons get squeezed out.
NAVST43 C2011 10 26.81807021 18 13.88 +13 00 09.1 12.8 V Ce1
NAVST43 CK111026.81807023021 18 13.88 +13 00 09.1 12.8 V Ce1
NAVST43 CK111026:19380126821 18 13.88 +13 00 09.1 12.8 V Ce1
These all refer to the time 2011 October 26.818070230 = 2011 Oct 26 19:38:01.268 UTC. The Minor Planet Center will accept only the first of these, rounded to the nearest millionth of a day. This tool, and others on this site, will accept any of the three formats.
The level of timing accuracy for which you strive depends mostly on how good the positions from your astrometry are, and how fast the objects you move are.
If your astrometry is good to about half an arcsecond, and you're observing an object moving at 3" per second, then having your timing off by 1/6 of a second would contribute about the same amount of error as your positional measurement does. So you'd really like to have your timing be at least that good. (And if you're using the "traditional" 80-column MPC format, you should specify the time to six decimal places.)
The reality is that timing is often not all that hugely important. Most objects are slow-movers. If you're only observing main-belt or more distant objects, you can have significant timing errors and not notice them. The problem is that when you do encounter a fast-moving NEO, the timing becomes very important.
There's another subtle aspect of timing errors that deserves mention : they tend to be systematic. In the above instance, if your timing is 1/6 second late on your first observation of the evening, it'll probably be about that late for subsequent observations as well. Instead of cancelling out as you get more data, as random observational errors ought to, your errors will remain undiminished.
My recommended procedure would be to observe some GNSS satellites, and then feed the astrometry through this page. If it tells you that your timing is off by, say, 1.4 +/- 0.3 seconds, do some analysis to see why that's happening. (Maybe you aren't actually synching to NTP? Maybe there's a software issue? Etc.)
If that error seems entirely reasonable to you, and repeats consistently, then adjust all your observational timings by 1.4 seconds. And then, if you can submit your data in the ADES format (which most software now can), make sure that the rmsTime field in your submissions is 0.3 seconds.
Properly written orbit determination software will make use of rmsTime. Us orbit guys are fine with the fact that your timing isn't perfect. But we really need to know just how imperfect it is. A timing error of 0.1 seconds might be perfectly reasonable (if you didn't expect to do better than about +/- 0.3 seconds anyway). Or it could flag a bad observation, if you really expected to be good to +/- 0.01 second (some video observations are good to that level). But those of us computing orbits from your data do want that rmsTime information. (We currently almost never get it.)
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...