PART 1: Galileo fact of the day
PART 2: Working on the tape recorder
PART 3: The spacecraft performs great
PART 4: Canceling maneuvers means a job well done

Galileo's 400-Newton engine looks powerful, but it actually gives a
pretty gentle ride. The "nudge" it gives the spacecraft is like sitting
in a car going from 0 - 60 miles per hour in just under 2 _minutes_!
(an 8 year old Toyota can beat that by almost a factor of 10.) On the
other hand, unlike that car, Galileo can keep accelerating as long as
the engine fires. At the end of the 45 minute JOI burn, Galileo's
speed has changed by about 1400 mph.

November 21, 1995
I'm writing this from the Mission Support Area (MSA). The MSA is
the "control room" for the Galileo spacecraft. From here we send
commands and monitor the telemetry from critical events on the
spacecraft.

It's a smallish room at the corner of the 5th floor of building 264
here at JPL in Pasadena. Out one set of windows is a view of JPL's
huge, cylindrical Space Simulator where Galileo was tested before
beginning its long journey to Jupiter. Out the other windows is a hazy
but beautiful view of the San Gabriel mountains, a great place to ride
mountain bikes (but you had better like to *climb*). A third window
provides a view of *us* from the Viewing Room. The managers
sit in there to keep an eye on things when a "Big Event" (tm) is
taking place.

On two walls of the MSA, a pair of digital clocks with big, red
letters show the current day and time: UTC 325/23:33:27. A third
clock counts down the time till Jupiter Orbit Insertion (JOI):
JOI -16/01:46:00. Yikes! only sixteen days left!!

The room is arranged as a set of computer displays and work areas
for different groups of engineers. A little blue sign hangs over
each area: Telecom , Systems, SFP (system fault protection),
CDS (command and data subsystem), Mission Control. Each
station has a computer with a pair of screens to display
telemetry and voice-net terminal we can use to talk to each other.
When we need to say something official like, "Roger Systems, you
are go to send command package "X-ray Zulu Three Four Niner".

The sign over *my* head reads AACS (Attitude and Articulation
Control System). I'm here today to watch the final test of our
troublesome tape recorder before JOI. The tape recorder is really
part of the CDS, and normally an AACS guy like me wouldn't be
involved, but when the recorder anomaly occurred, I volunteered
to help the CDS unit and the anomaly team collect and plot the
recorder data.

To be honest, I sort of crammed my help down their throats.
I have a lot of experience using the telemetry system and have
spent many hours searching through old flight data trying to
solve problems for AACS, so I just started plotting up recorder
data and giving it to people. My plots seemed to be helping folks
and pretty soon I found myself being invited to anomaly team
meetings and given work to do. When a major problem like this
comes up, everyone on the team contributes where they can.

For a couple of weeks after the anomaly, everyone on the team
was working 7 days a week and late into the night to try and
figure out what was going on. It was *very* exciting to be
involved. It's sort of like trying to solve a Sherlock Holmes
mystery, where you have to find pieces of evidence and then
fit them together into a theory about what happened and how to
fix things.

Sometimes you get false clues and they make you pick the wrong
"suspect". For example, we have a computerized simulation
of the spacecraft that we call "The Testbed". It's built out of
our spare flight computers and hardware. We use it to test
command sequences on the ground before we send them
to the spacecraft and to help us figure out problems.

Now get this: on the *very same day* that the spacecraft
recorder anomaly happened, the spare recorder in our testbed
also failed! People were saying that it was a million to one
odds that both recorders would fail on the same day, so our
first "prime suspect" was some kind of problem with the
computer software that controls the tape recorder.

After looking much closer at the telemetry from the flight
recorder and eventually taking the testbed recorder apart
and looking inside, it is now clear that the two failures were
really unrelated! The software is fine and we just beat the
odds and had two independent hardware failures on
the same day!!!

Anyway, back to the MSA. By getting involved in the
anomaly, I learned a lot about how the recorder works and
build some tools for decoding and plotting recorder data.
That's what I'm doing today. We are doing our fifth
test of the recorder, running it for a couple of seconds to
make sure that it still works and that the tape isn't getting
stuck to anything.

My job is to collect some data on the recorder and plot
it up so the real tape recorder experts can make sure
everything is working ok. This is our last chance to
check on it before we use the recorder to save the
science data coming up from the Galileo Probe on
7 Dec.

