Kelso, T.S., Keynote address, presented at SMOPS-2026: International Conference on Spacecraft Mission Operations, Bengaluru, India, 2026 April 8.
Namaste, aloha awakea kākou, and good afternoon.
Mahalo and thank you to Chairman Narayanan, Dr. Somanath, Director Kumar and ISTRAC, and particularly Deputy Director Nandini Harinath, Amit Singh, and all the conference organizers who did so much to make it possible for me to be here with you once again.
I am honored to have this opportunity to talk to you on the important topic of space situational awareness (SSA)—one of the tools we use to operate safely in space and to preserve our orbital environment for generations to come. It is fundamental to everything we do in orbit.
Today, we face significant challenges as we continue to rely on the legacy SSA systems, first developed back in the 1970s and 1980s by the US, to support today’s rapidly growing and evolving presence in Earth orbit in a way that advances those goals.
Those of you who know me, know that I don’t like to complain about problems—I want to understand them and find ways to address our challenges, working together with others in the global space community. Collectively, we have done that with CelesTrak, SOCRATES, and so much more for decades. This week, I’m honored to work with ISRO and those of you here at SMOPS-2026 to find ways to turn these challenges in SSA into opportunities.
So, let’s get right into it. I think a good place to start is always with definitions, to ensure we all understand the context of these challenges.
So, we should first be clear with what we mean by SSA. In this context, we define SSA to be knowledge about the objects we put into orbit and the environment they work in. That includes knowing the orbits of these objects, their operational status, and the space weather that affects them.
At CelesTrak, we define this information in relation to our primary objective—to maintain safety of flight and mission assurance.
We need to know this information not only for active payloads, but the thousands of dead satellites and the rocket bodies used to put them in orbit, and all sorts of related debris.
And since we care about accurate orbits, we need data on space weather—or at least the atmospheric density that affects drag. And we also need to be able to accurately predict space weather, and other perturbations, which affect these orbits.
Having accurate orbits, now and in the future, is key to avoiding false positives and false negatives regarding the potential for serious close approaches.
The operational status of each object is important because it too can affect the accuracy of the orbit, as well as its ability to maneuver. And if key systems on the satellite aren’t working, such as communications or attitude control, it may be impossible to command an active satellite, or its changing attitude may affect drag in unpredictable ways.
We need to know size and mass because these affect the stability and accuracy of an orbit and not only the probability of collision but the potential consequences of one, so we can focus on the most serious close approaches.
And we need to be able to clearly identify which object is which and how to contact the operators of that object, if it is a payload.
Notice that I am not talking about space domain awareness, or SDA, that might include knowing an object’s mission and intent. Think about it like cars on the highway—we don’t need to know who is in them or what they are doing, we just need to know where they are to try to prevent accidents.
So, if you think we already have extensive data on all these things, then you might be pretty uncomfortable with what I am about to explain.
I’m going to start with one issue that many of you may not realize is even a problem—tracking satellites in Earth orbit. Sure, there are a lot more of them today than there have ever been and many more will be launched in the coming years. But the problem is more fundamental than simply having to track more objects.
In the early days of the Space Age (1950s & 1960s), there weren’t many satellites and we used radars and telescopes (optical sensors) to track them. Each operator often collected their own tracking data and produced their own orbits and did that in ways that didn’t support interchange of their data—that is, there were no standards.
The US DOD didn’t share their data with others then, anyway. And they tracked objects without the cooperation of the satellite operators (including DOD satellite operators), so they had to infer which observations went with which objects to produce good orbits, as well as determine when they maneuvered.
If a maneuver was detected, it was after the fact and could take some time to create a ‘new’ orbit. Depending upon observing conditions, an object could become ‘lost,’ which then took additional resources to relocate. The same is still true today.
As the number of objects in orbit grew, that became more challenging. DOD maintained track custody on a high percentage of objects, but that was a false metric, since the hardest ones to track were the ones that maneuvered and those were often lost. These were active satellites, many of them national security satellites of the Soviet Union.
At the same time, computer resources—CPU, memory, storage, and bandwidth—were extremely limited and drove the choice of data formats and orbital propagators. All those tools used a state vector—a single record that could be used to predict where the object would be—if it didn’t maneuver. That applies not only to the GP data, still used today with SGP4, but also in the SP (special perturbations) data in what DOD calls their High-Accuracy Catalog (HAC).
As CelesTrak began to develop SOCRATES to demonstrate the need to screen all active satellites for potentially hazardous conjunctions (close approaches), it became apparent that just using GP data would not be sufficient. We needed data that included not just the effects of the most recent maneuvers, but planned maneuvers, as well. Where would we get that?
It turns out that sometimes even the most seemingly complex problems can have pretty simple solutions. If an active satellite is maneuvering, somebody is responsible for maneuvering it and we can just ask them for their orbital data!
This was when the community first started to come together to address the space safety issue. Instead of relying on government agencies, that have a different mission and may not be fully transparent, they could work together to share data to address the problem. That led to the creation of the Space Data Association (SDA) and Space Data Center (SDC) in 2009, where operators first used ephemerides, instead of state vectors, to screen.
At first, DOD was reluctant to use this data and insisted on using their SP data—despite its limitations. They issued Conjunction Data Messages (CDMs) that relied on state vectors—without maneuvers—to share data.
By the time DOD started accepting ephemerides from satellite operators for screening, they were stuck with a format that required a state vector and force model, not an ephemeris. To make that work, they re-fit the ephemeris with their force model and used that in the CDM. The only problem was that if the data included maneuvers, fitting the data with a force model that didn’t include maneuvers would just fuzz the maneuvers up. We saw cases where the fit would produce an orbit with a perigee below the Earth’s surface—for a GEO satellite!
There was an obvious solution—change the CDM format to allow standard definitions of orbital data that would allow for those using state vectors (like DOD) or ephemerides provided by a satellite operator. That data would be part of the package in a CDM.
It has taken DOD, along with CCSDS, almost a decade to finally do that—but only part way. The new format shows an ephemeris name, if available, but doesn’t include the data or provide a URL. And there is still a partial state vector—with no defined force model—presumably for use by those who don’t have access to the ephemeris data. It seems this partial solution is not only inefficient but could potentially lead to inconsistent interpretation of the CDM.
Before moving on, I’d like to address an even more fundamental issue facing us—the accuracy of the data. For the moment, let’s assume the operator-provided ephemeris data is correct. But there are a lot of dead satellites, rocket bodies, and debris that don’t have ephemerides. How accurately are those being tracked?
CelesTrak started an effort back in 2007 to try to answer that question. At the time, we were seeing cases where the US Space Surveillance Network (SSN) lost GPS satellites—for weeks or even months—even though the GPS operators shared current data with the world on when maneuvers occurred and their new orbits. But the SSN didn’t use any of that—it couldn’t because they didn’t use the same orbital data formats and models.
So, CelesTrak created Supplemental GP (SupGP) data—which fit GPS almanacs propagated with the GPS orbital model using the SGP4 propagator to produce SGP4-compatible GP data. Despite doing that 18+ years ago, however, the SSN continues to lose GPS satellites after maneuvers to this day, with one last month (March) untracked for 20 days and another currently untracked for 10 days and off by over 500 km (as of Apr 7).
Working with satellite operators around the world, CelesTrak now processes data for 11,571* of the almost 14,985* active satellites tracked by the SSN. In fact, we download and process data for 10,190* Starlink satellites every 2 hours.
When we produce SupGP data, we always produce an RMS metric that shows the quality of each of our fits relative to the original ephemeris. Back in 2024, we developed a tool that also calculates the RMS between the GP data produced by the SSN and our SupGP data. The results are sobering.
We routinely see thousands of comparisons that are off by more than 25 km. And the DOD gets ephemeris data for almost all these objects directly from satellite operators. But they only use that data for conjunction assessment—it is rarely used for SSA.
There was an active satellite on that list that hadn’t been tracked by the SSN in 240 days—from 2025 Aug 5 to 2026 Apr 2—despite the operator sharing current data around a day old with the SSN via Space Track every day. The RMS differences for some others are over 10,000 km.
If you think the SP data will help, it is important to realize that the SSN uses that data to produce the GP data we are comparing against, using a process (eGP) similar to what we do to produce SupGP data, so the GP and SP should be within a kilometer or two RMS of each other. That means if the GP data is off by hundreds or thousands of kilometers, so is the SP data.
So, trusting the US DOD to screen your satellites may be doing nothing more than giving you a false sense of security. Before you choose to believe that maneuvering to avoid collisions based on this data has avoided lots of disasters, realize that there are 2,800 dead satellites and 2,180 rocket bodies in orbit—none of which can be maneuvered—that even though uncontrolled are not colliding with each other.
Now, realize that satellite operator-provided ephemerides aren’t perfect, either. While likely much better, don’t be confused by the fact that, although their orbits might be generated using GNSS data, that doesn’t mean the predictions in their ephemerides have meter-level accuracy. For the moment, we don’t care how well we knew where their satellites were in the past—we need to know where they will be in the coming days.
Many thousands of those active satellites are in LEO and subjected to drag. We need atmospheric density data to calculate that, but we don’t have that. We use surrogate data—like solar and geomagnetic activity—to model density. Those models are not very good and lead to orbital accuracy degrading quickly. And predictions of the surrogate data are even worse. To minimize the effects of these problems, it is important to reduce data latency—the time between when the data was generated and when it is used.
Not only is that important to reduce drag-modeling errors, it is important to make sure that low-thrust autonomous maneuvers, like those used on Starlink, are incorporated quickly and accurately.
If we’re going to use ephemerides, that means they must be produced frequently enough to minimize error growth between updates. And those using them must download and process them quickly, as well.
I already mentioned that CelesTrak processes over 10,000 Starlink ephemerides every 2 hours or so. That means we download ~120,000 ephemerides, almost half a terabyte of data—every day—just for Starlink. Add constellations like Amazon Leo, GuoWang, Qianfan, and others, and we could have 50,000+ active satellites in orbit by the end of the decade, with regular replacements and disposals occurring daily.
Even if bandwidth and storage continue to improve, there are several issues here. Not all satellite operators share their data. While CelesTrak easily updates SupGP data for over 11,000 (11,571 as of Apr 9) satellites multiple times every day, we get no data for about a quarter of the active population. It’s an easy matter to add them, but operators may believe if they know where their own satellites are, that’s enough. We’ve already seen that’s not true.
Most operators do not share their operational status. Not knowing whether an object might suddenly maneuver or that it is unable to maneuver complicates our ability to avoid collisions. CelesTrak uses orbital data from operators we work with and performs regular assessments of that data to infer operational status and then shares it with the world. Collaboratively, we could do this much more accurately and quickly. For now, CelesTrak is the only operational source of this kind of data.
Many operators don’t even share their identifications of their own satellites. CelesTrak works with many operators to ensure we know which satellites are which and then match them against SSN GP data to identify things like cross-tags. We also work with amateur radio operators to associate telemetry or assigned frequencies to orbital data.
This is a particular challenge for rideshare missions, like the Transporter-16, launched Mar 30 with 82 passengers. CelesTrak gets data from SpaceX up to deployment, but the quality of that data degrades pretty quickly. By the time data is available from the US SSN—which can be weeks later—the process of identification begins and that can take a month or more. By then, many of those satellites have failed because operators couldn’t communicate with the right objects to perform early-orbit operations or identify and resolve anomalies.
It regularly takes the SSN almost a week to identify objects from Starlink launches—CelesTrak can provide SupGP data and make identifications within 8 hours. We do the same for others who share their independent orbital data. When Planet has launched on rideshare missions, we were able to identify them within hours with SupGP data and then match them to GP data immediately when that finally became available. That can make a big difference eliminating dozens of objects on a launch with ~100 satellites in reducing the time to perform the process of elimination.
Those operators who do not share their identifications and operational status may cause other operators to be unaware of which objects might maneuver and leave those operators no way to communicate, should they have a different perspective on a close approach. Sharing this data could not only avoid a decision to maneuver unnecessarily but avoid one that might suddenly maneuver directly into the path of the other object.
If you think this isn’t a serious problem, consider these statistics. There are 1,073 unknown objects in the Space Track SATCAT—none of which even identify the object type, although many are active payloads. CelesTrak has identified 349 of these objects working with operators and others in the community. Of the remaining 421 in orbit, 339 are known to be active payloads. 303 of these objects decayed from orbit without ever being identified.
Those of you who know me and have worked with me know I do not make generalized statements without mind-numbingly quantifying how we know what we know. And one of the problems we face is that we have a large part of the space community simply choosing to believe that everything is under control and that it cannot really be that bad. I hope by now you realize how wrong that belief can be.
If you are participating in the workshop on Friday, I will show you exactly how we know how bad things are. And once you see how bad the comparison is for objects where we have ephemerides with maneuvers for, you should immediately wonder how much worse it might be for any maneuvering satellites that do not share orbital ephemerides.
Lest you be discouraged by this presentation for the need to act, you should not be. We can all work together today to share ephemeris data, and you should encourage every satellite operator you know—not just those in India—of the need to do that immediately. Our ability to maintain safety of flight is only as strong as its weakest link.
We can also work together to share operational status to ensure that is more accurate and timely. It is well past the time that caring about stockholders’ investments is worth more than preserving Earth’s orbital environment. Satellites fail and we all know this—it’s time to be up front about reporting that. The same is true with decommissioning satellites.
We can, of course, use RF systems to detect signals to help infer or confirm operational status, when not otherwise available. We need these systems more than we need more radars and telescopes.
We need the equivalent of transponders or RFID tags on every object in orbit—from cubesats to large payloads, rocket bodies, and even mission debris. Systems are being developed today that can detect Bluetooth signals from orbit. We need to turn that around, using a small self-contained, solar-powered GNSS receiver that transmits an ID, position, and velocity every second. Or coded RFID tags to stick on even the smallest cubesat.
And we desperately need data on object sizes and masses—not just to calculate the probability of collisions but also the potential consequences.
This data all exists—it just needs to be shared and made available to all. I look forward to working with ISRO, the Indian government, and those of you in the room today to turn these challenges into opportunities to grow the space economy to meet the needs of the future.
Working together, we can do so much better!
Mahalo nui loa—thank you very much—for the honor of your attention. I look forward to your questions and discussions throughout the week.
*Data as of 2025 Apr 9.