Frequently Asked Questions: TwoLine Element Set FormatBy Dr. T.S. Kelso 



Frequently Asked Questions: TwoLine Element Set FormatBy Dr. T.S. Kelso 
As I sat in my hotel room answering email on a recent trip to Washington, DC, I realized that a column of this nature was probably long overdue. Most of the questions I receive are the result of the lack of publicly available documentation on the NORAD SGP4/SDP4 orbital model and the twoline orbital element sets, although a few deal with issues involved in the administration of the orbital data maintained on the Celestial WWW site. In this column, I hope to provide a single source of answers to what I've seen to be the top dozen or so questions on this topic. Here is a summary of the questions I'll answer in this and the next column:
I'll answer the first four questions in this column and the remainder in the next one.
What is the format for the twoline element sets? A NORAD twoline element set consists of two 69character lines of data which can be used together with NORAD's SGP4/SDP4 orbital model to determine the position and velocity of the associated satellite. The only valid characters in a twoline element set are the numbers 09, the capital letters AZ, the period, the space, and the plus and minus signs—no other characters are valid.
Of course, not all valid characters can be used in all columns within the element set. Figure 1 shows what type of character is valid for each column. Columns with a space or period can have no other character. Columns with an 'N' can have any number 09 or, in some cases, a space. Columns with an 'A' can have any character AZ or a space. The column with a 'C' can only have a character representing the classification of the element set—normally either a 'U' for unclassified data or an 'S' for secret data (of course, only unclassified data are publicly available). Columns with a '+' can have either a plus sign, a minus sign, or a space and columns with a '' can have either a plus or minus sign (if the rest of the field is not blank).
1 NNNNNC NNNNNAAA NNNNN.NNNNNNNN +.NNNNNNNN +NNNNNN +NNNNNN N NNNNN 2 NNNNN NNN.NNNN NNN.NNNN NNNNNNN NNN.NNNN NNN.NNNN NN.NNNNNNNNNNNNNN
Figure 1. TwoLine Element Set Format
[Editor's Note: See ADCOM/DO Form 12 from Spacetrack Report Number 3 for detailed format.]
Further restrictions are placed upon the values in each column as the individual fields of data are defined. Tables 1 and 2 define each of the individual fields for lines 1 and 2, respectively. Many of these bear additional explanation.
Table 1. TwoLine Element Set Format Definition, Line 1
Field  Column  Description 
1.1  01  Line Number of Element Data 
1.2  0307  Satellite Number 
1.3  08  Classification 
1.4  1011  International Designator (Last two digits of launch year) 
1.5  1214  International Designator (Launch number of the year) 
1.6  1517  International Designator (Piece of the launch) 
1.7  1920  Epoch Year (Last two digits of year) 
1.8  2132  Epoch (Day of the year and fractional portion of the day) 
1.9  3443  First Time Derivative of the Mean Motion 
1.10  4552  Second Time Derivative of Mean Motion (decimal point assumed) 
1.11  5461  BSTAR drag term (decimal point assumed) 
1.12  63  Ephemeris type 
1.13  6568  Element number 
1.14  69  Checksum (Modulo 10) (Letters, blanks, periods, plus signs = 0; minus signs = 1) 
Column 1 of each line of the twoline element set indicates the line number (and hence the format) for that line. The next field on each line (fields 1.2 and 2.2) indicates the satellite number—actually, the NORAD Catalog Number—of the object the data is for. The NORAD Catalog Number is a unique identifier assigned by NORAD for each earthorbiting artificial satellite in their SATCAT (Satellite Catalog). For a valid twoline element set, fields 1.2 and 2.2 must be identical. As mentioned above, field 1.3 indicates the security classification of the data—all publicly available data will have a 'U' in this field to indicate unclassified data.
The next three fields—fields 1.4 through 1.6—define the International Designator of the object. This identifier is an additional unique designation assigned by the World Data CenterA for Rockets and Satellites (WDCAR&S) in accordance with international treaty (1975 Convention on Registration of Objects Launched into Outer Space). The WDCAR&S works together with NORAD and NASA's National Space Science Data Center (NSSDC) in maintaining this registry. Although there have been some changes in format since it was first used back in the late 1950s (see "Space Surveillance" in Satellite Times Volume 4 Number 1), the International Designator indicates the year of the launch (field 1.4 only gives the last two digits), the launch of that year (field 1.5), and the piece of that launch (field 1.6) for each object. These three fields can be left blank, but all must be present if any is. Finally, field 1.6 can be either right or left justified—the latter is preferred.
As an aside, there are some significant differences between NORAD's Catalog Number and the International Designator. For example, NORAD assigns a catalog number based upon when the object was first observed, whereas the International Designator is always tied to the original launch. For example, the 81^{st} launch of 1968 carried four payloads into orbit: OV25, ERS 21 and 28, and LES 6. Together with the Titan 3C transtage rocket body, these objects were assigned International Designators 1968081A through E and Catalog Numbers 03428 through 03431. Just this past October, however, NORAD cataloged two additional pieces associated with this launch as Catalog Numbers 25000 and 25001—they have the International Designators 1968081F and G.
The next two fields (fields 1.7 and 1.8) together define the reference time for the element set and are jointly referred to as the epoch. Field 1.7 is the twodigit year (more on this later) and field 1.8 is the day of that year. The epoch defines the time to which all of the timevarying fields in the element set are referenced.
While talking about the epoch, this is perhaps a good place to answer the other timerelated questions. First, how is the epoch time format interpreted? This question is best answered by using an example. An epoch of 98001.00000000 corresponds to 0000 UT on 1998 January 01—in other words, midnight between 1997 December 31 and 1998 January 01. An epoch of 98000.00000000 would actually correspond to the beginning of 1997 December 31—strange as that might seem. Note that the epoch day starts at UT midnight (not noon) and that all times are measured mean solar rather than sidereal time units (the answer to our third question).
How will the Year 2000 be handled? Right now, probably the most common question I'm asked is how years beyond 1999 will be handled in the twoline element sets. Actually, the use of a twodigit year affects both fields 1.4 and 1.7, although the impact of the latter is definitely much more important. To date, I have been unable to secure an official response to this question from US Space Command. Informally, I have been told that there will be no change in the twoline element set format to accommodate the arrival of the Year 2000. However, while the format may not change, the interpretation of the format does.
Apparently, US Space Command sees no need to change the twoline element set format yet since no artificial earth satellites existed prior to 1957. By their reasoning, twodigit years from 5799 correspond to 19571999 and those from 0056 correspond to 20002056. Therefore, there is no need to change the format for another 50 years! Unfortunately, this reasoning is severely flawed. While changing the format would involve changing large numbers of software packages to accommodate the format changes, not changing the format does not remove the need to modify this software. Instead of incorporating a format change along with the software modifications, modifications must be made now to change the epoch interpretation and later when the format is finally changed. Too bad that when Aerospace Defense Command proposed going from the old fiveline to the current twoline format in November 1972 they didn't recommend a fourdigit year (they did, however, at least change from a onedigit to a twodigit year).
Field 1.9 represents the first derivative of the mean motion divided by two, in units of revolutions per day^{2}, and field 1.10 represents the second derivative of the mean motion divided by six, in units of revolutions per day^{3}. Together, these two fields give a secondorder picture of how the mean motion is changing with time. However, these two fields are not used by the SGP4/SDP4 orbital models (only by the simpler SGP model) and, therefore, serve no real purpose.
Field 1.11 represents something called B* (BSTAR), which is an SGP4type drag coefficient. In aerodynamic theory, every object has a ballistic coefficient, B, that is the product of its coefficient of drag, C_{D}, and its crosssectional area, A, divided by its mass, m.
B = C_{D} A/m
The ballistic coefficient represents how susceptible an object is to drag—the higher the number, the more susceptible. B* is an adjusted value of B using the reference value of atmospheric density, ρ_{o}.
B* = B ρ_{o}/2
B* has units of (earth radii)^{1}.
Fields 1.10 and 1.11 have a somewhat different format that the other fields. In particular, they use a modified exponential notation with an implied leading decimal point. This convention is inherited from FORTRAN where all such numbers range from 0 to less than 1. The first six columns of each field represent the mantissa and the last two represent the exponent. For example, the value 123456 corresponds to 0.12345 × 10^{6}. Each of these two fields can be blank, corresponding to a value of zero.
Field 1.12 represents the ephemeris type (i.e., orbital model) used to generate the data. Spacetrack Report Number 3 suggests the following assignments: 1=SGP, 2=SGP4, 3=SDP4, 4=SGP8, 5=SDP8. However, this value is used for internal analysis only—all distributed element sets have a value of zero and are generated using the SGP4/SDP4 orbital model (as appropriate).
Field 1.13 represents the element set number. Normally, this number is incremented each time a new element set is generated. In practice, however, this doesn't always happen. When operations switch between the primary and backup Space Control Centers, sometimes the element set numbers get out of sync, with some numbers being reused and others skipped. Unfortunately, this makes it difficult to tell if you have all the element sets for a particular object.
The last column on each line (fields 1.14 and 2.10) represents a modulo10 checksum of the data on that line. To calculate the checksum, simply add the values of all the numbers on each line—ignoring all letters, spaces, periods, and plus signs—and assigning a value of 1 to all minus signs. The checksum is the last digit of that sum. Although this is a very simple errorchecking procedure, it should catch 90 percent of all errors. However, many errors can still sneak through. To eliminate these, all data posted on the CelesTrak site not only pass the checksum test, but must also pass both format and rangechecking tests (as described in this article).
Line 2 consists primarily of mean elements calculated using the SGP4/SDP4 orbital model. The definitions for fields 2.3 through 2.8 can be seen in table 2 below. Fields 2.3, 2.4, 2.6, and 2.7 all have units of degrees and can range from 0 up to 360 degrees—field 2.3 (inclination) only goes up to 180 degrees. The eccentricity (field 2.5) is a unitless value with an assumed leading decimal point. For example, a value of 1234567 corresponds to an eccentricity of 0.1234567. The mean motion (field 2.8) is measured in revolutions per day.
Table 2. TwoLine Element Set Format Definition, Line 2
Field  Column  Description 
2.1  01  Line Number of Element Data 
2.2  0307  Satellite Number 
2.3  0916  Inclination [Degrees] 
2.4  1825  Right Ascension of the Ascending Node [Degrees] 
2.5  2733  Eccentricity (decimal point assumed) 
2.6  3542  Argument of Perigee [Degrees] 
2.7  4451  Mean Anomaly [Degrees] 
2.8  5363  Mean Motion [Revs per day] 
2.9  6468  Revolution number at epoch [Revs] 
2.10  69  Checksum (Modulo 10) 
The final field on line 2, prior to the checksum, is the rev number. Since there are several conventions for determining rev numbers, this field also bears some clarification. In NORAD's convention, a revolution begins when the satellite is at the ascending node of its orbit and a revolution is the period between successive ascending nodes. The period from launch to the first ascending node is considered to be Rev 0 and Rev 1 begins when the first ascending node is reached. Since many element sets are generated with epochs that place the satellite near its ascending node, it is important to note whether the satellite has reached the ascending node when calculating subsequent rev numbers.
In general, any number smaller than the maximum field size can be padded with either leading spaces or leading zeros. In other words, an epoch can be represented as either 98001.12345678 or 98 1.12345678 or an inclination can be represented as 28.1234 or 028.1234. Convention uses leading zeros for fields 1.5 and 1.8 and leading spaces elsewhere, but either is valid.
Obviously, there are a few limitations with the current twoline format. First and foremost is the need for a fourdigit year in fields 1.4 and 1.7. Next, there is a need for a more robust form of error checking—perhaps a 16bit CRC. Such a checksum could be applied to both lines together, not only detecting errors within the data but also mismatched lines 1 and 2. If such changes were made, it might also be wise to increase the field size for the Catalog Number to six or seven digits to support the eventual cataloging of smaller debris.
The International Designator format seems to suffice for the foreseeable future, with a fourdigit year, up to 999 launches (the most we've had to date in any one year was 129 in 1984), and up to 13,824 pieces (the record holder today is 1994029 with 672 pieces). Of course, the cataloging of smaller debris—which we may be unable to correlate with the original launch—still presents potential problems.
As always, if you have any questions or comments regarding this column, please feel free to contact me at TS.Kelso@celestrak.com. Until next time, keep looking up!