The data I want is coming down as a MRO (Memory
Read Out). That's where the spacecraft just sends
down a copy of a little section of its computer memory
instead of its normal stream of telemetry channels.
At my workstation under the blue AACS sign, I
start up a program to capture and save the MRO data
as they come down.

There's the data, right on time. On my screen I can
watch the data being printed out as I type this. It looks kind of like 
this:

ERT: 95/325-22:18:16.670   BUC: 8b  Module: DBUM-1B
SCLK:   03186602.81.0.0  5100:
ffff  ffff  ffff  ffff  ffff  ffff  ffff  ffff  ffff  ffff  8121
1a21  121a  8b81  8b1b  8121  1a21  121a  8b81  8b1b
8120  1a20  121a  8b81  8b1b  8121  1a21  121a  8b81  8b1b
8122  1a21  121a  8b81  8b1b  8121  1a21  121a  8b81  8b1b

It takes a while for all the data I need to come down, maybe 15
minutes. When I have it all, I copy it to a file and run my little
program on it. It slices it up, moves it around, figures out what data
happened when. Finally, it makes a set of plots that I can hear
dropping out of the printer. As far as I can tell, everything looks just
fine. But that's for the real recorder experts to decide. I call the
beeper number I've been given and Greg Levanas (our version of
Sherlock Holmes) responds, He says he'll be up in a few minutes to
have a look.

I use the time to Xerox copies of the plots for him and finish this
report.

December 8, 1995
Yesterday's events, Probe Relay and Jupiter Orbit Insertion, appear 
to have run flawlessly. In fact, the spacecraft performance was 
amazing. I am still only beginning to realize the magnitude of this 
success.

For years, the Galileo Project has been concerned about the harsh 
radiation environment around Jupiter - and it was an important part 
of the spacecraft design. However, in the last two years, we in 
attitude control have taken further steps to figure out how to deal 
with potential weaknesses in the face of this radiation threat.

One big concern was how the star scanner would operate in the 
radiation environment. The star scanner is one of the ways in which 
the spacecraft orients itself: it basically compares the stars that it 
sees with a star map. In a high radiation environment, though, a 
cosmic ray can hit the star scanner and make the scanner think that 
there's a star where there's really nothing. Or, a cosmic ray could 
end up enhancing the brightness of a real star, which means that the 
star scanner won't properly identify it.

Long ago, we put together plans so that we wouldn't depend solely on 
the star scanner (gyros were the primary attitude source and the use 
of the acquisition (sun) sensor was incorporated). Nevertheless, we 
hoped that the star scanner would work okay. It turns out that the 
star scanner worked remarkably well. We did "lose lock" on one star 
(Canopus), which caused some problems, but that didn't occur until 
we were at a fairly sizable radiation level. And, after flailing for 
about 30 minutes, we locked back onto stars - even though the 
radiation level had not significantly subsided. One factor that helped 
was that we had made some software patches to the star scanner 
parameters so that it would initialize at a much higher background 
noise level (in case we lost celestial reference in high rad 
environment). I was ecstatic that we only lost stars for about 30 
minutes. I fully expect that we'll lock back onto stars after we spin 
down today.(the main engine burns are performed while the 
spacecraft is at high spin - 10.5 rpm, rather than our nominal spin 
rate ~3rpm.)

