Satellite Times

Tracking the Sun and the Moon

By Dr. T.S. Kelso

Cover
January/February 1997

Satellite transiting Moon

From time to time, I'll get a question asking for two-line element sets for the moon (or the sun). This would seem to be a natural enough question. After all, the moon is a satellite of the earth and its orbit is described by the same basic parameters as those contained in the two-line element sets.

The rub here is that the two-line element sets you find on the Celestial WWW are not generic element sets—they are specific to NORAD's SGP4 orbital model. In order to understand why this distinction is important, I'd like to begin by briefly reviewing the basics of orbital modeling and specifically address the assumptions made in the SGP4 orbital model. Once we've done that, it should become clear why this model can't be used for tracking the moon. Then, we'll move on to cover some simple ways to track both the sun and the moon and discuss an interesting new application.

While we have covered some of this material before, it is important to note it here to place the larger question in perspective. First and foremost, we must understand what a model is to fully appreciate the general limitations of any orbital model and the specific limitations of the SGP4 orbital model. According to Shannon, "a model is a representation of an object, system, or idea in some form other than that of the entity itself."1

Models can come in many forms from physical and scale models to mathematical and computer models. Regardless of the form, models serve one of two purposes: they are either descriptive (explain the system of interest) or prescriptive (predict the behavior of the system).2 The orbital models we use for predicting the position of an earth satellite (natural or artificial) fall in the latter category.

The reason for using a model, as Rosenblueth and Wiener note is that,

No substantial part of the universe is so simple that it can be grasped and controlled without abstraction. Abstraction consists in replacing the part of the universe under consideration by a model of similar but simpler structure.3

This statement is certainly true of orbital mechanics. While the underlying principles of gravitational attraction are pretty simple, extending them to objects other than point masses can become complicated pretty quickly.

When developing a model, it is important to do several things. First, you should understand the goal of developing the model. For the SGP4 orbital model, the goal was to track large numbers of artificial satellites orbiting the earth on a routine basis—the implication here being that the tracking needed to be computationally efficient to support daily operations. Of course, the speed of computation would have to be traded off against the accuracy (or fidelity) of the predictions, with some minimum level of performance.

The second thing that needs to be done is to define the system under investigation. Shannon defines a system as "a group or set of objects united by some form of regular interaction or interdependence,"4 which for our case amounts to our satellites and anything which influences their orbits. The range of influences would naturally include the gravitational influence of the earth, moon, sun, and planets, as well as things like atmospheric drag and solar pressure.

We must define the system as part of the process of balancing the goals of computational speed against predictive accuracy. If we could model every influence on the motion of a satellite, our accuracy be very good, but our computational speed would be low. If, however, we rank these effects by the magnitude of their influence, we find that some have no practical effect on the motion of a near-earth satellite. For example, the effect of the earth's gravity is much greater than that of Mars and, in fact, the gravitational pull of Mars has no practical influence on the orbits of these satellites. As such, there is no point in developing a model (and increasing the computational complexity) that includes such an effect.

When the predecessor to SGP4 (SGP or Simplified General Perturbation) was developed, most artificial satellites were in low-earth, circular orbits where the primary effects were the earth's gravity (including some of the major perturbations due to its non-spherical shape and non-uniform density) and atmospheric drag. Things such as solar and lunar gravitational effects and solar pressure had a negligible effect on these orbits. As a result, the model was developed incorporating only these effects. In addition, simplifications could be made since the mass of these artificial satellites is much much less than the mass of the earth and the effect of third bodies could be ignored.

To eliminate the need to numerically integrate the position of each satellite (a particularly time consuming computational process), an analytical model was developed that allowed the position to be calculated directly at the time of interest (for more information on numerical integration versus analytical models, see this column in the March/April 1995 issue of Satellite Times). This analytical model required a series expansion in terms of the orbit's eccentricity—a term that is usually small for the class of orbits being examined.

Both the reduction in the number of effects influencing the orbit of the satellite and the conversion from a numerical integrator to an analytical model served to considerably reduce the computational load of predicting the position of a given satellite. At the same time, however, it also reduced the accuracy of these predictions and placed some assumptions on the orbital characteristics being modeled to ensure the accuracy is maintained within reasonable limits.

These assumptions include the satellite having a negligible mass compared to that of the earth, with no third-body gravitational effects, and having a near-earth orbit—where the effects of the earth's gravity and atmospheric drag dominate—with a small eccentricity. With the exception of the low eccentricity, neither the orbit of the moon or the earth around the sun (to calculate the position of the sun) meet the remaining modeling assumptions. Since the orbital elements in the two-line element sets are generated by fitting observations to the SGP4 orbital model, trying to fit elements to orbits which do not satisfy our modeling assumptions will result in predictions which are likely to have large errors.

