This is the first in a series of four journal entries that details the steps the NAV team and others go through to plan, design, test and execute a trajectory correction maneuver (TCM), which is a major activity for a spacecraft in cruise.

Today the NAV team is to perform orbit determination and maneuver computation for the third midcourse maneuver. The design of the maneuver, a critical event during interplanetary cruise, is a process that takes a few days to complete. I hope to step you through the whole process in four journal articles. This first one is a bit long because it deals with orbit determination, my specialty, so forgive me if I talk a bit too long...

The first step in designing a maneuver is to determine where the spacecraft currently is and accurately predict its motion until arrival. That process is referred to as orbit determination, which is a complicated process, but I'll try to explain it as best I can. Basically, we start with a computerized model of the spacecraft's trajectory that our navigation software can process. The numbers from the computer model should closely represent the actual trajectory that the spacecraft is flying, but it's not perfect. In order to make it as perfect as possible, we use tracking data to measure the real trajectory and adjust the computer model accordingly.

Tracking data for Mars Pathfinder consists of two types, Doppler (a measure of how fast the spacecraft is receding from Earth) and range (a measure of the distance from the station to the spacecraft). There are other types of possible tracking data types, but on Mars Pathfinder we prefer to use only Doppler and range to reduce operational complexity and spacecraft resources. The Deep Space Network measures the range and Doppler from the stations to the spacecraft at regular intervals, and the results make their way to the NAV team in the form of a "Tracking Data File." The NAV team reads the file and compare the actual tracking data values with values we would expect from our model. Any error in our trajectory model will show up in this tracking data, and our programs know how to adjust the model to match the data correctly.

This may sound straightforward, but it's really not, for a number of reasons. First, there are a lot of physical effects that affect the spacecraft's flight path through space. Gravity of the Sun and the planets is the most obvious, but there is also a small but continuous acceleration due to the photons from the Sun hitting the spacecraft. Solar radiation pressure is what this is called, and it has been a difficult effect to model for us until just recently. There are also small changes in velocity that occur whenever the spacecraft's thrusters are fired to change the attitude, and we can't forget the results from past TCMs.

Secondly, since we use tracking data to help determine our trajectory, we need to know what phenomena will affect the measuring and collecting of that data. This includes the locations of the stations on the surface of the Earth, the orientation of the Earth at the time the measurement is made, the effect of the atmosphere and the ionosphere on the signal from the spacecraft to the station, and finally the electronic delays in both the spacecraft hardware and the station components that collect the data. That's quite a lot of stuff to keep track of, but is necessary in order to obtain the best possible trajectory solution.

Finally, we have to be careful to check the tracking data before using it, because sometimes we get delivered some bad data that would mess up our solution process. So the art of orbit determination sometimes involves editing out bad data, adjusting slightly flawed data, and reporting these errors to the Deep Space Network, who needs to know how they are doing. Orbit determination is also experimental in nature. The NAV team will try different strategies in orbit determination, always looking for the right strategy. Sometimes we'll use only Doppler data and ignore the range, or maybe we'll try the opposite. Sometimes we'll try estimating a particular effect and see what the result is, or we might choose to leave it unmodelled. A lot of comparisons between solutions are done, and this is where the human element of "judgment" comes into play, something you can't really program into software without a lot of effort. Experience with orbit determination is very important to know if you've got a good solution, an okay solution, or a bad solution.

After a number of experiments have been tried, we'll select a few of the better experiment results for consideration in selecting the 'right' solution. Today, for example, we had four possible solutions to pick from. All of these solutions were within 10 kilometers of each other, so we really could have picked one at random and had a good solution virtually guaranteed. Yet we prefer to discuss briefly any advantages or disadvantages a given solution might have, and narrow down the field to one solution. This we did in a meeting around 11:15 today. After discussing the various aspects of each solution and the implications of each for maneuver design, we selected one that Robin Vaughan had done. Its 'code number' was 970429rv104630, which identifies it among the many solutions we've done to date. I figure, I, myself, have done over 500 solutions since launch, so you can see that we need some method to keeping track of all these solutions.

Now we know where we are... The next step is to determine where we want to go, which is the subject of the next entry.