Feature request: sgp4-xp
Closed this issue · 3 comments
Some notes for the community from around the web on what this is and why it matters. In 2020 the United States Space Force (USSF) released an implementation of the SGP4-XP propagator, an advanced version of the existing SGP4 propagator stated to deliver accuracy roughly equivalent to that of the USSF’s Special Perturbations Ephemeris propagator (SPEPH) with runtimes only 50% to 100% longer than SGP4.
The AstroStds library (available at https://space-track.org) supports the SGP4-XP (Extended Precision) algorithm, which is used with TLE data in ephemeris type 4 and includes Solar Radiation Pressure modeling, the Jacchia-70 atmosphere density model, and additional perturbation modeling for Earth-based and deep-space trajectories.
These are NOT backwards compatible. Running a SGP4-XP TLE through the current SGP4 propagator will likely throw unexpected errors. Updates could be added to at least throw expected errors when parsing the 1st line of the TLE (@davidcalhoun this seems relevant to your TLE.js library).
The SGP4-XP algorithm was found to have significantly improved position accuracy compared to SGP4 for objects in medium- and high-Earth orbits. Position accuracy for objects in low-Earth orbit was comparable to that of SGP4, but velocity accuracy proved to be better which improves accuracy when propagating beyond the fit-span of the TLE generation process.
As of November, 2023, the USSF only provides SGP4-XP in compiled binary form. It may require special security considerations. Third-party binaries with no available source code may present a concern for operators wishing to include the functionality on their operational systems.
What that means to everyone on runtime compiled languages like JavaScript and Typescript is that we will not be able to use this new method or any of the TLEs with a 4 in the ephemeris column of the 1st line of the TLE. My hope is that there may be a way to use WASM to implement the binaries on the web, but my experience with using WASM for propagation has been an overall decrease in performance caused by the overhead of moving the input/results to/from WASM when doing one TLE at a time. An implementation that propagates the whole catalog on each call may be able to overcome this limitation.
If anyone spots a project looking to go the WASM route I'd appreciate a heads up.
TLDR; Without a WASM implementation or USSF decision to release the source code JavaScript and Typescript users will be out of luck when trying to use SGP4-XP TLEs and will not have the added accuracy they provide.
@thkruz Thank you so much for the explanation, that why I closed the issue after a bit more digging
The WASM implementations for SGP4-XP are now available on Space-Track.org, along with the official SGP4 WASM implementation. Both are allowed to be used / embedded / distributed in third-party apps with no restrictions.