Introduction and History
David A. Vallado* Center for Space Standards and Innovation, Colorado Springs, Colorado, 80920
Paul Crawford† Crawford Communications Ltd., Dundee, DD2 1EW, UK
Richard Hujsak‡ Analytical Graphics, Inc., Exton, PA, 19341
T. S. Kelso§ Center for Space Standards and Innovation, Colorado Springs, Colorado, 80920
Abstract. Over a quarter century ago, the United States Department of Defense (DoD) released the equations and source code used to predict satellite positions through SpaceTrack Report Number 3 (STR#3). Because the DoD’s two-line element sets (TLEs) were the only source of orbital data, widely available through NASA, this code became commonplace among users needing accurate results. However, end users made code changes to correct the implementation of the equations and to handle rare cases encountered in operations. These changes migrated into numerous new versions and compiled programs outside the DoD. Changes made to the original STR#3 code have not been released in a comprehensive form to the public, so the code available to the public no longer matches the code used by DoD to produce the TLEs. Fortunately, independent efforts, technical papers, and source code enabled us to synthesize a non-proprietary version which we believe is up-to-date and accurate. This paper provides source code, test cases, results, and analysis of a version of SGP4 theory designed to be highly compatible with recent DoD versions.
This revision discusses corrections noted by readers to make the code closer to the perceived operation of the AFSPC version. It also enables an improved mode of operation designed for use with the differential correction code which is in development.
The Simplified General Perturbations (SGP) model series began development in the 1960s (Lane 1965), and became operational in the early 1970s (Lane and Cranford, 1969). The development culminated in Simplified General Perturbations-4 (SGP4), and although the name is similar, the mathematical technique is very different from the original SGP technique. The first release of the refined SGP4 propagator source code was Spacetrack Report Number 3 (Hoots and Roehrich, 1980). That release resulted from a user compatibility survey of space surveillance operational sites and official users. The magnitude of the resulting variations spurred an effort to promote better compatibility for users. The intent was to get the operational community, as well as ordinary users, synchronized with respect to the implementation. The best vehicle for this was a technical report, including the computer source code. It was designed for the widest possible dissemination. Although most of the equations were given, the use of the source code became common practice for using Two-line Element (TLE) sets.[^1]
Spacetrack Report Number 3 officially introduced five orbital propagation models to the user community — SGP, SGP4, SDP4, SGP8 and SDP8 — all “generally” compatible with the TLE data. At the time, SGP had just been replaced by SGP4/SDP4 (the latter having included deep-space perturbations). The SGP8/SDP8 model was developed to alleviate deficiencies of SGP4/SDP4 for the special cases of orbital decay and reentry. The approach provided a closed-form solution based on the general trends of orbital elements as they neared reentry, and was quite successful. However, there is no evidence to suggest that SGP8/SDP8 was implemented for operational TLE formation.
After STR#3, Spacetrack Report Number 6 (Hoots, 1986) was publicly released by North American Aerospace Defense Command (NORAD). Some researchers initially assumed this release was intended to update portions of the SDP4 deep-space routines, but the actual intention was to document HANDE[^2] and had little to do with SGP4/SDP4. Nevertheless, it provided amateur satellite trackers and researchers with a confirmation of identified deficiencies in the original validation and verification efforts. This report has not been as widely circulated as STR#3, which benefited from its early electronic availability (Kelso, 1988).
In the early 1990s, the NASA Goddard Space Flight Center (GSFC) obtained a copy of the 1990 standalone SGP4 code[^3] from project SpaceTrack as part of a study on orbit propagation models for the SeaWiFS Mission (Patt et al., 1993). In 1996—7 they released the unrestricted code on the Internet and to numerous organizations around the world involved in the SeaWiFS Mission. It confirmed changes already discovered by many independent researchers, and we refer to it simply as the “GSFC version.”
In 1998, Hoots published a history of the equations, background, and technical information on SGP4. In 2004, Hoots et al. published a complete documentation of all the equations (including the deep-space portion). These publications cover the incorporation of resonances, third-body forces, atmospheric drag, and other perturbations into the mathematical technique. We note that all published reports on SGP4 have suggested only improvements in the code used to implement it, and not any changes to the underlying theory. Thus, the equations in Hoots (2004) should be representative of the current mathematical theory. This is a fundamental and essential assumption we use in this paper.
Outside the DoD, perhaps the most comprehensive external version of the software resided with Paul Crawford. His “Dundee code” kept track of the many changes inferred by real-world observations by independent researchers, and those confirmed by DoD releases. Many of the results contained in the code pre-date matters that were later confirmed in the DoD standalone releases. We use the change history from the Dundee in this analysis.
A. Motivation
Section titled “A. Motivation”Spacetrack Report Number 3 noted the importance of using the specific equations and data input to ensure proper operation and we repeat it here. “The most important point to be noted is that not just any prediction model will suffice… The NORAD element sets must be used with one of the models described in this report in order to retain maximum prediction accuracy.” The numerous releases and modifications to the original SGP4 standalone code have made it virtually impossible to satisfy that direction today. For instance, using element sets generated with the operational SGP4 code will not reproduce the same ephemeris as the original STR#3 code (without modifications) would. Similarly, using this TLE data in another general perturbations propagator will result in completely erroneous results. Simply converting the orbital elements to an osculating state vector and propagating with a numerical propagator is equally invalid. These are consequences of the model-based parameter estimation technique of orbit determination, and are most noticeable when using general perturbation techniques.
In fact, one may infer that none of the public releases meet this criterion because Kaya, et al. (2004) says “Air Force Space Command (AFSPC) developed Astrodynamic Standard Software to emulate the operational astrodynamic algorithms used by the Space Control Center (SCC) in the Cheyenne Mountain Operations Center (CMOC)” by “extracting desired algorithms from the larger programs in the Space Defense Operations Center (SPADOC) within the SCC.” Thus, there are multiple versions of the SGP4 code even within the DoD. We must recognize that the true official code is inextricably linked and embedded within the operational computer system at CMOC (we designate it as the “operational” version). CMOC uses this operational version to produce all the TLE data that are distributed daily to worldwide users. A similar “standalone” version of the official code is maintained by technical offices within AFSPC, which, under various organizational names,[^4] published the Spacetrack series of reports. The mention of emulating the operational codes leads us to think that AFSPC routinely tests and aligns these two versions for compatibility. Spacetrack Report Number 3 report contained a snapshot of this standalone code in 1980 and is the basis for our discussion.
Kaya et al. (2001) note the lack of enforcement for early AFSPC instructions (publicly available administrative documents) concerning the use of their standalone code, and discusses changes in AFSPC policy about releasing code. We see this in the evolution of Air Force Space Command Instructions. These documents imply that models and computer codes have been extracted from larger programs, modified frequently, and that those modifications are not promulgated or available to the broader user community.[^5]
Perhaps the best motivation for the paper came from a 1998 version of AFSPCI 33-105, which stated,
The need for this instruction was identified by the lack of any HQ AFSPC procedures for releasing a certain set of software, commonly called the “astrodynamics algorithms,” used in the Space Defense Operations Center system (SPADOC 4C) for the space control mission. With no configuration control in place, various versions of executable and source code of the “astrodynamics algorithms” have been used for certain contracts and research projects.
1.1. Over the past 15 years or so, various commercial companies have produced and marketed products that these companies claim contain some of AFSPC’s astrodynamics algorithms. Not only are these claims very difficult to confirm, very few of these claims, if any, have ever been confirmed. Also, in many cases, AFSPC has no documentation that states why, when, and from whom the contractor obtained the command’s code. Consequently, AFSPC and other DoD units may have purchased their own software, often unknowingly.
1.2. Frequently, the algorithms and code contained in these products were outdated versions or had even been modified without consultation and certification from AFSPC. Additionally, the contractor rarely provides source code of their proprietary system to AFSPC so AFSPC cannot confirm whether the system’s software actually contains the AFSPC “astrodynamics algorithms.” Consequently, AFSPC cannot perform verification and validation that the astrodynamics algorithms have been utilized correctly in decision support systems, potentially critical to the space support provided to other combat units. Because of the severity of the problem with AFSPC’s astrodynamics algorithms, an overall instruction for all of the command’s software is required.
Thus today, there are perhaps more versions in use than at the time of original publication and compatibility and interoperability for users has been impacted. Many organizations routinely use a “version” of SGP4 that they received from “someone” at “sometime”. Precise documentation is often scarce. Thus, a primary motivation for this paper is to bring the community up to speed with respect to the current implementation of SGP4 and the TLE data released by NORAD.
B. Purpose
Section titled “B. Purpose”The technical community has increasingly sought more information about SGP4 because its TLE data set continues to be widely disseminated even today and represents the only ‘public’ source of data covering the majority of orbiting objects. Although many of today’s most important operations have switched to numerical processing methods, the analytical approach still has value, especially when dealing with large numbers of satellites. Examples of these include:
- Rapid searches for satellite visibility for ground stations, and generation of communication schedules.
- Programmed tracking of medium beamwidth antennas (or initial acquisition for narrow beamwidth auto-track systems) using limited CPU power embedded devices.
- Investigations into initial orbit design based on low-precision requirements, such as general sensor and/or ground station visibility statistics.
- Rapid assessment of close conjunctions (http://CelesTrak.com/SOCRATES) (Kelso and Alfano, 2005) can be made computationally efficient by pre-processing with analytical techniques, and then applying numerical techniques only to those cases that appear to warrant additional consideration.
This paper provides source code, test cases, results, and analysis of a version of SGP4 designed to be similar to the standalone code. Because the complete equations for SGP4/SDP4 are given in Hoots et al. (2004), they are not repeated here. Instead, the focus is more on the actual code development, testing methodology, and results. The references at the end of the paper attempt to list the various papers that document the SGP4 theory and practice. This will establish a consistent new baseline and permit improved accuracy of operations for worldwide users that routinely process TLE data. The TLE are routinely available from CelesTrak (http://CelesTrak.com) and AFSPC (www.space-track.org). The basic format for the data has not changed much over the years and is described in many places and we have included a discussion in the Appendix.