As can be seen from this development, therefore, there can be no two-line element sets for the position of the moon or the sun (actually, the earth's orbit around the sun). Equally important, it can be seen that predictions for orbits which have high values of eccentricity will likely be less accurate than those with small eccentricity.

Of course, as satellites began to be launched into higher orbits, other limitations in the SGP model's assumptions became apparent. In particular, above a certain altitude, effects such as solar-lunar gravity, solar pressure, and gravitational resonances with the spin of the earth dominate over that of atmospheric drag. As a result, SGP was modified to become SGP4 (or really, SGP4 and SDP4). SGP4 is valid for near-earth orbits with periods of 225 minutes (an altitude of roughly 5,000 km) or less while SDP4 is valid for deep-space orbits above that (well, at least out to geosynchronous altitude).

As would be expected, several tradeoffs had to be made in developing the SDP4 portion of the model. Of course, some additional effects are included in this new model while atmospheric drag is eliminated, increasing the overall computational load. In addition, since the series expansion in eccentricity modeled only the earth's gravitational effect, some numerical integration was required to handle some of these new effects. The result is what is referred to as a semi-analytical model—again increasing the computational load. However, without these changes, the accuracy of predictions for orbits above the 225-minute cutoff would be significantly reduced.

Down to Business

Just as a separate model is required to handle deep-space orbits, separate models are needed to predict the position of the sun or the moon with reasonable accuracy. Astronomers have expended considerable effort in developing models to predict the position of these bodies with extremely high accuracy for use in calculating circumstances for solar eclipses. In fact, at the beginning of this century, E.W. Brown spent twenty years developing his theory of the motion of the moon—ten years to develop the equations and another ten years to check them!

In the case of the sun's motion, not only must theory account for the earth- moon orbit about the sun but also the rotation rate of the earth and the nutation and precession of the earth's axis. The moon's orbit is influenced by the gravitational attraction of not only the earth and the sun but also of the planets, together with interactions with the earth's ocean tides. High accuracy predictions require equations with hundreds of terms to account for the various effects.

For more practical applications of predicting the position of the sun and the moon for calculating satellite eclipse circumstances or the rise and set times of these celestial bodies, an excellent source is Jean Meeus's Astronomical Algorithms. As the title suggests, this book covers a wide range of algorithms relating to astronomical circumstances—including how to calculate the position of the sun (chapters 24 and 25) and the moon (chapter 45).

For the sun, Meeus's algorithm—similar to the one in my SGP4 Pascal library—predicts the sun's position to 0.01 degrees (two percent of the solar diameter) by assuming a purely elliptical motion for the earth and ignoring perturbations from the moon and planets. Each calculation only requires evaluation of eleven low-order polynomial equations with a dozen trigonometric evaluations. As seen in this column in the September/October 1996 issue of Satellite Times, this makes it possible to calculate when earth satellites are visible to observers on the ground by calculating the elevation of the sun and the position of the earth's shadow.5

Meeus's algorithm for the calculation of the position of the moon is considerably more complicated. The calculation is based on a summation of sine and cosine terms which, while significantly reduced from the hundreds of terms necessary for high accuracy computations, still requires ninety trigonometric evaluations. Using only these more significant terms, however, the algorithm is still able to provide accuracy of approximately 10 arcseconds in geocentric longitude and 4 arcseconds in geocentric latitude.6

An Interesting New Application

Back in August of this year, I received an e-mail message from Gary Eldridge wanting to know how to predict the position of the moon. Seems Gary has become hooked on watching satellites transit (cross the surface of) the moon's disk through his telescope. After relating his initial experiences, I can see why:

Got a GREAT silhouette view of Mir last Saturday night and some other unknown satellite a few weeks prior. The detail was incredible while using an 8 inch reflector scope and 17mm eyepiece.

Of course, the real problem here is figuring out just when a satellite is going to transit the moon (or the sun) so as to know when to look. Up to now, he's been using something of a brute force approach—running a large catalog of objects against a star background and examining in detail those that come close to the sun or moon.

I think this problem would make an interesting project for an upcoming column(s) since it has several intriguing aspects. First, it will be necessary to develop code to predict the position of the moon (to go along with that for the sun) which can be used with the SGP4 orbital model. Then, it will be necessary to define the circumstances of a successful transit: (1) the sun or moon above the observer's horizon, (2) for lunar transits, a minimum phase for the moon and the sun being a certain distance below the horizon, and (3) the satellite crossing the illuminated portion of the object's surface.

The challenging part of this project will be to come up with efficient ways to reduce the number of cases examined. The intriguing part is two-fold. First, since the satellite will transit the sun or the moon's disk, it is trivial to know exactly where to point a telescope (and track) to watch the transit and the background should be bright enough to make it easy to photograph or videotape the event. Second, it will be interesting to see just how much detail can be discerned of the satellite as it transits since, according to Gary, there seems to be some disagreement:

I seem to have caused some controversy among other astronomers as to whether a amateur telescope can resolve such detail on an orbital satellite. I would not have thought so either until I started seeing these things. It seems that when they cross in front of the Moon, the silhouette image reveals incredible detail. Solar panels and other structures can easily be seen.

Of course, observation and timing of these transits will also serve to visually demonstrate the overall accuracy of the orbital model, as discussed in our last column on "Real-World Benchmarking."

I hope you will join me on this journey. Not only will we be covering new ground, but the development of an efficient tool to predict satellite transits is likely to spark a new aspect of visual observing. And I, for one, am looking forward to seeing your best photographs so we can share them with the world.

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!

Notes

1 Robert E. Shannon, Systems Simulation: The Art and Science (Englewood Cliffs, NJ: Prentice-Hall, Inc., 1975), p. 4.
2 Shannon, p. 7.
3 Quoted in Thomas H. Naylor et al., Computer Simulation Techniques (New York: John Wiley & Sons, 1966), p. 9.
4 Shannon, p. 15.
5 Jean Meeus, Astronomical Algorithms (Richmond, Va.: Willmann-Bell, Inc., 1991), pp. 151-153.
6 Meeus, pp. 307-313.


TLE Data Space Data
Current GPS
Archives EOP
Documentation Space Weather
SATCAT Columns
Boxscore Software
SOCRATES
Dr. T.S. Kelso [TS.Kelso@celestrak.com]
Follow CelesTrak on Twitter @TSKelso
Last updated: 2014 May 17 01:56:23 UTC
Accessed 109,026 times since 2000 December 16
Current system time: 2017 August 18 10:56:18 UTC