GCAT: General Catalog of Artificial Space Objects

Jonathan C. McDowell

Definitions

SatType scheme

Associated with each object in the General Catalog is a 12 byte SatType string that provides a classification of the object. Each byte in the string has a set of defined meanings. (As of late 2022, byte 12 is unused). The SatType data in principle allows one to select subsets of certain kinds of object.


The SatType string can be found in the table column called simply `Type'.


For each object, the SatType string in the entry for the first phase for that object applies to the whole history of the object. If the type is different in a later phase, that's probably a data entry error.


The byte layout is as follows:
ByteContents
Byte 1Coarse Type (payload, rocket, debris)
Byte 2Type modifier
Byte 3Attach flag
Byte 4Subtype
Byte 5Orbit flag
Byte 6Human spaceflight subset
Byte 7UN registration flag
Byte 8Failure flag
Byte 9Uncertain ID flag
Byte 10Annotation flag
Byte 11Group control flag
Byte 12: Not yet used
In each byte, an empty (null) value is represented by blank or dash (the dash is used to help me visually line up the elds during data entry).

Byte 1 (Coarse type)

The coarse type allows us to divide the catalog into payloads, rocket stages, and debris. We consider two kinds of debris: components, which are subsystems of the parent object, usually but not necessarily designed to separate, and fragmentation debris, pieces resulting from an object breakup (propellant explosion, weapons test, self-destruct, collision, insulation blanket separation).


ValueMeaning
PPayload (for orbital attempt)
CComponent
RLaunch vehicle stage
DFragmentation debris
SSuborbital payload (e.g. sounding rocket payload or missile reentry vehicle)
XCatalog entry that has been deleted (used in auxcat etc.)
ZSpurious catalog entry (was in SATCAT, perhaps in TLEs, but there was no real object)

Byte 2 (Type modifier)


The Byte 2 entries modify the Byte 1 entries (and are not independent of them). Here I tabulate the combined byte 1/2 values and their meanings. (cases where byte 2 is blank are not listed).


Byte 1-2 ValueMeaning
PAAlias entry.
PHSpaceship with humans aboard at launch.
SHSpaceship with humans aboard at launch (suborbital).
SXSuborbital, special cases not currently further defined
PP or CP or SPSpaceship with pressurized cabin, but without humans at launch.
PX: Not in standard list of satellites.
R1 to R5Stage number for launch vehicle stage.
CCCargo placeholder for mass accounting.
CXComponent not to be included in certain standard lists
CDDeployer for separately integrated payload


PA: The A (alias) modifier is used for special records representing a phase where the satellite is leased temporarily or jointly owned. This phase type is special in that its time period overlaps another phase. An example is object S23779 (Palapa C1, renamed HGS-3 in Nov 2000) From Dec 2000 to Jan 2003 its capacity was leased to Turk Telecom which called it Anatolia 1. The HGS-3 entry is tagged with SatFlag equal to P (standard payload) while the Anatolia 1 entry covering an overlapping time period is tagged with SatFlag equal to PA to denote that it's a secondary or alias entry that may be ignored.


PP: The P modifier is used for spaceship test flights without crews, pressurized sections of cargo ships, and space station modules.


PX: The X modifier is used to denote `non-standard payloads'. What is a payload and what is just a component? I take a broader view of `payload' than most satellite lists do. Some examples of `PX' types:


CC is used for `down cargo' for space stations returned to Earth or destroyed in cargo ship reentry. Note that we usually don't know the launch date of `down cargo'.


The D modifier (CD) is used for separately integrated deployers. The D flag has been added to reflect the emergence of intermediary companies like Nanoracks and Spaceflight which sit between the payload owner and the launch provider and manage the integration of customer payloads Note that byte 4 has a V value for 'deployer/clamp band' which is more general and does not imply a separate integration - it includes things like the CRRES canisters or the Shuttle PAM-D ASE. (Well, it's an interesting question whether those count as equivalent to a Nanoracks deployer, but I think the hardware and integration were done by NASA - I could be wrong.)


Objects with a D flag in byte 2 are usually not separate satellites but attached to a parent object (e.g. launch vehicle stage). They are therefore usually in the A (auxiliary) catalog.

Byte 3 (Attach flag)

This flag describes why this object is attached to its parent object:


Byte 3 ValueMeaning
APermanently attached component or payload
FStuck attached by mistake
SExpected to separate in future
TNever flew free but transferred
IInternal


F indicates that the object was intended to separate but failed to do so. S denotes that the object is expected to separate at a later date. T is mostly used for hardware that is transferred from the exterior of one object to another during a spacewalk or using robotic arms.


I is used for entries representing hardware that remains internal to one or more host spacecraft, possibly being transferred between them. Entries of this sort that I keep track of include EVA spacesuits not actually used on an EVA; cubesat dispensers used on ISS; and special entries used to do mass accounting of upward and downward space station cargo. In the future I'm considered adding entries for human space travellers, who would also be internal (either to a spaceship or a spacesuit).

Byte 4 (subtype flag)

This byte is used to categorize objects more finely than the byte 1-2 specification. It is useful for gathering statistics about different kinds of debris. Each value is usually only used with a subset of possible byte 1 values as listed below (however, these restrictions are not absolute).


ValueMeaningAllowed B1 values
APayload adapter (e.g. SYLDA)., support structures, interfacesC
BBattery explosion debrisD
CPassive calibration satellites, test objects or chaffP, C
DDummy satelliteP
ESpacesuit on tethered spacewalkP (PX)
FFairings and other coversC
GGeneral, miscellaneous debrisC, D
HHuman spaceflight relatedP,C
IImpact (accidental collision)D
JAnomalous debris (insulation, soft material, ablated material)C, D
KPossible solid motor slagD
LSeparated from vehicle after landing (rovers, etc)P, C
MJettisoned motor or tankC
NNuclear reactor core or coolant blobC, D
OUnknown debris released at orbit insertion
PPropulsion related, residual-propellant breakupD
QAerodynamic breakup at low perigeeD
RReentry vehicleP
SSubsatellite or subpayloadP
TEjected section of payloadC
UUntethered EVAP (PX)
VEjection mechanism (deploy canister, clamp band)C
WWeapons test, ASAT debrisD
XDebris of unknown natureC, D
YDespin (yo-yo) deviceC
ZBreakup debris from on-board destruct deviceD
Note that code K used to be used for interstages but that meaning has now been merged with code A.

Byte 5 (orbit flag)

This flag is used to note special cases related to the object's trajectory. The flag is blank for normal SATCAT entries except for the deep space ones.


Valuemeaning
DDeep Space or escape
EDestroyed in pad explosion
FFailed to reach orbit
LActive on planet surface during this phase
MMissing from SATCAT by mistake (EXPRESS, IXV)
OOrbital-Energy but Non-Orbit
PPartial orbit - reached legit orbit but deorbited after less than 1 rev
RReentry orbit: objects that were attached and separated in post-deorbit-burn suborbital trajectory
SNear-Orbit (marginally suborbital)
TTransient orbit - separated just (perhaps seconds) before deorbit
VEscape energy but not deep space
XExtra catalog entry for extraterrestrially launched object
ZLaunch from extraterrestrial object, recataloged with new D series number.

Byte 6 (human spaceflight/special group flag)

This flag is present to support easily identifying all objects in the given categories, such as all satellite deployments from ISS. As such it serves a somewhat different purpose from the byte 2 values. At the moment I've only filled in values for space stations and Shuttle. `Station' refers to any space station, or indeed any composite space object.


