I've read through the SGP4 documentation at least 5 times, and I swear the only reference it makes to the construction of an input card is "just look at the examples". For Sgp4Prop, it looks like the only elements required (besides the TLEs) are a start epoch, time step, and stop epoch. Oh, and whatever '6P' controls. I tried changing the '0.0000' for start epoch to '10.0000', including removing the whitespace that the 1 should occupy, and instead of getting a start epoch that was TLE epoch + 10 minutes, I got a start epoch of Jan 1 1956, 00:00. There has to be some real documentation for the input cards somewhere, right?
2$\begingroup$ The key to this is knowing what the word "epoch" means. Can you add a link to the documentation that you are reading? Also, just for the heck of it, see what happens if you put in today's date in the form of decimal days since January 1, 1970, which will be some number like 19035. Or try 220209.5 (2022-02-09 12:00) $\endgroup$– uhohFeb 9, 2022 at 11:49
1$\begingroup$ Unfortunately, it's a seemingly arbitrary amount of whitespace, which is the part that's really throwing me. Trying 19035 reverted to 0.00 mins from epoch, and not an absolute time. I can't link directly to the documentation, but if you grab the SGP4 .zip from space-track.org, it includes a file called "ProgrammersGuide.pdf" which is unhelpful on the subject, and "Sgp4Prop.pdf" which hilariously glosses right over the input card portion. $\endgroup$– orbit-stuffFeb 9, 2022 at 11:57
1$\begingroup$ +1 for using historical code! There are lots of more modern implementations of SGP4 in non "card-based" languages. If what you really want is to propagate TLEs and are not so interested in Hollerith fields, that might be the way to go. But if you really want this current thing to work then stay tuned, I'm sure someone here will be able to help. I noticed that you have added the python tag, if you like python then Skyfield's EarthSatellite objects are my favorite. $\endgroup$– uhohFeb 9, 2022 at 12:06
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. :)
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 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.
2$\begingroup$ I'm accepting your answer since it's way more detailed, and you took the time to write it up, thank you! I'm trying to use SGP4 as the ephemeris source for more complex operations, so ultimately I'd like to wrap the whole process in something that allows me to build the input, and get back a parsed output from a single function call. The skyfield stuff looks a little too specialized for observation and not generally producing arbitrary J2000 ephem. Do you know of something open-source I can look at for inspiration? $\endgroup$ Feb 10, 2022 at 1:05
1$\begingroup$ @orbit-stuff Thank you, my pleasure. My response to your follow-up question was too big to fit in a comment, so I added it to the answer. $\endgroup$– Ryan CFeb 10, 2022 at 18:17
I'm going to write out this answer for anyone else who might be furiously googling in the future:
The first line of the input card for Sgp4Prop is a "6P card". It's parsed by timefunc.dll, and you can find the documentation in Documentation/librarydocuments/timeFunc.pdf. Columns 1-15 are an absolute julian date (YYDDDHHMMSS.SSS), or you can use 10-15 as a relative time, for start time in minutes since epoch. It's unclear if that can be negative. Columns 16-20 is the step size, in minutes. 22-36 is an absolute stop, again in YYDDDHHMMSS.SSS. Alternatively, 31-36 is a relative offset in minutes. 79-80 must contain "6P".
2$\begingroup$ hah! beat me by a minute. kudos for answering your own question! $\endgroup$– Ryan CFeb 10, 2022 at 0:30