Near-real-time alerts for new bright objects on the NEOCP and PCCP lists. While idle, the service checks every minute and filters e-mail alerts by location, visibility and attainable limiting magnitude.
Preface
I set up this private NEOCP/PCCP alert system because I sometimes learned too late about newly published objects that I could still have observed.
A computer runs day and night. Whenever no full evaluation is active, it checks NEOCP and PCCP once per minute. A completed evaluation is followed immediately by another check. Under normal conditions, a new list entry is therefore detected within about one minute.
The subsequent evaluation downloads observations, calculates the orbit and ephemeris, and decides which recipients qualify. Alert calculation and delivery take priority; archive, table and upload maintenance follows afterwards. Unchanged orbit elements and previously parsed observation files are reused. A running evaluation is completed and is not interrupted by another one-minute check.
RSS/XML, JSON and Discord use the general default selection with station 500 and 20.0 mag. E-mail subscriptions can additionally use a personal station and limiting magnitude.
Motivation
The service makes new potentially observable objects easier to spot. It combines the current MPC lists, downloaded observations, and local Find_Orb working values into reviewable tables.
This is a private supplemental service and not an official Minor Planet Center service. Scientific or operational decisions should always use the original sources and ephemerides.
Useful with smaller telescopes
The limiting magnitude selects objects your instrument can reach. A smaller number is more restrictive: with 18.0 mag, an e-mail is created only if the object becomes at least magnitude 18.0 in the personal 48-hour ephemeris. The 20.0 mag default includes correspondingly fainter objects.
For a topocentric station, the mail includes only times when the object is at or above the horizon and the Sun is at or below −6 degrees. If no qualifying ephemeris row exists, that recipient receives no mail.
Observers without their own MPC station code may choose an existing nearby code for alert calculation. The station finder derives one from latitude and longitude. A closer substitute gives a better horizon and topocentric approximation, especially for nearby objects.
Never report your own astrometry to the Minor Planet Center under somebody else's station code. Guidance on obtaining a code and using the rover format is provided in the station finder.
Personal horizon profile
The safe text import, format detection, azimuth normalization, and horizon interpolation are implemented locally and tested with sample files. The feature should therefore work, but it remains experimental. A safely checked and unambiguously recognized profile is activated immediately without additional manual approval and is used in personal delivery decisions.
A station code describes the observing location, but not trees, buildings, mountains, or a local dome. An optional personal horizon profile may therefore be attached to the registration mail. The website itself does not upload files; checking, storage, and application take place locally in the alert service.
Data model and lifecycle: The profile is part of the recipient record. For a file, the stored fields are the filename, detected format, SHA-256 checksums of the attachment and normalized profile data, and the azimuth/altitude points normalized to north = 0° and east = 90°. A valid attachment activates or replaces the profile immediately. Alternatively, one number from 0 through 90 after Horizon profile: creates a constant minimum-altitude profile for every azimuth. A faulty new value never overwrites an existing working profile; the subscriber receives a notice instead.
An empty Horizon profile: field and a registration without a new profile attachment leave an existing profile unchanged. attached announces the attachment; none explicitly removes the profile. A profile requires a topocentric station code; an existing profile remains stored with station 500 but is not applied to the geocentric ephemeris.
Supported text formats include N.I.N.A., Cartes du Ciel/SkyChart, Stellarium, XEphem, and PVGIS, as well as unambiguous CSV, JSON, and two-column tables. Azimuth and altitude are normalized to north = 0 degrees and east = 90 degrees.
How azimuth is counted
MPC-RSS internally uses the compass convention: true north = 0°, east = 90°, south = 180°, and west = 270°. Values increase clockwise from north through east.
- N.I.N.A. standard text: the first value is azimuth and the second is altitude; the N.I.N.A. source code uses north = 0° and east = +90°. The different MountWizzard4
.hptsformat stores altitude before azimuth and is not currently accepted as a mail attachment. - Cartes du Ciel/SkyChart: north = 0°, east = 90°, south = 180°, west = 270°.
- Stellarium: counted from true north towards east according to its format reference.
polygonal_horizon_list_modeselects degrees, radians, or gradians and altitude or zenith distance;polygonal_angle_rotatezis then added as an azimuth correction. - XEphem: explicitly degrees east of north, again north = 0° and east = 90°.
- PVGIS: its output file uses south = 0°, west = +90°, and east = −90°. MPC-RSS recognizes
A_hor/H_horor the matching JSON fields and adds 180° to obtain the internal north convention.
Verified value ranges
Internal normal form: MPC-RSS stores azimuth as 0° ≤ azimuth < 360°; 360° is the same direction as 0°. Finite values outside this interval are wrapped cyclically. Horizon altitude must be between −90° and +90°, otherwise the file is rejected.
For an ordinary obstruction profile, altitudes from 0° through 90° are expected. Negative altitudes are not necessarily invalid: they describe an unobstructed view below the mathematical horizon, for example from an elevated site, and are permitted by some source formats. They are retained, but do not extend alert selection below the separate object-altitude limit of 0°. 90° is the zenith.
Raw formats: N.I.N.A. standard text, Cartes du Ciel/SkyChart, XEphem, and unlabeled two-column files are read as degree values. XEphem explicitly allows azimuths outside 0°…360° and wraps them cyclically. Stellarium may supply degrees, radians, or gradians and either altitude or zenith distance. PVGIS supplies raw azimuth from −180° to just below +180°, with south as zero. The internal ranges apply only after format-specific conversion.
SkyChart documentation note: the English version apparently says “azimuth 90° = zenith” by mistake. The official Dutch version is unambiguous: azimuth 90° is east, while altitude 90° is the zenith.
For an unlabeled two-column file, the parser assumes north = 0° and east = 90°. The mail fields Source program and Azimuth convention document the source but do not themselves rotate data. Explicitly recognized program formats are converted automatically according to their format conventions. Any other file using a different convention must be converted to north = 0°, east = 90° clockwise before it is sent.
Exactly what can be sent
- N.I.N.A.: its horizon text file containing
azimuth altituderows, usually a.txtfile. - Cartes du Ciel/SkyChart: the horizon list as
.txt,.csv,.horizon,.hor, or.hrz. - Stellarium:
landscape.iniand the exact file named bypolygonal_horizon_list. Attach both files separately and do not send a ZIP file. - XEphem: the horizon file with the
.hznextension. - PVGIS: the exported horizon profile as
.csvor.json. - Constant minimum altitude without a file: one number from
0through90afterHorizon profile:, for example12.5. It applies to every azimuth. - Other programs or personal measurements: a
.txt,.csv, or.jsonfile with unambiguous azimuth and altitude columns. State the azimuth convention in the mail. - NEO Planner: either put the values listed below in the mail body or attach a personally reviewed
settings_XXX.dat. That file may contain additional personal equipment and planning settings.
Every attachment must be a plain-text file no larger than 512 KiB. Allowed extensions are .txt, .csv, .dat, .hzn, .hor, .hrz, .horizon, .mask, .ini, and .json.
Mail body to complete
Only the values after the colon in the input lines are evaluated. Keep every field name and its value on one line. All explanations therefore follow the input lines.
Station: X09 Limiting magnitude: 19.5 Horizon profile: Source program: None Azimuth convention: North = 0, East = 90 (clockwise) NO-GO East: no NO-GO West: no RA East: 10 RA West: 08 Mount type: German equatorial Meridian flip / pier-side limits: please describe Only the values after the colon in the input lines above are evaluated. Leave Horizon profile empty to keep an existing profile. Use none to remove it, attached with a supported plain-text file, or one number from 0 through 90 for a constant minimum altitude at every azimuth, for example 12.5. For Source program, use None or one of the following: N.I.N.A. standard horizon text; Cartes du Ciel / SkyChart horizon text; Stellarium polygonal landscape; XEphem .hzn horizon; PVGIS horizon profile; NEO Planner settings; or Other plain-text horizon profile.
A filename, extension, or MIME declaration alone is not trusted. The local importer also checks size, raw bytes, and known binary signatures, strictly decodes text, and accepts the data only if the horizon parser produces a plausible profile. Programs, shortcuts, archives, scripts, HTML/SVG, Office and image files, double extensions, and ambiguous files are rejected. No single test can guarantee absolute malware detection, so processing remains passive and fail-closed.
NEO Planner
NEO Planner minimum Altitude is automatically converted to a flat all-azimuth profile and applied immediately after successful validation. The station code and minimum altitude are sufficient; alternatively, settings_XXX.dat may be attached. That file can contain additional personal equipment settings and should be reviewed before sending.
NEO Planner NO-GO values are mount- and meridian-dependent restrictions, not an azimuth terrain profile. A later separate implementation also needs NO-GO East, NO-GO West, the RA East/RA West meridian distances, mount type, and the applicable flip and pier-side limits. Without those details, only minimum altitude is converted; NO-GO is never silently reinterpreted as a landscape horizon. These optional mount details are documented but are not yet applied automatically to delivery decisions.
Registration
E-mail notifications are enabled on request. The registration mail must be sent from the exact address that should receive later alerts.
Only e-mail subscriptions can additionally include an MPC station code and a personal limiting magnitude. If omitted, station 500 and 20.0 mag are used. RSS/XML, JSON and Discord remain general feeds with these defaults.
The station controls the location for the Alert-MPEC visibility check. The limiting magnitude controls how faint an object may be for an alert mail; the default is 20.0 mag. To change the station or limiting magnitude later, send another mail from the subscribed address with the new values.
A valid horizon attachment is activated automatically with this registration. Without a new attachment and with an empty field, an existing profile remains unchanged. A number from 0 through 90 sets a constant minimum altitude; none removes the profile.
Choose station and magnitude Registration mail with defaults
RSS, Mail And Discord
RSS/XML and JSON provide the current bright objects from the general default selection. E-mail can additionally be filtered by personal station and limiting magnitude; Discord remains a general channel.
Use the Discord invite to join MPC NEO Alert on Discord and receive the current warnings directly in the Discord channel.
Tables
Compact orbit elements, full orbit elements, and observations are available as separate pages.