by Dr. T.S. Kelso
January 1992
I seem to have stirred some controversy of late with the recent change in convention for calculating the checksum for the two-line element sets to follow the NORAD convention. In an effort to help the users of these data understand the reason for the change, I have included some historical information detailing how we got to where we are now.
I first began posting the two-line element sets for selected satellites in January 1986 after failing to convince NASA/GSFC of the need for and efficiency of providing the data in an electronic form. Since the only source of these data was Part I of the NASA Prediction Bulletins, I began entering these data by hand from the paper printouts I received by mail from NASA/GSFC. Initially, this was not much of an effort since I only typed up data for satellites I was using anyway. However, as word spread of this source of element sets, the list began to grow.
It quickly became apparent that without some specialized software to check the data, it would be easy to make errors in entering the data, no matter how careful I was. I developed a program which forced the data into the proper format and into the appropriate fields, saving time and effort during entry and reducing the chance for error. The software also calculated the modulo-10 checksum for each line. After entering thousands of element sets by hand, I began to notice that on the rare occasions when the checksum failed (on a legible element set), it was always under the following conditions: the field in Columns 54-61 of Line 1 was present and the digit in Column 61 was a zero. When this error occurred, the calculated checksum was always two (modulo-10) less that the printed checksum.
I reported this discovery to NASA/GSFC in a letter on 4 October 1988 and asked for an explanation. In a 15 December 1988 letter from Robert Lively, Head of the Project Operations Branch of the Mission Operations Division at NASA/GSFC, I received the following explanation:
As mentioned in the telephone conversation, our source of orbital elements has been working on an answer to your question of check sum anomaly. We are now informed that when transmitting the element sets via Teletype, a + sign does not convert to a printed character on the receive terminal. We are informed that groups of numbers that would normally have a + or - prefix assume a + sign if a - is not displayed, and have a value of 2 when validating the checksum. We will change our format explanations accordingly.
Since this explanation explained the anomalous data, it appeared to be correct and I changed the format description to state that a plus sign had a value of two when calculating the modulo-10 checksum.
This explanation held until I finally secured a means of obtaining the element sets directly (through a somewhat convoluted process) from NORAD in the latter part of 1989. At that time, I found that NORAD was apparently using the convention that a plus sign had a value of zero. Being unable to confirm this convention with NORAD officially, I began editing out the plus sign in Column 60 to make the checksum match. This change caused no real problem since any number without a leading sign is assumed to be positive.
The explanation was further muddied when NASA/GSFC began distributing a paper product with several thousand element sets on it. On those few occasions when I was unable to obtain the data electronically, I would use this source for updating the master list by hand. To my dismay, I discovered that the plus sign had an apparent value of zero in these data, even though the data from Part I of the NASA Prediction Bulletins assigned a value of two to the plus sign.
What finally convinced me that the plus sign should really have a value of zero was the result of two events. First, NASA/GSFC went online with their own BBS for distributing the two-line element sets and the plus sign had an apparent value of zero. Then, I had an opportunity to discuss the matter with officials in Cheyenne Mountain and at Air Force Space Command. I was told that the plus sign had a value of zero and that NASA obtained their data directly from NORAD. Since there was now another source of data which would not have the plus sign edited out, it was now time to straighten out the convention. As of 1 January 1992, the data which I post will follow the NORAD convention that a plus sign has a value of zero. While NASA's documentation states that a plus sign has a value of two, it is apparent that they do not follow this convention.
Subsequent to making this decision, I came across an old letter which may shed some light on the origin of our problem today. The following quote comes from this Headquarters Aerospace Defense Center letter dated 7 January 1980:
As you can see, the origin of our problem appears to have occurred back in the days of punch cards! I'm guessing that NASA didn't perform the transition properly. My guess would be that they disabled the teletype character to print a < rather than converting from BCD to EBCDIC. The checksum value for a < must have been a two and when NASA realized that the character was supposed to be a plus (some nine years later), incorrectly assumed that a plus must have a value of two! These are the kinds of problems we run into when we avoid standardization.
It is my belief that we should now officially adopt the NORAD convention and change any software, as necessary. NASA is being contacted on this matter and it is my hope that they will concur and change their official position. I apologize for any inconvenience this change may cause but hope that you now have a good understanding for why it is necessary.