Last revised here on 2022 Feb 06. You can get more detailed revision information on the GitHub page.
Click here for an on-line form for identifying artsats from observations. It's basically just a CGI wrapper for the code described on this page. If you just need to identify a few dozen objects or fewer, the on-line form is almost certainly your simplest solution.
Note that the source code for this program, and for the artificial satellite code in general, is available on GitHub as open source.
Also: another program of interest for this problem is Ted Molczan's IDSat.
Astrometrists routinely come across artificial satellites in their images, and often don't have a way to ID them. In such cases, they often keep getting data on them in hopes that they've found a more interesting (to an astronomer) object: a near-Earth asteroid. If it turns out to be an artificial satellite, then it's been a waste of effort.
To address this problem, sat_id reads in a file containing astrometric observations in the MPC 80-column and/or ADES formats. It then looks for catalogued satellites that match the observations, both in position and motion. The resulting output shows the original lines from the file, with identifications added (we hope!) after each observation.
The program is based on the artificial satellite ephemeris source code supplied on this site; full C/C++ source code is available.
First, note that for the vast majority of users, the on-line version of this software is probably your simplest bet. You can run it from anywhere and you don't have to worry about keeping TLEs (Two-Line Elements, the orbital data that is "standard" for artsats) current. However, the on-line service is limited to about 500 lines of astrometry at a time, and you need a connection, and if you're going to run lots and lots of objects, it may be slow. Or you may have some oddball purpose in mind, for which being able to modify the source code matters.
To run the program on your own machine, you'll need to get the source code from GitHub and compile it. This is quite easy in Linux or BSD or even OS/X. It gets a bit trickier in Windows, especially since most Windows users are unfamiliar with compilers. I have posted an executable for 64-bit Windows and an executable for 64-bit Windows, current as of 2020 October 15. You should be able to download that, along with the MPC list of observatory codes so that the program knows the latitude/longitude of each observatory, and be off to the races. Be sure to put the compiled sat_id (in Windows, sat_id.exe) somewhere in the executable path.
Next, you will (most likely) want to clone the repository of TLEs for high-flying artsats. Asteroid observers will definitely want to do this. There are quite a few bits of high-flying, slow-moving junk that are catalogued in that repository that are not catalogued elsewhere. If you're only concerned about stuff in geostationary orbit or closer, you can skip this bit.
Next, you'll need to get a copy of all_tle.txt, a comprehensive list of orbital elements for currently-visible artificial satellites. The file is provided via www.tle.info, or from this site in Australia. UnZIP the file to extract all_tle.txt into the same directory as sat_id . (The .zip files are about 1.3 MBytes at present, unZIPping to about 3.7 MBytes.) Put that file in the same folder into which the above GitHub TLEs were cloned, or just make a new folder and put all_tle.txt into that.
Be warned that the elements change over time. You'll probably have to download that file every couple of weeks, to ensure a current set of elements. Which is one more reason to favor the on-line version: it gets those updates automatically.
And now, you're ready to try it out. Suppose you have a file with MPC-formatted astrometry called vfmo.ast. You would open a terminal, change to the folder containing the TLEs, and run
sat_id vfmo.ast
The program would read through the file, pausing at each observation as it looks for possible matches within four degrees that have roughly matching motion. It then outputs data concerning each possible match.
If you wish to save the "match" data, you can redirect the output to go into a file, instead of to the console:
sat_id vfmo.ast > sat_ids.txt
At the end, sat_ids.txt would contain the data previously shown on the screen.
Every now and then, you should run git pull from the directory containing the TLEs. This will download any changes I've posted (and changes are posted fairly often, usually a couple a week.) You can do this fairly often; git is remarkably effective at figuring out exactly what has changed and sending only those bytes it really has to.
If you don't do such updates, sat_id will eventually start emitting warnings about TLEs being about to expire. (The TLEs I generate are fitted for specific time spans, and I usually can't predict all that far into the future. Sometimes, even when I do, new data gives us better TLEs and I'll do an update for that reason.) By default, the warnings start seven days ahead of the actual expiration.
As mentioned above, it's also a good idea to download a fresh copy of all_tle.txt from time to time, perhaps every few weeks.
This program is fairly difficult to baffle. But we don't have elements for everything. If you find that you've tried everything and sat_id still can't figure out what you've found, you should probably e-mail me, at pôç.ötulpťcéjôřp@otúlm (remove accent marks), including the MPC-formatted observation(s). If I can't track it down myself, I can probably find somebody who can (and who can make use of your observations to update the orbit for that object.)
• (2022 February 06) Another update to the (very out of date) documentation.
• (2017 February 22) Updated this (very out of date) documentation.
• (2013 January 7) Made some speed improvements, and revised the output to show object name and some orbital parameters.
• (2012 March 28) Fixed a divide-by-zero bug that occurred if two input astrometry lines in a row had identical times. (The object would have moved, or not moved, over a time span of zero seconds, for an angular speed of something-divided-by-zero.)
• (2006 June 30) Further comment from Eric Christensen: when computing object motion from two consecutive observations, if the second one had a date/time preceding the first, you got a negative rate of motion that's off by 180 degrees.
• (2006 June 23) After comment from Eric Christensen, revised to use names 'ObsCodes.html' or 'ObsCodes.htm', with 'stations.txt' being a third choice. Also added the '-a' command line switch to cause the program to show all lines from input (default is now that only MPC astrometric input gets echoed.)
• (2003 Mar 29) Fixed a problem with high-drag objects: if their projected position crashed into the earth, that caused sat_id (and other satellite code I've written) to crash.