Another amazing point: our approach trajectory was so good (well, 
good enough) that we cancelled 3 planned maneuvers that were 
supposed to take place before the Jupiter Orbit Insertion (JOI) burn. 
These correction maneuvers are frequently small (they change the 
spacecraft's velocity by less than 1 meter/second), and gently nudge 
the spacecraft to where we want it to be. The JOI burn, which 
changes the spacecraft velocity by approximately 645 meters per 
second, is a HUGE maneuver. Yesterday, it executed with 
UNBELIEVABLE accuracy - the NAV team reported it was only off by 
one tenth of one percent!!!! This is so accurate that we have 
cancelled (*completely* cancelled) the clean up maneuver Orbit 
Trim Maneuver-1 (OTM-1), and we will most likely cancel the second 
clean up maneuver (OTM-2) also. Just think - here was a maneuver so 
large that we had planned on TWO clean-up maneuvers to correct for 
errors and we end up not needing either!

It really amazes me. Everything went better than predicted. And we 
had prepared for MUCH worse than predicted. We had so many 
scenarios of possible problems and backup plans that no one person 
can even comprehend all of it. Yet, all these plans remained in our 
"back pockets", keeping the engineers sane during the nail biting 
time. I guess it really says a lot about the original designers - this 
spacecraft is healthy and performed great.

Anyway, my excitement and awe is slightly tempered by some 
tiredness, and some surprise, and a sense of free-floating. After all, 
this was our main goal ever since I started working at JPL - perform 
probe relay and get into orbit. And now that we've done it...I guess I'd 
just like to bask in this glow and then start thinking about what to 
focus on next. Certainly there is no shortage of work on the 
spacecraft team... I guess for me, I now have to get used to the 
passing of the torch - from an engineering mission to a science 
mission. We've done our part, and now they get a chance to do theirs. 
I suppose the first sign of that happens over the weekend, when 
we'll get the first glimpse of the probe data. It will be the first 
information back from the atmosphere of Jupiter. A place that has 
never been visited before. And we were there. Yesterday.

-greg harrison
Galileo Attitude Control/Power

Monday, November 27
As we get closer and closer to arrival day and the Jupiter Orbit 
Insertion burn, there are an increasing number of meetings to go to. 
Today I attended two meetings. One was a meeting of the members 
of the Navigation Team who are responsible for figuring out the 
strategy to use for working on OTM-1 (Orbit Trim Maneuver #1 -- 
notice how we are changing the jargon here from "Trajectory Change 
Maneuver" to "Orbit Trim Maneuver," now that the spacecraft will be 
in orbit around Jupiter, and not just on its way to Jupiter).

OTM-1 is performed one day after the large JOI (Jupiter Orbit 
Insertion) maneuver. OTM-1 mainly corrects errors resulting from 
either (1) an Io flyby altitude that is above or below the target value 
(1000 kilometers) and/or (2) a JOI velocity change that is larger 
(overburn) or smaller (underburn) than the value we want (644.4 
meters per second). The strategy for OTM-1 has just recently 
become very complicated because we now know it is possible to 
make OTM-1 much smaller (and hence use less propellant) by 
changing the date of the first satellite encounter in the orbital tour, 
called the "Ganymede 1" flyby.

Today's other meeting was with representatives from the DSN (Deep 
Space Network) Team. We were looking at how to model the JOI burn 
in the DSN computers to guarantee continuous, or nearly-continuous, 
tracking of Galileo by the DSN antennas during the JOI burn. The 
better that the DSN understands how the orbiter's trajectory will 
change during the burn, the better able it will be to keep tracking 
the spacecraft.

Tuesday, November 28
Almost the entire day today was spent in discussions about the OTM-
1 strategy. The Navigation Team is going to give a presentation to 
the Project tomorrow morning to tell them the details of the 
different options for the OTM-1 strategy -- particularly with 
respect to changing the Ganymede 1 date. We hope to get from the 
Project some specific ground rules to use for designing OTM-1. The 
reason we need these ground rules *now* is that the Navigation 
Team has only 5 hours in which to do the actual computations for 
OTM-1. There is not enough time in those 5 hours to do the work 
required for OTM-1 and also allow the Project to consider and decide 
on various options.

Today's calculations of the Io flyby trajectory show essentially no 
altitude error at the Io flyby. However, there is a significant "out-
of-plane" (i. e., North-South) error -- the trajectory is several 
hundred kilometers South of the desired aim point. On the other hand, 
the altitude uncertainty is decreasing and is now about one third as 
large as it was for the TCM-27 and TCM-28 designs. We'll be able to 
present this material to the Project tomorrow.

Wednesday, November 29
This morning, the Navigation Team presented the options for the 
OTM-1 strategy and the latest orbit determination results to the 
Project. The material on OTM-1 generated a great deal of discussion. 
That's understandable -- this material is particularly detailed and 
complicated, but I believe that the Project now understands much 
better the issues surrounding OTM-1 and the implications of 
changing the Ganymede 1 encounter date to reduce the OTM-1 
velocity change. We should be getting the requested OTM-1 design 
ground rules by the end of the week.

Today's orbit determination solution for the Io flyby show the 
trajectory to be at an altitude of 956 kilometers, 44 kilometers 
below the desired altitude. The uncertainty is now about the same 
size as this error. The trajectory is South of the aimpoint by about 
300 kilometers. This "too far South" error in the trajectory is not a 
problem, because the Project some time ago decided that there 
would be no remote-sensing observations (for example, pictures) at 
the Io flyby, so as not to risk breaking the tape recorder, on which 
all of the atmospheric Probe data will be stored. The "too far South" 
error does not affect the gravity assist effect (slowing the speed of 
the Orbiter) we are getting from Io.

