# How to implement SGP4 C++, satellite propagator?

I would like to ask about how to implement the SGP4 code in C++ by Vallado. How can I implement the libraries that are available in https://celestrak.com/software/vallado-sw.php. I think that are the latest routines. There are some test cases, but I don't know if it would be possible to propagate the satellite and then obtain the orbital elements at the intervals of time calculated. I would also like to extract other types of data.

Has someone done this and doesn't mind sharing it?

• Have you checked the ReadMe.txt in the three SGP4 related folders (SGP4, SGP4DC, and TESTSGP4)? Can you mention how much is clear and where specifically you need help? Thanks, and Welcome to Space!
– uhoh
Jun 11 '19 at 12:16
• There is what looks like a different source for C++ on the page SGP4 Orbit Determination AIAA 2008-6770 instead. Inside that Source Code zip file AIAA-2008-6770.zip there is a very helpful-looking PDF sgp4dc CodeReadme.pdfthat might be more of what you are looking for.
– uhoh
Jun 11 '19 at 12:22
• Thank you, I already looked at Revisiting Spacetrack Report #3 AIAA 2006-6753. It is just that the program doesnt compile well and it crashes when I introduce the paramenters
Jun 14 '19 at 21:41

You don't have to implement the propagator. You can download it from space-track.org, just like you download TLEs. Go to space-track, click "Help", then click "SGP4", and arrive at https://www.space-track.org/documentation#/sgp4 . From there, pick Windows or Linux, and download compiled shared libraries of the latest SGP4 as released by the US Air Force, complete with wrappers and examples for C, Fortran, Java, Matlab, .Net, and Python.

If all you want is to use SGP4, call those DLLs, and you're done. What Vallado, Kelso, and the others who have contributed to Celestrak over the years want, is to figure out how SGP4 works, which is much harder than just using it. Based on their published error statistics, they're really close, but not quite there. Recently, a friend asked me why he was getting imaginary numbers out of propagating TLEs for some GPS satellites, and this was the answer: he was using a tool other than the official Air Force Space Command product, and when he switched to the real thing, the problem went away.

Note that "Revisiting Spacetrack" and the AIAA 2008-6770 paper have different goals. 6770 is about orbit determination by differential correction, which is much more complicated than just propagation. Propagation means you have a TLE or other representation of the orbit already at hand, and you want to use it to compute position and velocity, or other variables derived from the state, at some list of times. Orbit determination is the reverse process, of starting with a bunch of observations, such as angles, times, and distances, and using those to compute the orbit. A good introductory textbook for orbit determination is Statistical Orbit Determination by Tapley, Schutz, and Born. Vallado and Crawford give a method for making TLEs out of other data, which strikes me as perverse: if you've got a full-blown OD engine, why would you want to produce output in such a crappy form as a TLE? Just stick to coordinates that are unambiguously defined, and stay far away from TEME frames, fictitious mean objects, and the other baggage that comes with the woefully obsolete TLE.

Grady Hillhouse was able to get it working on a Nucleo F401RE development board: link. I improved on that to get it on an ESP8266 wifi module. And added some extra stuff to calculated satellite overpasses and see if the satellite is visible: project , library

This is focused on embedded devices, but it shouldn't be to hard to get it running in other environments.

• ESP8266! excellent! Any plans to implement a microPython wrapper?
– uhoh
Jul 3 '19 at 23:48