How to manage ephemeris
Uploading/submitting OEM Ephemeris data
How to upload your ephemeris
Satellite operators may submit ephemeris data to NSpOC orbital analysts by uploading Orbital Ephemeris Message (OEM) files.
Satellite operators may upload OEM files via:
- The ‘Upload your ephemeris data’ link on the relevant satellite page on the MSH site
- Via API using the POST/v1/ephemeris endpoint
How to upload your ephemeris
The OEM file must meet MSH naming conventions in order to allow MSH to process the data.
The format of a filename is as follows:
<DataType>_<SatelliteNumber#>_<CommonName>_<DayTimeGroup>_<Operational/Special>_<MetaData>_<Classification>.<FileExtension>
‘SatelliteNumber#’ (referred to in other Space-Track publications as ‘Catalog#’) refers to the satellite’s NORAD ID. If this is not included, the file will be rejected.
Examples:
- MEME_25544_ISS_1651200_oper__unclassified.txt
- MEME_25544_ISS(ZARYA)_1651200_operational_nomnvr_UNCLASSIFIED.txt
- MEME_25544_ISS_1651200_special_mnvr01_Unclassified.txt
- MEME_UCN01_SPACESAT1_1651200_special_burn01_Unclassified.txt
- MEME_799500234_Sat1_1651200_special_separation_unclassified.txt
This is aligned with Space-Track requirements for ephemeris uploads to Space-Track. Further information is available here:
Space-Track (2023). Spaceflight Safety Handbook for Satellite Operators. Version 1.7. https://www.space-track.org/documents/SFS_Handbook_For_Operators_V1.7.pdf. See pp.25-26.
File format and content
The file uploaded must not exceed 20MB.
MSH conducts additional data validation against uploaded files, and will reject files in which the following fields are not present:
- CCSDS_OEM_VERS
- CREATION_DATE
- ORIGINATOR
- OBJECT_NAME
- OBJECT_ID
- CENTER_NAME
- REF_FRAME
- TIME_SYSTEM
- START_TIME
- STOP_TIME
MSH will also reject files which do not meet the following additional requirements:
- NORAD ID in file name must match the NORAD ID of: the satellite page on which ephemeris is uploaded, or the object_id provided if ephemeris is uploaded via API.
- Satellite with provided NORAD ID must be in Monitor Space Hazards database
- META_START/META_STOP tags must be in ephemeris file in header section in proper order (START before STOP)
Beyond these MSH-specific requirements, it is strongly recommended that the format of the OEM file be aligned with Consultative Committee for Space Data Systems (CCSDS) Recommended Standards. Further information is available here:
CCSDS (2023). CCSDS 502.0-B-3 Orbit Data Messages Recommended Standard (Blue Book). Issue 3. https://ccsds.org/publications/bluebooks/entry/3073/. See Section 5.
MSH aims to align with the most up-to-date guidance on OEMs, so this page will be updated if CCSDS or Space-Track publish version updates to their guidance.
Decisions
A range of orbital data message (ODM) file types are available. MSH uses the OEM file type for the following reasons:
- The OEM is appropriate for data exchanges that involve automated interaction (e.g., computer-to-computer communication when frequent, fast automated time interpretation and processing is required)
- The OEM is appropriate for data exchanges that require higher fidelity or higher precision dynamic modeling than is possible with other ODM file types.
This aligns with CCSDS guidance. Further information is available here:
CCSDS (2023). CCSDS 502.0-B-3 Orbit Data Messages Recommended Standard (Blue Book). Issue 3. https://ccsds.org/publications/bluebooks/entry/3073/. See Section 2.