by Dr. T.S. Kelso
2023 Nov 24
Updated 2026 Jun 15
Twenty-five plus years ago—from 1994 to 1998—I wrote a series of articles for the "Computers & Satellites" column of Satellite Times. They covered a variety of topics from how to transform between various coordinates systems used in orbital mechanics to how to find the rise and set times of a satellite.
But one of the assumptions in many of those articles was that you had a way to calculate the position of a satellite. CelesTrak made the GP data easily available in the TLE format and provided documentation on the SGP4 orbital propagator needed to use that data, but originally the source code was only available in FORTRAN and many users had no way to use it without porting it to another language first. And there was no way at the time to run SGP4 and the associated algorithms needed to use it effectively on a web server.
Today we can run complex algorithms like SGP4 using JavaScript. JavaScript code is actually run on the user's machine not the server, which means CelesTrak can provide the software and the user can download and run it on their local machine. That allows CelesTrak to efficiently provide validated code to support thousands of users at a time. Of course, that means the user will experience the best performance if they have good network bandwidth (to download the software), a fast machine with ample RAM, and use a modern browser that provides an efficient implementation of JavaScript.
These tutorials will provide a framework for how to apply basic orbital mechanics techniques to not only help users better understand the topics, but to be able to use the software as a way to validate their own software development efforts.
The plan is to cover these topics:
SGP4: While there are many ways to propagate an orbit, the orbit propagator must match the data. Since the current data on CelesTrak is all either GP (General Perturbations) data produced by 18 SDS fitting US Space Surveillance Network (SSN) observations with SGP4 or SupGP (Supplemental GP) data produced by CelesTrak fitting satellite operator-provided data (e.g., Starlink ephemerides) with SGP4, having the right implementation of SGP4 seems like the place to start.
While there are many packages available that implement the version of SGP4 described in the paper "Revisiting Spacetrack Report #3", written by my colleagues Dave Vallado, Paul Crawford, Dick Hujsak, and me back in 2006, they aren't always configured correctly. And there are a lot of implementations of unknown pedigree. We will use a version of satellite-js that has been validated to match the official USSF version of SGP4 [requires being logged in on an account on space-track.org] to 7 decimal places (0.1 mm) to show how to validate your code and how to correct some common misconfigurations to get the same results. We will also provide an example to show how to properly use SGP4 to maximize computational efficiency and then benchmark your results.
Ensuring you are starting with a valid version of SGP4 is paramount to support chasing down those inevitable bugs in any software development effort!
Example Applications: SGP4 outputs position and velocity in the TEME (True Equator Mean Equinox) coordinate system. While many applications require knowing the position relative to an object or observer in another coordinate system—which requires a coordinate transformation—there are some applications that only use GP orbital data and can all be done in the TEME frame.
Example Application #1: One of these key applications is conjunction assessment, which requires finding the closest approach between two objects. This example will show how to calculate the range between two satellites and then how to implement a simple binary search to find the point of closest approach. And we will see that the binary search is quite useful in a variety of other applications, such as finding rise and set times.
Example Application #2: Another is in performing a 'consistency' check of GP or SupGP data. That is, looking at the GP data for a particular object over the past 30 days to see how the prediction at epoch compares to the predictions at all of the other epochs as a function of time since epoch. This can give a good idea of the uncertainty involved with the GP data for a particular object and can be a useful tool for a variety of applications.
Orbital Coordinate Systems: If you want to compare objects that use different coordinate systems, then you will need to know how to convert them to a common reference frame. An example might be to find the position of a satellite relative to an observer on the Earth's surface. An orbit using GP data will produce results in the TEME coordinate system whereas an observer on the Earth's surface might use geodetic latitude, longitude, and altitude relative to the WGS84 ellipsoid. You can convert either object to the other object's reference frame, but we'll see it can be much more efficient to use the frame that requires the fewest transformations.
In the original "Computers & Satellites" articles on "Orbital Coordinate Systems", we talked generally about "ECI" (Earth-Centered Inertial) and "ECF" (Earth-Centered Fixed), but we will need to be more specific to ensure results which can be useful in standard operations. We will look at ECI frames (e.g., TEME and J2000/GCRF), ECF frames (e.g., ITRF in Cartesian and geodetic latitude, longitude, and altitude coordinates), and body-relative frames (e.g., topocentric azimuth, elevation, and range).
Example Application #3: We will tie together all of the previous work into a tool to predict visible passes vs. all passes for a satellite and observer. So, we will start by calculating the satellite's position using SGP4 and convert the observer's location to TEME and perform a binary search to find rise and set times.
And Then... Certainly there is a lot more to explore in these tutorials, so we will just have to see once we get this far. But the goal is to provide you the framework and tools to go off and create great tools, not for me to do that all for you. So, stay tuned!