Radar astrometry in MPC format
Radar astrometry in MPC format Overview of tools for asteroid observers on this site
Click here for all current publicly-available radar astrometry, converted to the existing 80-column MPC astrometry format.
MPC does provide some radar data for some objects, but it's not very complete and not usually updated. However, the JPL version of the radar data tends to be complete and reasonably up to date. But I know of no software that actually reads the JPL format. So I wrote a converter program that turns the JPL data into the 80-column format and used it to create the above file. I have a job running on this server which downloads the JPL file daily and converts it to the punched card format.
Output to ADES in either PSV or XML or both would probably be a good idea. (Though in this instance, the punched-card format actually contains almost everything we need, including uncertainties in the data. Note that comment lines and modification times are shown. Some observers are shown in the "Initial. Lastname" form that MPC would expect, but I haven't puzzled them all out yet... I'll probably have to pester the radar observers about some of the more cryptic forms.)
You may find this tool to convert unpacked designations to packed ones (or vice versa) helpful.
You would not normally compute an asteroid orbit using only radar (you'd take advantage of both optical and radio data), but just for yuks... the following are links to pseudo-MPECs with orbits based solely on radar. The residuals are shown in sigmas.
4179 Toutatis
4660
25143 Itokawa
66391
99942 Apophis
101955 Bennu
214869
451124
In some cases, there was a noticeable Yarkovsky effect, which I model with an A1 and A2 parameter (should really only be A2). I just did a few objects for which we have plenty of observations.
You'll notice that in most cases, the residuals in the above "radar only" orbits are much less than one sigma. (If data are normally distributed, about 2/3 of the observations should be within +/- 1 sigma, 95% within two sigmas, and 99.7% within three sigmas. This is a quick way to tell if data are, in fact, normally distributed.) I've asked about this. Seems the radar guys prefer to overstate the uncertainties in their data.
Ideally, you'd want uncertainties to reflect reality, i.e., "This observation is within one sigma with probability 2/3, etc." (With the usual caveats that due to blunders, there will be more outliers in "real" data than you'd get with a for-real Gaussian distribution.) The current situation means that radar data are underweighted: most of them are well within one sigma. This has two bad effects.
First, if you compute ephemeris uncertainties, they're going to be wrong. You'll overstate how poor the uncertainty is; you might tell them that the position is known with an accuracy of three arcseconds when it's really good to 0.3 arcsecond. In the former case, they might think : "Maybe we should get some optical astrometry for this object." In the latter, they'll realize that the object's orbit is well enough determined that (unless their astrometric accuracy is really good) their efforts ought to go elsewhere.
Second, it can be really bad if you try to combine the radar data with optical data (which you almost always do, aside from the stunts I've done above.) If the optical data does have correctly assigned sigmas, the radar data won't be given the "weight" in the solution that it should. You'll have all this really good radar data, but you won't be making full and proper use of it.
For an extreme example : I've been computing orbits using Gaia DR2 data, which has the opposite problem. They really overstated how good their data are, with the result that there are lots of four- and five-sigma errors in Gaia solar system astrometry. Their data really do have low uncertainties; it's just not as low as they state. Orbits computed using Gaia data combined with radar have amazing accuracy, but the totally different concept of how to report uncertainties really throws a wrench into things.
Theoretically speaking, I could probably analyze the corpus of radar observations and determine a multiplier that should be applied (looks to be about 3) to convert "official radar uncertainties" to "realistic radar uncertainties". And similarly for Gaia-DR2, probably getting a multiplier there of about 0.5.