Updated 2017 January 29
Special note about A/2017 U1 = interstellar object
Use the form below to get orbital elements and ephemerides from astrometric observations.
Suggested quick start: Don't panic! Copy/paste your observations in the large text window below, and/or click on "Browse" to pick a file containing the astrometry, and/or enter an object name.
Feed it all of your observations. There is almost never any benefit in giving the program a subset.
Then click the "compute orbit and ephemerides" button. Usually, that'll be all you need to do. If it isn't, hit the back arrow and look a little more closely at your options (options documented here.) If you're still not getting things to work, contact me.
Click here if you just want customized ephemerides for an NEOCP object.
Here are a few hints that may be useful.
Note that the orbit will be computed from all observations, from all three possible sources (cut/pasted, uploaded, or from MPC data), whether their designations match or not. So you can mix-and-match the three input sources, if you have (for example) some new observations of an object already known to MPC.
This is a modified, simplified, non-interactive version of the Find_Orb program.
There are several other tools for asteroid observers on this site.
Observations : You can have extraneous text mixed in with the observations; observer details specifying measurers, observers, telescopes, etc., will be used. Anything that isn't an observation or an observer detail will simply be disregarded. The current limit is about 500 observations.
Object name: Enter an object name here, and Find_Orb will get astrometry for it from the Minor Planet Center. This can be in addition to any observations cut-and-pasted to the text box or provided in an uploaded file.
Epoch of orbital elements: By default, you'll get a "reasonable" epoch (one that's within a day of the time of the last observation). But you can set it to a desired date/time, using any of the formats used in specifying the starting date for the ephemerides.
Residual format: MPC usually gives residuals to a precision of 0.1 arcsecond. By default, this software usually provides another digit of precision. Every now and then, for testing purposes, it can be useful to have a third digit. (It's rare to actually find data good to a milliarcsecond; this is mostly used to allow comparison of results with those from other programs.)
It can also be useful to see the residuals as expressed in "along-track" difference in time (i.e., "the object would have been here 23 seconds earlier") and in "cross-track" difference (i.e., "the object missed the predicted point at that time by 0.23 arcseconds"). This can help in diagnosing timing errors of the sort that often occur with nearby, very fast moving objects.
Redact NEOCP astrometry:
By default, all astrometry is shown in the resulting page.
If you're planning on re-distributing the page, though, you should check this
box. That will cause NEOCP astrometry to be shown "redacted" (blacked out, like
I^P[#ldH6g*/]?\x%, with an explanation
that one should look on the NEOCP for the data).
The reason is that MPC frowns on redistribution of NEOCP data; the data is considered to be preliminary, not fully checked, and solely for personal use. (A few observers have given the "green light" for redistribution; their data is never redacted, even if it came from NEOCP and you've checked this "redact" box.)
If you do not intend to redistribute the astrometry (i.e., don't intend to post the pseudo-MPEC on your blog or Web site or what-have-you), you can leave this box unchecked, and NEOCP data will be shown unredacted.
Ephemeris starting date : This is quite flexible. 'now' is the default, but one can provide dates such as '2014 dec 25', 'Feb-13 3:00', '2015/2/13 03:14:15.9', and it will be interpreted properly. (Note that one shouldn't get too sloppy; '2015-5-6' could be either May 6 or June 5, and '05-06-07' could be interpreted as a (two-digit) year, month, and day in any of six orders, probably but not definitely in the 21st century. Caveat user. I usually go with a four-digit year and three-character month; "2015 Feb 18" is unambiguous, no matter how you scramble the pieces. But essentially, if a human can figure it out, this program should be able to.)
Input such as 'MJD 12345.6', 'jd 2451545', 'now+3h', and 'Wed 3:14:16 PM' will also work; click here for the full list of time input options.
Step size: This defaults to being in days, but input such as '2h' will lead to a two-hour ephemeris step size, or '10m' for a ten-minute step size. One can use '.1' to get a step size of a tenth of a day, and so forth. Negative step sizes will result in a backwards-running ephemeris.
MPC code: This defaults to 500, for a geocentric ephemeris. But it can be any of nearly 2000 three-character observatory codes assigned by the MPC. As an extension, you can use "codes" Sun for the Sun, Mer for Mercury, ... Plu for Pluto, and Lun for the Earth's Moon.
Faint limit: This defaults to 99, meaning that output will be suppressed if the object would be fainter than magnitude 99. (Which does sometimes happen, if the object passes between the earth and the sun. But it's rare. You might reset this to your own observable magnitude limit, so as to get only the ephemerides that are really practical for you.)
Ephemeris type: By default, one gets "observable" quantities: RA/dec, magnitude, elongation, and so on. But you can request tables of state vectors, Cartesian coordinates, orbital elements in either the MPC's MPCORB format or the more verbose "eight-line" format; or you can get a list of close approaches to the observer over the ephemeris span.
For close approach tables, it's a good idea to pick the geocenter or another planet or moon's center. Topocentric close approach tables usually look like garbage, due to the daily distance variation as the earth rotates.
Alt/Az: Causes the altitude and azimuth of the object to be given in the ephemerides. Obviously, if you do this for a geocentric viewpoint or a planet-centered or moon-centered or heliocentric viewpoint, this will be disregarded.
Radial velocity: Causes the radial velocity, in km/second, to be given in the ephemerides.
Visibility indicator: For topocentric ephemerides, this gives a two-character indication of how "visible" the object is. The first character is an asterisk (*) if it would be daytime at that site at that time. 'C'=civil twilight, 'N'=nautical twilight, 'A'=astronomical twilight, ' '=full nighttime. The second character is a space if the moon would be below the horizon at that time; if the moon is above the horizon, you get an 'm' for a less-than-50% illuminated moon, or an 'M' for a more-than-50% illuminated moon.
The idea for this indicator was shamelessly lifted from the JPL Horizons ephemeris system. (The only modification I made was the use of 'M' during the first to third quarter phases.)
Suppress unobservables: For topocentric ephemerides, this will cause output to be suppressed if the object is below the horizon or it's full daylight at the time. That is to say, if you couldn't actually observe the object at that time from that place, it won't get mentioned in the ephemerides.
For (251) Arecibo and (253) Goldstone, the daylight part is ignored. Radar guys don't care about such things. However, the object must be within 19.5 degrees of the zenith at Arecibo, or 70 degrees at Goldstone.
Motion: Causes the apparent motion of the object, in arcminutes/hour (or, equivalently, arcseconds/minute) to be given in the ephemerides.
Element center: By default, the program will automatically select a "reasonable" center for orbital elements. If the object orbits the sun, you get heliocentric elements; for an earth-orbiting artificial satellite, you get a geocentric orbit, and so on. However, you can override the default choice of an element center. In particular, barycentric elements are sometimes the desired choice for distant solar system objects.
Phase angle bisector (PAB): The PAB is a quantity sometimes of interest to those doing light curves: it gives the ecliptic latitude and longitude of the point midway between the observer-target and the sun-target vectors.
Ground track: Gives the latitude and longitude of the point on the earth's surface where the object is at the zenith. This is sometimes useful with objects coming close to the earth or impacting the earth.
Computer-friendly ephems: The ephemerides should be more easily amenable to parsing by computers. For example, the date/time will be given as a JD, the RA/dec will be given in decimal degrees instead of in Babylonian base-60 form, distances will uniformly be given in AU (instead of switching to kilometers for smaller distances), and so on.
Note that the current system is doubtless not bulletproof. In particular, to avoid the possibility of the program locking up and needing to be killed, I've set it to time out after five seconds. Give it a long enough arc of observations, and it'll give up, exit somewhat gracelessly, and you won't get a result.
Language: This is a work in progress. Some text (currently not much; month names and a few phrases) will be shown in the selected language; everything else will remain in English. If you've an interest in adding a language or completing an existing one, please let me know. (It's quite straightforward to do it, except that like most Americans, I really only know one language!)
• At first, feed all the observations to the form and click "compute orbit". This will almost always work. If it does, that's your orbit; unless some observations have unusually large residuals, there is no real point in then running a solution using a subset of your observational data. (If you get a strange orbit, perhaps not including all the observations, then you might try a subset of your data. But this is very rarely required.)
• This page will work for almost all ordinary situations. But if some of your astrometry is a bit poor, or if the length of the observation is more than about a decade, the program may not get an orbit. (It will devote about 15 seconds of processing time, then give up.) Some situations still call for some human interaction to get the program to look in the right place for an orbit. If that happens to you, I'd suggest that you use the Find_Orb software (on which this service is based). It offers many more options, such as the ability to constrain the orbit (say, tell it that the orbit is parabolic), handle non-gravitational parameters, get orbital elements for objects not orbiting the sun, and so on and so forth. Or you can contact me, send me the astrometry, and I'll offer an opinion.
2017 Jan 29: Added a form for getting customized ephemerides for an NEOCP object. Useful if you're interested in such an object and don't have astrometry to add to the solution.
Also, if you're frequently generating ephemerides for a specific place and/or time span and/or number of steps and/or object, you can specify those parameters on the URL. For example,
http://www.projectpluto.com/fo.htm?obj_name=Phreddo&mpc_code=J95&epoch=-11&year=2017 jan 19&n_steps=13&stepsize=10m
would cause astrometry to be retrieved for the NEOCP object Phreddo; ephemerides would be (J95)-centric; the epoch for the orbital elements would be 11 days ago; ephemerides would start on 2017 January 19, for thirteen steps of ten minutes.
Create a bookmark containing the bits and pieces of the above URL that actually matter to you (usually your MPC code, number of ephemeris steps, and ephemeris step size), and you can go to that URL and already have those fields set. (Alternatively, this could be set via cookies. I may eventually offer that option.)
2016 Nov 4: In addition to being able to cut/paste astrometry, or specify a file to be uploaded, one can enter an object name. At present, that object name has to be one currently on NEOCP. I expect to remove that limitation, so you can just enter, say, "2009 SJ209" and get a pseudo-MPEC for that object. (Trick here is doing it without bashing the heck out of MPC servers. Some caching should accomplish that: "don't ask MPC for data on object X if you asked for that data five minutes ago; just re-use what you've already got.")
In this regard, be advised: my server gets "fresh" NEOCP data once an hour, in the course of updating my on-line summary of current NEOCP objects. So really recent data may not show up via this new method.
As per the above note, astrometry can be provided via one, two, or three of these methods.
Find_Orb does not really expect to be fed interstellar objects! Under normal circumstances, if you do so, it'll find some short arc of the data to which it can fit a more "normal" orbit and give high residuals for everything else. You generally would have to run the interactive version of Find_Orb to handle such objects. (Which is how I originally determined that the object was, in fact, interstellar.)
I've sort of jury-rigged on-line Find_Orb so that if you feed it astrometry for A/2017 U1, it shows you a "canned" orbit. This is suitable for checking your residuals and generating ephemerides, but it won't attempt to actually fit your data into the mix, and it doesn't compute uncertainties. I do, however, have a pseudo-MPEC posted with that data (and other comments about this unusual object.)
I can be reached at pôç.ötulpťcéjôřp@otúlm. If you're a human instead of a spambot, you can probably figure out how to remove the diacritical marks...