Where to get the files : Note that I'm now storing TLEs on this GitHub repository. This should make the documenting of updates a little more precise than it has hitherto been.
What these TLEs are: These are orbital elements, in the TLE format, for several high-orbiting artsats that have been tracked by asteroid observers. These objects usually have periods of two or more days, and/or have high eccentricities such that, at apogee, they move about as slowly as a fast-moving near-earth asteroid would. In most cases, TLEs are unavailable elsewhere; Space-Track.org, the US Government organization that supplies most publicly-available artificial satellite elements, either doesn't track or doesn't publish elements for many high-flyers. I don't think there is a "national security" angle here. I think it's just that their main task is tracking objects in lower orbits. Also, I gather they rely heavily on radar for objects that don't transmit anything (junk, inactive satellites). Radar is jaw-droppingly good for low-earth orbits, enabling accurate tracking of even tiny objects. But it loses effectiveness with distance more rapidly than visual tracking (inverse fourth power versus inverse square). If it can track, say, a five-centimeter object in low-earth orbit (about 350 km up), that limit will drop to about fifty meters in GEO orbit and to five kilometers at the distance to the moon.
You can click here to see the source data used to compute these TLEs, residuals, and some analysis of these objects.
You can click here for details on the TLE format, and where to get TLEs for other objects.
How these TLEs were computed: For each object, I determined an orbit from optical astrometry, using my Find_Orb orbit determination software. I then generated a numerically-integrated ephemeris of state vectors from that orbit, usually at a close step size of 0.1 day.
Finally, I used a program I wrote, eph2tle, that could find and least-squares-fit TLEs to that ephemeris. Almost always, the default settings were used : ten state vectors are from the ephemeris, covering one day, and the program looks for the TLE that best fits those ten positions. (In some cases, I could use a larger time span than one day and still get a good fit. In others, especially artsats with periods of more than about six days, even one day spans were too long; the TLE would 'fit' with errors of thousands or even tens of thousands of kilometers.)
As a result, when I write out the TLE, I can also write out the worst error during the time span. This is repeated for all lines of the ephemeris.
All of the source code is publicly available, though I have to admit that eph2tle is currently poorly documented. Right now, it's pretty tricky code to use, and even more difficult to figure out what I was doing. Determining the TLE that fits a given state vector, or set of state vectors, is mildly straightforward for low-orbiting objects, but gets increasingly difficult for high-altitude and/or high-eccentricity objects.
Important safety tip! Note that some of these element files (mostly for objects with orbital periods greater than about six days) contain the lines
# SGP4 only: these TLEs are _not_ fitted to SDP4, even for # deep-space TLEs. These may not work with your software.
The problem is that the SDP4 model has lots of nice trickery for handling 24-hour and 12-hour orbits accurately. But it wasn't really intended for multi-day orbits, especially higher-eccentricity ones and objects beyond the Moon (WT1190F and XL8D89E, for example). In some cases, I simply couldn't find an SDP4 element set that would fit a particular object over a particular time span, or the fit would only be to within thousands of kilometers.
In such cases, I would fit SGP4 elements instead, and set the ephemeris type byte to '2', meaning SGP4. This does result in accurate ephemerides for any object in an elliptical orbit around the earth (no escape orbits, which is why there are no TLEs here for Gaia or similar objects.)
The problem is that every TLE I've ever seen uses ephemeris type 0, i.e., "use SDP4 for any object with an orbital period greater than 225 minutes". (The ephemeris type flag is apparently normally only used for internal processing.) A lot of code expects this, has never seen a non-zero ephemeris type, and will simply ignore a non-zero ephemeris type. So if you see the above warning, be advised: those TLEs may, or may not, work with your software. (They do, of course, work with all of the software and services provided on this Web site.)