At the end of the day, word came down from the Project that they 
were leaning heavily towards the OTM-1 strategy that would make 
maximum use of changing the Ganymede 1 flyby date in order to 
minimize the velocity change. This strategy would help us to 
conserve as much propellant as possible, with the major downside of 
having to make changes to all of the computer sequences that would 
be running the spacecraft during the Ganymede 1 encounter. But 
these sequences have to be redone anyway, because of the tape 
recorder problem. So accommodating a change in the Ganymede 1 
flyby date does not have as big an impact as we had originally 
thought.

Thursday, November 30
More meetings today, including one where a decision would be made 
by the Project on whether to send some special commands to Galileo 
next week. The idea is to ensure that the pointing of the relay 
antenna that receives the data sent from the Probe is as accurate as 
possible.

Today's orbit determination results for the Io flyby show the 
trajectory to have moved back to almost exactly 1000 km altitude 
-- no error again! There are two more tracking passes before the 
cutoff for receiving data that can be used for the design of TCM-28A 
(6:00 AM tomorrow morning). If the trajectory does not move much 
with the additional data, we will recommend not doing TCM-28A.

Friday, December 1
Today I got to work at 6:00 AM, but I wasn't the first one in. Our 
orbit determination specialists were already hard at work 
generating a new trajectory that includes the latest tracking data. 
Our maneuver design and trajectory analysis experts were eagerly 
awaiting the new trajectory so that they could get to work on the 
maneuver design. We had five hours in which to do all the work 
required to calculate the desired velocity change for TCM-28A 
before passing on the information to the Orbiter Engineering Team. 
No problem -- by noon, we were presenting arguments for and 
against doing TCM-28A at the Maneuver Design Status meeting.

But first, some background. The new strategy for designing OTM-1 
allows us to move the Ganymede 1 flyby date earlier (in one week 
increments). This allows us to minimize the OTM-1 velocity change 
(and propellant consumption) in some situations -- namely, when the 
time it takes for Galileo to orbit around Jupiter after JOI is longer, 
or higher, than expected. So, if the spacecraft has a higher "orbit 
period" than was initially planned, we have a straightforward way in 
which to save considerable propellant.

Does this work the other way? If the orbit period is shorter than 
expected, or "low," can we move the Ganymede 1 flyby date later to 
conserve propellant? Unfortunately, no, since that would require 
flying closer to Ganymede than is safe. So we want to avoid errors 
that will result in a low period, but we can deal effectively with 
high period errors. Now back to the TCM-28A meeting...

The situation was as follows: If we don't do TCM-28A, that leaves 
the trajectory with a slightly high period (by about 3.5 days), a 
result of the predicted Io flyby altitude now being about 60 
kilometers low. If we do TCM-28A, then we will get rid of this 
period error, and move the trajectory toward the "low period" cases 
-- precisely the situation we want to avoid. The Navigation Team 
recommended that TCM-28A be cancelled so that the trajectory 
would have a slight "bias" toward a low period. Of course, the orbit 
determination results can (and will) change as we get closer to Io, 
and the JOI burn may underperform (moving the period lower) or 
overperform (moving the period higher). After considerable 
discussion, the Project agreed with our recommendation, and TCM-
28A was cancelled. (The new OTM-1 strategy was made official 
today; the Project Manager issued a memo declaring that the 
Ganymede 1 date should be moved to minimize the propellant 
required for OTM-1.)

With the cancellation of TCM-28A, that makes three maneuvers in a 
row that have been cancelled. In many jobs, having an upcoming work 
activity get cancelled would be regarded as a failure. For us, it 
means that we're doing our jobs right. It has been possible to cancel 
these maneuvers because of a combination of factors: excellent 
navigation (smart, hard working navigators :-), the new strategy for 
OTM-1 (more navigation ingenuity -- what can I say, I work with a 
group of smart people), the removal of any science requirements on 
the Io flyby (since we don't have to worry about camera pointing 
angles, this allows us to leave the ever-present "too far South" error 
uncorrected), and, finally, a little bit of luck.

The next big event is the JOI "Tweak" which starts next Monday 
afternoon (three days before the Io flyby). Even though TCM-28A was 
cancelled (it would have been done on Saturday), the Navigation 
Team will be working this weekend to update the trajectory 
predictions as more tracking data comes in and to practice the 
design of OTM-1.