Updated 2020 May 06
Special note about interstellar objects such as C/2019 Q4 = 2I/Borisov and A/2017 U1 = 1I = ʻOumuamua
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.
Click here if you're wondering how to get your observations into the correct format.
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 orbital elements and/or ephemerides for an object, and don't have astrometry for it.
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 : The observations can be in the MPC 80-column format and/or ADES format in XML and/or PSV form, and/or in the AstDyS/NEODys .rwo format. You can mix-and-match among these formats, which can be helpful if you have data from multiple sources. Click here for specifics about the format of the astrometry you can use in this and other tools on this site.
Anything that isn't an observation or an observer detail will simply be disregarded. The current limit is about 5000 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 this
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!)
Sky brightness: Background sky brightness from the sun, moon, and airglow, in magnitudes/arcsec^2. The model is from Bradley E. Schaefer, Sky & Telescope, May 1998, pages 57-60. Source code, with comments and references that may be useful, is available.
Galactic confusion: A number from zero to 99 will be shown, 0=nowhere near a dense star field, 99=core of a very dense star field. This is based on the number of Gaia-DR2 stars in the area. I'm awaiting feedback as to just how much trouble a 'confusion factor' of, say, 30 will cause for observing a given object. (Some observers just don't observe below a given galactic latitude, but the real area within which things get too confused is more complicated than that. It also includes areas around globulars and the Magellanic Clouds; the confusion factor computed in this software will include those areas.)
Output: By default, you get a 'traditional' HTML pseudo-MPEC, resembling the MPC's MPECs. You can, however, get various JSON files instead.
• 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.
• 2020 May 06: You can now specify, instead of the default HTML output, various JSON outputs. Also, there's a new 'galactic confusion' quantity available in ephemerides.
• 2019 Sep 15: Added comments on how to solve for orbits for interstellar objects.
• 2018 Jun 16: You can supply data in ADES format in XML and/or PSV form. (Previously, all data had to be in the "traditional" MPC 80-column format.) You can mix ADES and 80-column data. Click here for specifics about the format of the astrometry you can use in this and other tools on this site.
• You can feed astrometry for 1I/ʻOumuamua and get a correct orbit, complete with sigmas.
• 2017 Dec 2: You can specify the name of any object, on NEOCP or otherwise, in the above 'object name' box. Find_Orb will grab the astrometry for that object from MPC.
• 2017 Jan 29: Added a form for getting customized ephemerides for an NEOCP object (since extended to work for all objects). 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. This can be an NEOCP designation, or an asteroid name such as "Eros", or a number (for numbered asteroids), or a comet designation such as "C/2017 U4", or an asteroid designation such as "2009 SJ209".
In this regard, be advised: my server gets "fresh" NEOCP data once every 15 minutes, in the course of updating my on-line summary of current NEOCP objects. So really recent NEOCP 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.
By default, Find_Orb is strongly inclined to get non-interstellar orbits. The reason is that about 99.9% of the time, such an orbit will be wrong, and can mislead you into thinking you've got a much more exciting object than you really do. Such orbits usually mean you don't have enough data, or that some of the observations are wrong.
However, we now know of two objects that really are on interstellar orbits. If you give Find_Orb data for ʻOumuamua or 2I = C/2019 Q4 (Borisov), Find_Orb will notice the 'I' designation and recognize that interstellar orbits should be considered, and it'll get a correct answer. (Though unfortunately, it'll be one that doesn't include non-gravitational effects. For that, you'll have to download the interactive Find_Orb software, run it, load the astrometry, and turn on non-gravs. This is true for all comets, by the way.)
Alternatively, if you've got astrometry for an object that doesn't have an interstellar 'I' designation, you can either mangle the designation to be interstellar; or (more reasonably, in my opinion) insert the following line before the astrometry :
Do this, and Find_Orb will consider interstellar orbits and get the right answer.
Note that if you feed this page data for an interstellar object, but it does not have an interstellar designation or the COM interstellar line, Find_Orb will search valiantly for a non-interstellar orbit. It will find one, but the fit to the observations will be terrible. Which is how we figured out that these two objects were interstellar: no "normal" orbit would fit.
Note that I have a pseudo-MPEC posted for ʻOumuamua, with other comments about this unusual object, as well as similar information for C/2019 Q4 (Borisov).
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...