Introduction to the project
ISS Transit email-alert signup page
Project Goals & Stuff ToDo
Links & Informational Resources
Released Software
SourceForge project page
Technical issues & challenges
If you ask a bunch of people how long it takes the earth to make one orbit of the sun, (hopefully) most of them will answer, "one year." However, the definition of a year is actually tied to the seasons (Calendar: Humanity's Epic Struggle to Determine a True and Accurate Year), and its most precise definition (I'm a positivist- despite positivism's current lack of favor among philosophers- so I take the view that all knowledge is necessarily a little fuzzy) is the time from one passage of the Vernal Equinox to the next (the V.E. is when the plane of the earth's equator passes through the center of the sun, as the earth's orbit carries it "below" the sun, from the point of view of someone living at the North Pole)... at least that was the definition of a year, prior to the invention of atomic clocks.
Now, because of the 25,770-year period of the retrograde precession of the earth's axis (simply put, the "spinning top," which is the earth, is wobbling in a clockwise direction, when viewed from above the North Pole- that is, the direction of wobble is opposite to the rotation of the earth on its axis, and the earth's orbital motion around the sun), a year is 1/25770 less than the time it takes for the earth to orbit the sun; stated another way, it takes about 1 year and 20.4 minutes for the earth to make one complete orbit around the sun.
The original Roman calendar of about 753 BC (or 752 BC, for anyone who wants to follow my wise advice, and belatedly recognize the existence of the Year Zero, so come 3000 AD, we won't have to listen to any more whining from those "the Millennium really doesn't start until..." weirdoes) had the Vernal Equinox occurring- logically enough- on the first day of the year, which was March 1. However, fairly quickly... well, after 53 "years"... they noticed that there were problems with having 10 months in a year, so they added January and February (which is why the "10th" month, December, is now the 12th month). However, they had to wait another 650 years or so for Julius Caesar to come along, consult with an Egyptian astronomer, and in 46 BC, add an extra day to the calendar, every 4 years. But, alas, a year is slightly less than 365.25 days, so by the time of the Gregorian calendar reform of 1582 (which was ignored by us good Protestants, in America and England, until 1752), things had gotten enough out of whack that we're stuck now with the Vernal Equinox occurring- arbitrarily, it seems, but nonetheless by definition- on March 21.
At present, the earth reaches its perihelion (about 91.5 million miles from the sun) on about January 2, and its aphelion (at 94.5 million miles) on July 4. What's happening, as a result of the precession of the earth's axis, is that the Vernal Equinox is slowly shifting backwards toward the perihelion, so that 5500 years from now, it will coincide with the perihelion. (By 2098, the North Celestial Pole will have made its closest approach to Polaris, which is currently located at about 2 h 30 m in Right Ascension, and 89° 15' declination.)
Also in the realm of "things are always more complicated than you originally assume," I've lived most of my life within the mostly pleasant latitude of 34º N. One would think, then, that the angle from me to the center of the earth, to the point on the equator directly south of me, should be 34º, but it ain't necessarily so... The earth is 0.5% oblate; its mean diameter at the equator is about 7960 miles, versus about 7920 miles, when measured from pole to pole. Evidently, the "official" definition of latitude places 45º of latitude exactly halfway between the equator and the poles, as measured by surface distance. Since the earth has a nice middle-aged waistline, this means that at "45º N in latitude," you're a little closer to the equator than you are to the North Pole, in terms of angular measurement (i.e., a star at precisely 45º N declination will cross your meridian a little bit north of "directly overhead").
I used to work on a satellite that I'll simply refer to as "DSP," and I can tell you that- when you're trying to deliver your thermonuclear bomb within 100 feet of the other guy's hardened missile silo from 7000 miles away- such nit-picking details make all the difference.
Two-line Elements
Two-line elements are the means by which satellite positions are currently predicted. Unfortunately, they are also a good example of all that was twisted and evil about the time when Elvis made Priscilla dye her soft-brown hair an army-boot black; incest between persons of the opposite sex was legal in Georgia; and programmers actually had to worry about saving a few bytes, wherever they could. Quoting from T.S. Kelso:
"How will the Year 2000 be handled?... Apparently, US Space Command sees no need to change the two-line element set format yet since no artificial earth satellites existed prior to 1957. By their reasoning, two-digit years from 57-99 correspond to 1957-1999 and those from 00-56 correspond to 2000-2056. Therefore, there is no need to change the format for another 50 years! Unfortunately, this reasoning is severely flawed..."
Of course, euphoric from having just saved 2 bytes in specifying the launch year, they celebrated their triumph in "line 2" by using 5 bytes (in columns 3-7) to specify... once again... the "Satellite number," which had already been specified in columns 3-7 of "line 1!"
This is why, today, we have XML... and perhaps it might not be such a bad idea, for this project, not only to provide a means of parsing two-line elements, but also to convert them to a meaningful, non-redundant, XML format.
Two-line elements were developed as part of an orbital model called "Simplified General Perturbation." Ideally a satellite- once put into orbit- would precisely repeat its orbit forever. In reality, the satellite (if it's less than about 3000 miles up) will slowly lose energy due to the tiny amount of the earth's atmosphere it encounters. In addition, it's affected by the "lumpiness" of the earth (including ocean tides); the earth is not a perfect sphere whose density is constant at any given distance from the center (if this were the case, the earth could be treated as a "point mass," for such purposes as orbital prediction). Farther out, a satellite (e.g., in geosynchronous orbit 22,240 miles up)- while no longer affected by the earth's atmosphere- encounters the solar wind, a variety of high-energy particles that continuously escapes from the sun. These satellites are also affected by the varying position of the moon, and (to a lesser degree) planets such as Venus and Mars.
Simply stated, accurately tracking a whole bunch of man-made satellites, year after year, is a real headache!
In Tracking the Sun and the Moon, Dr. Kelso goes a bit more into the history of this. The present orbital models in principal use are SGP4, for low-earth orbits, and SDP4 (Simplified Deep-space Perturbation), which gives good predictions at least out to geosynchronous orbit.
Satellites have a far more bumpy ride than I'd ever have imagined. Shown below, from www.hq.nasa.gov/osf/station/viewing/issvis.html, is a record of the roller-coaster ride of the space station since its launch:
All of the above notwithstanding... and having already converted legacy SGP4 code to Java... it actually may be overkill to use this algorithm for the purpose of this project. The 2-line elements for the space station are evidently frequently refreshed by NASA- despite the fact that (except when it's given some rocket boost) the station's orbit is unlikely to change significantly from day to day. Therefore (assuming one has reliable network access), one should be able to look up the station's latest orbital parameters, and use them to calculate its position based upon the assumption that- for at least the next 24 hours- it will follow a classic, unperturbed orbit, respecting Kepler's laws.
In fact, projected daily 2-line element values are available several days in advance (spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/orbit/ISS/SVPOST.html). As long as this remains true, then the ability to forecast transit tracks days in advance should be possible, without having to use the SGP4 model (which is limited in its forecasting accuracy anyway!).
On the other hand... what are a few billion CPU cycles, compared with writing more lines of code? :^)
update...
I was just looking at the above URL, and today it contains some interesting data behind the zigzags in the altitude chart, above. The excerpts, below, describe a rocket engine burn to boost the space station back into a higher orbit:
Maneuvers contained within the current ephemeris are as follows:
IMPULSIVE TIG (GMT) M50 DVx(FPS) LVLH DVx(FPS) DVmag(FPS)
M50 DVy(FPS) LVLH DVy(FPS) Invar Sph HA
M50 DVz(FPS) LVLH DVz(FPS) Invar Sph HP
------------------------------------------------------------------------
42/12:00:23 7.1 16.2 16.2
-14.4 0.0 214.8
1.8 0.2 212.8
From spaceflight.nasa.gov/realdata/elements, M50 = "Inertial mean of year 1950 frame of reference" and LVLH = "Local Vertical Local Horizontal rotating, instantaneously inertial, frame of reference". spaceflight.nasa.gov/realdata/elements/graphs.html defines the x, y, and z axes (in LVLH, I presume DVx is the speed boost in the direction of travel, while DVz is the speed boost "upwards").
The rocket burn begins on day 42 of the year (11 Feb 2003), at 12:00:23, GMT. Just before the burn, the space station is in the "coasting arc" shown below:
Coasting Arc #6 (beginning on orbit 139)
---------------------------------------
Vector Time (GMT): 2003/042/11:44:20
Weight (LBS) : 397793.3
After the burn, the space station is in a new coasting arc:
Coasting Arc #7 (beginning on orbit 139)
---------------------------------------
Vector Time (GMT): 2003/042/12:15:17
Weight (LBS) : 396904.9
Note that the space station has mysteriously gotten lighter!.. a shame they don't have plasma engines.
updated 9 Feb 2003