Valuemeaning
IStation program, general
CStation major non-module component
DStation deployable subsatellite
EStation EVA related equipment
GPseudo-entry used for station generic cargo mass accounting
MStation module
SSpace Shuttle program or Shuttle payload or component
TPiece of visiting vehicle
UVisiting vehicle or rocket stage deployed satellite
VStation visiting vehicle

Byte 7 (UN registration flag)

This flag notes issues with UN registration for objects that are not standard payloads. Standard payloads (Byte 1-2 = P) should be registered, and the presence of a UNReg entry in the corresponding payload catalog tells you if they are or not (as of the last time I checked the UN site, at least). Non-standard payloads (Byte 1-2 = PX, see the byte 2 discussion) are more complicated. I have attempted to decide whether standard practice implies they should have been registered based on comparison with similar payloads.


ValueMeaning
UIs, or should be, UN registered even though not a standard payload.
XWas UN registered but should not have been.


For example, object A06499, the Canadarm-2 on the ISS, is not a standard payload and has no SATCAT entry. Nevertheless it was registered with the UN. A05668 Fasat-Alfa was a satellite that failed to separate from its parent satellite. It doesn't have a separate SATCAT number from its parent S23657 Sich-1, so it is a `PX' nonstandard payload; but it was registered by Chile, while Sich-1 was registered by Ukraine. Byte 7 is set to U.


