GCAT: General Catalog of Artificial Space Objects

Jonathan C. McDowell

Object Catalogs

Main Object Catalogs

GCAT Release 1.5.4 (2023 Oct24) | Data Update 2024 Mar 26

Primary Orbital Object Catalogs

The Standard (S) Satellite Catalog

Since the late 1950s the US government has maintained a catalog of satellites (often referred to as the SATCAT). Each satellite is given a sequential number (1 was the rocket stage from the first Sputnik). These numbers are sometimes referred to as SSN numbers.


In GCAT, each entry in the S catalog (Standard Satellite Catalog or satcat) corresponds directly to the corresponding entry in the US catalog; entry S00001 corresponds to SSN 1, entry S40000 corresponds to SSN 40000. The S catalog contains additional metadata not present in the US catalog, described later in this chapter. Note that I will use SATCAT in upper case to refer to the US catalog, while the lower case version will always refer to GCAT's S catalog.


By convention I render entries 1-99999 in each catalog with 5 digits, in this case S00001 to S99999. I then jump to 9 digits for objects 000100000 onwards (S000100000 in this case). I am optimistic that we won't reach S999999999 before I retire, so that'll be Somebody Else's Problem.


There are, as always, complications. Not infrequently, the SSN numbers associated with two space objects are swapped, or an SSN number is reassigned to a different object and the previously assigned object is now not in the catalog. However, archival TLE (Two Line Element) sets for the previous object remain associated with the same catalog number, potentially causing confusion. Although I would rather not reassign numbers, in the interests of practical compatibility the S catalog entry corresponds to the object MOST RECENTLY ASSOCIATED with that catalog number (and the GCAT is updated as required to reflect this).


The SSN number is really associated with an object tracked by the US space tracking team (currently the 18th Space Control Squadron and associated organizations). The set of TLEs associated with that catalog number, for the most part, define the SSN. The association of that catalog number with a physical object (satellite, rocket, debris) is an inference. Sometimes I disagree with the association made, and the S catalog reflects that. The harder problem is when you have, say, 3 SSN tracked objects and three known payloads, but you have no idea which is which. This can occur, for example, when three externally similar cubesats deployed from the same vehicle immediately fail, so even the satellite owners don't know which is which. In this case the SATCAT will just have them as 'OBJECT C', etc., and not attempt to make an identification. I prefer to make an arbitrary assignment of the three objects to catalog numbers but flag the assignments as uncertain. This lets me enter all the metadata such as country, owner, name etc. and so statistical counts such as number of payloads associated with a given country will come out right.


Some satellites are made up of several attached sections. When I deem that these separate sections are of sufficient interest to deserve their own catalog entry (for example because their metadata are interestingly different) I create additional entries in the auxcat (see below), and choose one of the sections to be associated with the S entry. As an example, for CORONA satellites both the CORONA payload and the attached Agena rocket stage, as well as any Agena aft rack attached payloads, get catalog entries. In such cases the S entry is given to the payload; metadata includes the information that the CORONA and the Agena remained attached until reentry.


The SATCAT associates debris objects with a particular launch but does not identify them in detail; again, I make my best guess as to the nature and origin of particular debris objects.


The US catalog is coy about certain military and intelligence satellites belonging to the US and its allies. Usually a cover name (e.g. USA 304) and a launch date are provided, but no orbital data or reentry date. Since I do not have access to secret information, I am free to speculate. Usually it's not very hard and identifications of secret satellites with particular programs and orbits mostly have a high degree of confidence.

The Auxiliary (A) Satellite Catalog.


The auxcat contains entries for objects not in the standard catalog. The catalog numbers have the prefix 'A', so the first entry is A00001.


Objects end up in the A catalog for a variety of reasons:


Sometimes objects already in the A catalog get a US SATCAT number - for example, external ISS experiments which are unexpectedly discarded into orbit at the end of their lives. In this case the object is moved to the S catalog, and its A catalog number is retired. In previous internal use of the catalog I've reused such freed A catalog entries, but with the formal release of GCAT it is my intent that any such reassigments will be recorded formally and the empty catalog entries will not be reused.


When it is clear that an object is likely to receive a SATCAT number in the near future, it is placed in the T catalog (see below) instead of the A catalog.

The Failure To Orbit (F) Satellite Catalog


The ftocat (F, Failure to orbit catalog) contains objects from failed launches which were expected to have had satellite catalog entries if the launch had been successful. The objects are upper stages and payloads from launches with `F' launch designations (e.g. 1959-F01).


Note that objects from `U' marginal-orbit launches (1959-U01 etc) are in the auxcat rather than the ftocat. Objects from pad explosions (`E' launches where no actual launch occured) are in the lcat.


I have gone to some trouble to estimate the best-guess suborbital perigee, apogee and inclination for the objects in the F catalog. If you have better data for a particular launch, please let me know.

Supporting Catalogs

The two supporting catalogs are relatively less complete and are of variable data quality, as described below. Caveat emptor - maxime quando sine sumptu est!

