Return to Answer

The purpose of SGP4 is to turn TLEs, which are easy to get but complicated to interpret, into a more immediately useful form, like position and velocity vs. time. Once you've done that, unfortunately, the error inherent in a TLE's approximations is baked into anything else you might do with it, as discussed in Accuracy of converting from TLE/Orbital Elements to Cartesian if used for other propagator?

The purpose of SGP4 is to turn TLEs, which are easy to get but complicated to interpret (see, for example, Mean to Osculating conversion for non-J2 averaged elements , Confused about SGP4 implementation published by celestrack , and How to construct $B^*$ drag term in TLE?), into a more immediately useful form, like position and velocity vs. time. Once you've done that, unfortunately, the error inherent in a TLE's approximations is baked into anything else you might do with it, as discussed in Accuracy of converting from TLE/Orbital Elements to Cartesian if used for other propagator?

The purpose of SGP4 is to turn TLEs, which are easy to get but complicated to interpret, into a more immediately useful form, like position and velocity vs. time. Once you've done that, unfortunately, the error inherent in a TLE's approximations is baked into anything else you might do with it, as discussed in Accuracy of converting from TLE/Orbital Elements to Cartesian if used for other propagator?

The most complete and most thoroughly-tested open-source orbit package I know of is OreKit. It is written in Java rather than Python, but there are Python wrappers for it out there. Its biggest drawback is that it's very low level, so there's a lot of assembly required, but they have some really good contributors. For example, the US Naval Research Lab published a paper favorably comparing OreKit's ocean tide models with NRL's own in-house tool: Evan Ward, John Warner, and Luc Maisonobe (2014). Do Open Source Tools Rival Heritage Systems? A comparison of tide models in OCEAN and Orekit. AIAA/AAS Astrodynamics Specialist Conference, DOI 10.2514/6.2014-4429.

I completely agree, the 6P card input is very annoying to use and its documentation is terrible. Here is an example of how to use it, as I did in preparing my answer to Failing at getting apogee and perigee from TLE The input file I made to use with space-track.org's Sgp4Prop.py, with the 6P "card" on the first line and the TLE on the second and third lines, is this:

21354165831.482 0001 21358165831.482                                          6P
1 25544U 98067A   21356.70730882  .00006423  00000-0  12443-3 0  9994
2 25544  51.6431 130.5342 0004540 343.5826 107.2903 15.49048054317816

Note in particular the "6P" all alone by itself way off in the corner. It must be in exactly that position, or nothing will work properly, so it helps to use a text editor that can display the column number your cursor is in. I use emacs, and its M-x column-number-mode is zero-based, so I put the 6P in columns 78 and 79; if your text editor starts counting columns with 1 rather than 0, you need to put your 6P in columns 79 and 80.

The next step is the time conversion. The TLE epoch is 21356.70730882, but that is not the same format as the 6P line! The TLE uses YYDDD.dddddddd, where YY is two digit year, DDD is three digit day of year, and .dddddddd is fractional day to 8 digits. To write that same time in the 6P card format, you must change to YYDDDHHMMSS.sss, where YY and DDD are the same, but HHMMSS is hours, minutes, and seconds of the 24 hour clock, with .sss as fractional seconds to three digits. 0.70730882 of a conventional mean solar day (86400 seconds) is 61,111.482 seconds, which works out to 16 hours, 58 minutes, and 31.482 seconds. To give the same two days before and two days after that the plot's in uhoh's answer to that question use, I added and subtracted 2 from the DDD part, giving 21534165831.482 and 21358165831.482 as the start and stop times. The 0001 between them is minutes between successive outputs. 0001 is the smallest number I've been able to use, and 60 seconds is pretty good for lots of purposes. The three zeroes are there to keep the spacing correct.

Now, you don't have to use 6P cards to use the space-track.org SGP4 library. It's just that the sample program they provide to show you how to use their Python code happens to choose this weirdly undocumented way of reading its time inputs. For serious use, I find it necessary to wrap their Python wrapper in another, more Pythonic wrapper, that for example has functions that return ordinary lists of floats, rather than force you to pre-declare everything in ctypes array objects. I put up with the 6P time format for things I post here, mainly so that I can remember how to answer questions like this. :)

I completely agree, the 6P card input is very annoying to use and its documentation is terrible. Here is an example of how to use it, as I did in preparing my answer to Failing at getting apogee and perigee from TLE The input file I made to use with space-track.org's Sgp4Prop.py, with the 6P "card" on the first line and the TLE on the second and third lines, is this:

21354165831.482 0001 21358165831.482                                          6P
1 25544U 98067A   21356.70730882  .00006423  00000-0  12443-3 0  9994
2 25544  51.6431 130.5342 0004540 343.5826 107.2903 15.49048054317816

Note in particular the "6P" all alone by itself way off in the corner. It must be in exactly that position, or nothing will work properly, so it helps to use a text editor that can display the column number your cursor is in. I use emacs, and its M-x column-number-mode is zero-based, so I put the 6P in columns 78 and 79; if your text editor starts counting columns with 1 rather than 0, you need to put your 6P in columns 79 and 80.

The next step is the time conversion. The TLE epoch is 21356.70730882, but that is not the same format as the 6P line! The TLE uses YYDDD.dddddddd, where YY is two digit year, DDD is three digit day of year, and .dddddddd is fractional day to 8 digits. To write that same time in the 6P card format, you must change to YYDDDHHMMSS.sss, where YY and DDD are the same, but HHMMSS is hours, minutes, and seconds of the 24 hour clock, with .sss as fractional seconds to three digits. 0.70730882 of a conventional mean solar day (86400 seconds) is 61,111.482 seconds, which works out to 16 hours, 58 minutes, and 31.482 seconds. To give the same two days before and two days after that the plot's in uhoh's answer to that question use, I added and subtracted 2 from the DDD part, giving 21354165831.482 and 21358165831.482 as the start and stop times. The 0001 between them is minutes between successive outputs. 0001 is the smallest number I've been able to use, and 60 seconds is pretty good for lots of purposes. The three zeroes are there to keep the spacing correct.

Now, you don't have to use 6P cards to use the space-track.org SGP4 library. It's just that the sample program they provide to show you how to use their Python code happens to choose this weirdly undocumented way of reading its time inputs. For serious use, I find it necessary to wrap their Python wrapper in another, more Pythonic wrapper, that for example has functions that return ordinary lists of floats, rather than force you to pre-declare everything in ctypes array objects. I put up with the 6P time format for things I post here, mainly so that I can remember how to answer questions like this. :)