Object A05597 EXPRESS completed several orbits of the Earth. It is a `PX' nonstandard payload because the US tracking system failed to catch it, and it doesn't have a SATCAT number. Nevertheless Germany should have registered it with the UN and did not. Byte 7 is set to U.


On the other hand, A06874 Celestis-04 Error was registered with the UN but should not have been, since it was removed from the rocket before launch and never got to space. Byte 7 is set to X.


Object A07634 ELC-1 is a logistics carrier launched on the Shuttle and later attached to the ISS. Although the US has usually registered ISS pressurized modules, other similar minor ISS components (such as the other ELCs and the major truss segments) have not been registered, so for consistency ELC-1 shouldn't have been registered either. Byte 7 is set to X.

Byte 8 (Failure flag/Constellation status flag)

An asterisk in this field records which rocket stage was to blame in an orbital launch failure. An asterisk in byte 8 says that this object was, broadly speaking, the culprit.


For a debris object, a numeric value in this field (1,2, etc) groups objects in a particular debris cloud for a launch which has multiple associated debris events. (I have only used this a few times.)


Other values indicate different kinds of payload failure (or success) and have been added to support analysis of the Starlink constellation.


ValueMeaning
*This object was the one that failed during launch.
ASatellite ascending: orbit raising to op orbit (or lowering from high drift orbit)
DSatellite in plane drift orbit
FSatellite failed early in mission, before reaching operational orbit ("screened")
GSatellite retired to a graveyard orbit of some kind
LSatellite removed far from operational constellation by lowering or raising orbit
MSatellite failed in operational orbit and is undergoing uncontrolled decay - non manueverable
OSatellite is active in operational orbit
RSatellite reentered after active orbit lowering
SSatellite was used for special tests outside of main constellation
TSatellite removed slighly (and possibly temporarily) from operational constellation by lowering or raising orbit a little
USatellite apparently malfunctioning, held in intermediate orbit for debugging?

Byte 9 (ID flag)

This flag notes problems with the identification of the object.
ValueMeaning
?The association of this satellite with this catalog number is a guess because JSpOC has not yet assigned a name. ID may change in future.
+Starlink filing with FCC reports this satellite is out of service but could still maneuver, at the time of filing.
*Starlink filing with FCC reports this satellite is out of service and can not maneuver.
mMultiple objects. This entry is a placeholder for a known debris event where no debris has yet been cataloged by DoD.
CUS government orbital data for this object are secret.
cOlder US government orbital data for this object were secret, but current data is public.
UThis object is a cargo item on ISS (or other station) and has been assigned to a likely cargo launch but the actual launch for this object is not known.
DThis object is a cargo item on ISS (or other station). The return date is uncertain and I've made a guess at which ship it went down on.
XWe don't know which launch this object is from, so the launch date is unknown (and other parameters may also be unknown).
sDisagreement between TLE and SupTLE data (true for S45139)

Byte 10 (Annotation flag)

This byte is used to control display options in certain software associated with the database. It should be ignored by other software.


At present, possible values of this byte are r,g,b,c,m,y,k indicating colors chosen for data associated with the specific satellite in automated plots, e.g. of altitude vs time.

Byte 11 (Group control flag)

This byte is used to include or exclude objects from the debris clouds in the debris cloud catalog.
ValueMeaning
+Object included in debris cloud analysis
-Debris object not counted as part of debris cloud