The Rocket (R) and Suborbital Object Catalog


The rcat contains objects whose apogee was probably above 80 km but which did not reach orbit (i.e. are not included in the orbital catalogs). The main purpose of the rcat is to record suborbital stages of orbit launch vehicles, allowing me to specify the detailed configuration of that particular flight vehicle - it gives me a place to put the type and serial number of the stages. Other metadata - mass, size, (sub)orbital parameters - are sometimes included but typically with approximate or guessed values. Orbital inclination values of zero should be ignored.


Object associated with suborbital launches are also included. The catalog is not complete in this respect and the caveats on the quality of the metadata for such objects apply even more strongly. But it gives me a place to store parameters of sounding rocket and missile payloads when I know them.

The Low-altitude (L) Endoatmospheric Object Catalog


The lcat contains objects whose apogee was probably below 80 km. Like the rcat, the main purpose of the lcat is to record the stage configuration of orbital launches, serving as a place to store the details of lower stages (first stage, strap-on boosters, etc) that did not leave the atmosphere. As for the rcat, but even more so, metadata on mass, size and trajectory are approximate or guessed and should usually be treated with skepticism. (For a few cases, such as Apollo-Saturn lower stages, the data are accurate.)


Mostly the lcat is used to store low altitude objects associated with a launch which also had exoatmospheric parts. However, some objects associated with purely endoatmospheric and mesospheric launches are included. Nevertheless, the presence of a low altitude launch in the launch lists does not guarantee its associated objects will exist in the lcat.


As noted above under ftocat, objects from launches which exploded on the pad are also included in the lcat.

Temporary Catalogs


Unlike the main catalogs, the catalog numbers in the T and C catalogs are not assigned sequentially. Currently the first object in the C catalog is C00100. The tmpcat contains objects which are (1) in orbit, and (2) do not have US satellite catalog numbers but are expected to get them in the fairly near future. This usually means objects which are aboard the ISS or a cargo ship and slated for later deployment, such as cubesats to be ejected from the Kibo module; or subsatellites to be ejected from another satellite; or objects such as the Crew Dragon Trunk which is left in orbit at the end of a Crew Dragon mission. Starlink and other megaconstellation satellites may also receive T numbers based on the 70000-series numbers used by Celestrak Supplemental TLEs before identifications are made with the SATCAT numbers.


When the T catalog object does get a US SATCAT number, its GCAT identifier is changed. The object is added to the S catalog, and its T catalog number is removed (and later reassigned). Users should therefore beware of referring to T catalog numbers - they are ephemeral and their reassignment is not formally recorded. They are a compromise, allowing the instantaneous catalog to reflect the state of things as well as possible, while avoiding reassigning any `permanent' catalog entries.


Objects which may never get catalog numbers - such as known objects which nevertheless have not been tracked - are instead put in the auxcat as described above.

The Complementary Space Object (C) Catalog

The csocat (C catalog) is a rather different construct. The objects here are those detected and observed by someone other than the US space tracking network, and not immediately identified with an existing SATCAT entry. These include objects found by hobbyist observers, astronomers,and non-US satellite tracking groups. `Analyst objects' from the US space tracking network are also included.


(I will admit that the `C' originally stood for Canadian Space Society, the initial source of hobbyist TLEs in the 1990s thanks to Ted Molczan).


Since the objects in the C catalog may or may not be also present in the S catalog, I do not include C catalog objects in my statistical summaries (of numbers of satellites launched, etc.).


C catalog entries are initially assigned the value NNA (No Number Assigned) in the Satcat number field (see column descriptions). Then, when and if a C catalog object is later identified with an S catalog entry, the actual SATCAT number is placed in the field to flag that the object is no longer `unaffiliated'. The user may therefore ignore all C catalog entries whose Satcat number is not 'NNA'.


Types of objects in the C catalog include (with catalog number ranges used as of mid-2020, but not guaranteed to be rigidly adhered to):


Since the objects in the C catalog are often of unknown origin, the launch dates and international desigations in the catalog are meaningless and should be ignored. The orbital metadata, however, are based on actual data.

Event Catalogs

The event catalogs consist of the main Event Catalog, for Earth orbiting objects, and the deep space catalogs which are only briefly discussed here.

The Event Catalog

The SATCAT data model is basically that launches put a set of objects in orbit at a given date (launch date), some of which eventually (decay date) reenter. The structure of the main GCAT object catalogs adds the idea that objects associated with a launch don't all appear on the launch date, but may instead separate from one of the other objects at a later (sep date) time. This model covers the vast majority of objects in the catalog, but some have more complex histories. The Event Catalog (ecat) is an attempt to accommodate those more complex histories.


We introduce the idea that each object in GCAT has a history composed of multiple `phases'. A new phase typically begins with either separation from a parent or attachment to a new parent. Parents may be GCAT objects or GCAT bodies (worlds). Another kind of phase is less physical: the object changes critical metadata - either its name or its owner. For a typical object, there is only one phase, which begins with separation from the parent object and ends with reentry - or is still in progress. But for some objects there are many phases involving renaming, on-orbit resale, docking and undocking, some other form of attachement to another object (e.g. EVA assembly), bringing inside or outside a space station, entering deep space, entering or leaving the gravitational sphere of influence of a new central body, landing or taking off from such a body, or returning to the Earth-Moon system. Each such phase can be characterized by:

All of this information is conveniently represented in a record identical to the normal satellite catalog entries. Thus, objects with multiple phases are represented by multiple entries with the same catalog identifier; each entry represents a phase. So that this complexity can be ignored when not useful, the main object catalogs contain only a single entry for each object, the first phase. Second and subsquent phases are stored in the ecat. The ecat records are in chronological order, although this is mainly for my convenience. Thus for example GCAT object A07959 has five phases, leading to one entry in auxcat and four entries in ecat.


The details of phases are captured in the phase-ending event type, which is stored in the `status' field of each phase record. The various options are defined in detail in the status column description.

The Deep Space Catalog


Objects which pass the EL1:4 deep space boundary at about 150,000 km from Earth are given a `D' catalog designation in addition to their entries in the S or A catalogs. The S or A catalog uses the decay date, status and destination fields to record the object's transition to deep space and its new catalog number. The corresponding DeepCat entry records the object's arrival in deep space and its departure to its next phase - reentry, entry to the lunar sphere of influence, or departure from the Earth-Moon system. The Heliocentric Register and the Lunar and Planetary Register then record subsequent phases of the object as it visits different bodies in the solar system, using its D catalog designation.


I recognize that the reassignment of a new catalog number to an object once it leaves Earth orbit may be inconvenient. A crossindex between D designations and S/A designations is provided at https://planet4589.org/space/gcat/data/cat/deepindex.html


The research behind the separate release of the Deep Space Catalog is discussed more fully at https://planet4589.org/space/deepcat . While I consider it a part of the General Catalog of Artificial Space Objects, it is a relatively self contained subset and is documented and published on an independent release schedule. The deepcat files within GCAT are kept more up to date.

Payload Catalogs

A lot of the metadata I track for satellite payloads (end of operation date, payload category, UN registration information, etc.) is not relevant for debris objects. To save space in the main catalogs, I pull out this extra information into separate `payload catalogs'. Each object from the main catalogs has zero or one record in the corresponding payload catalog.


For example, GCAT object A00489 appears in the main catalog `auxcat'. It also has a record in the corresponding payload catalog `pauxcat' with the additional payload metadata. The payload catalogs have the same name as the corresponding main catalog, except with a leading 'p', so it's pretty easy.


The payload catalogs are psatcat, pauxcat, pftocat and ptmpcat. In addition there is a plcat corresponding to the lcat, containing limited payload info for a few payloads for launches which exploded on the pad and so didn't make it into ftocat.


Of greatest interest is probably the end-of-life date information in psatcat, since a comprehensive satellite operational lifetime dataset has never before been published. The psatcat also is useful for statstical analyses since it characterizes satellites as nonprofit, commercial, civil or defense, and as communications, imaging, navigation, science, etc.

Unicode list

The usatcat file contains a list of satellite names in unicode with the correspoding GCAT catalog numbers. Only objects whose name is not in the Latin alphabet are included. This data should really just be an additional column in the payload or object catalogs but some of my older data entry software isn't completely smooth in the way it handles unicode, so it was easier for me to keep the unicode data separately in a dedicated file.


The file is a simple text file with two columns, the GCAT catalog identifier and the unicode satellite name. It is in alphabetical order of GCAT identifier, so auxcat entries precede satcat ones.

Derived Catalogs

Current Catalog

The currentcat file is provided as a useful subset of GCAT. It is largely derived from the information in satcat, auxcat and ecat. There is one record for each entry in satcat and auxcat; it is the most recent phase for each object. In the main GCAT, if you want to know the current state of an object in satcat, you also have to check through all its records in ecat to find the final one. I decided this is such a common use case that I'd do the work for you and make a 'most recent phase' catalog.


The catalog contains a subset of the fields in satcat, and a couple of new fields: the Active flag which is 'A' if the object is a currently active payload, and the first character of SatType (i.e. P for payload, R for rocket, C for component or D for debris) otherwise. and the extended status field which decodes the Status field information into a more readble text field.


Space probes have two catalog IDs, the regular JCAT for their near-earth launch phase and a Deep Space Catalog ID beginning with `D'. The currentcat has a DeepCat column which gives the `D' identifier for the object if one exists, corresponding to the object's JCAT field in the deepcat file.


There is one set of data not in the other catalogs: for objects currently in Earth orbit, the most recent available orbital data are provided in currentcat rather than the 'canonical' early orbit data provided in, e.g., satcat.

Launchlog File

The LaunchLog file is a list of all orbital launch attempts in chronological order. The data are extracted from the launch lists and the payload catalogs. It joins the launch and payload information to have one line per orbital payload with the payload name and the launch information. It replaces and supersedes the earlier launchlog.txt file on my site.