Apollo: The Race to the Moon (53 page)

Lunar descent was a complicated procedure, and there wasn’t much time to practice. From the first Apollo flight through Apollo 11, the people building the simulators were caught behind the curve. The flight hardware was always at least a little behind schedule, and it was always being changed. The simulators couldn’t be built to mimic the real LEM until they knew how the real LEM operated. Then, after the simulation hardware was built, there remained the even more difficult task of writing software that would permit the SimSups in the Control Center to put the crews and flight controllers through their paces with realistic, multiple-branch scenarios. In the case of the lunar descent, the simulation software wasn’t completed until about two months before G’s scheduled launch. But that was okay. The White Team was coming off Apollo 9 with “what we thought was a pretty hot hand,” Kranz recalled, and they were ready. Two months was plenty for the White Team.

The first simulation of a landing on the moon, on May 29, was a major event within M.S.C. The viewing room was filled with senior NASA officials. Low, Gilruth, and Kraft were in the back row of the MOCR. It was not the real thing, but it was exciting nonetheless. That morning, after all the years of preparation, they were going to practice landing on the moon.

Down in the Trench at the Guido console sat Steve Bales. Bales, like most of the others in the front room, was, at age twenty-six, a veteran in terms of experience (he had been in the Flight Dynamics Branch for five years). Bostick, Bales’s boss in the Flight Dynamics Division, had watched him carefully over the last year, as had the flight directors. Steve Bales was still a kid in many ways, inclined to oversleep if you didn’t get him on the phone and make sure he was in an upright, conscious position a few hours before his shift, given to enthusiasms and excitements. He was not the image of flight-controller cool—he would sit at his console constantly twisting a lock of his hair at the back of his head so that it stuck out like a small pigtail. But Bales was also a crackerjack Guido, quick, reliable, and knowledgeable, and now Bostick had picked him as Guido for the G Mission, along with Jay Greene for FIDO and Chuck Deiterich for Retro.* During the descent, Guido’s was an especially important console, because so many of the things that could go wrong involved errors in guidance. On this first simulation of a descent, Bales was as nervous as he had ever been on a real mission.

[* Controllers wanted the first descent shift just as badly as astronauts wanted the mission with the first landing—some of them almost obsessively. It took at least one FIDO a long time to recover from being passed over in favor of Greene. It is indicative of the spirit shared by the F.O.D. managers (and managers in Apollo in general) that the men who could have assigned themselves to the descent phase (Charlesworth, Bostick) did not do so, just as Kranz, as head of the Flight Control Division, could have assigned himself to be lead Flight Director for Apollo 11.]

The first lunar-descent sim, however, turned out to be routine. The SimSup didn’t try any funny stuff at all; he just let the flight controllers and Armstrong and Aldrin determine that they could indeed put the LEM down in one piece if nothing went wrong. And so it went for the first few days of sims, “shooting the nominals,” they called it—normal burns, no major malfunctions, no disperse trajectories. “But then the simulation team started putting the meat to us,” Kranz said, “and, to put it bluntly, we started crashing.” Or, almost as bad, they aborted when they didn’t really have to.

Several novel difficulties made the descent simulations especially harrowing. The voice and data delay was hard to get used to. At the speed of light, it took 1.3 seconds for a transmission from the spacecraft to reach the earth, and another 1.3 seconds for an answer to return. That added up to 2.6 seconds between the time that an astronaut in the lunar module reported a malfunction and his receiving the quickest possible response. The ways in which that 2.6-second delay could screw things up were legion, the White Team found. The difficulty was compounded by the slow computers of the 1960s. The most critical data during the lunar descent involved navigational calculations based on complex radar data. Those calculations took time to perform, so that four or five seconds would elapse between the time the data reached earth and the time the Trench and its back rooms could see what was happening on their screens.

Another problem was the “dead-man’s zone,” a label that official NASA didn’t like at all and tried to discourage. But it was called the dead-man’s zone for good reason. During a short period toward the end of the descent, the crew had no way of aborting if something went wrong. During that period, only about ten seconds long, the combination of altitude (by now very low) and rate of descent (still fairly high) was such that even if the ascent engine fired immediately after an abort command, the lunar module would crash before the ascent engine could overcome the inertia of the descent. The theory of how to minimize crashes in the dead-man’s zone had been worked out, but the White Team found that it was exceedingly difficult to apply during the sims—especially with that 2.6-second delay, which kept astronauts and controllers from staying in synch.

Then there was the difficulty with the PGNS (Primary Guidance and Navigation System, pronounced “pings” because sometimes the acronym was informally spelled PNGS). In the descent, if the PGNS found that the trajectory was deviating from nominal, it was supposed to keep balancing two competing desirable states of affairs: landing at the assigned target, and landing softly. During the simulations, the PGNS, given a choice between the two, had an unnerving tendency to decide to get to the target, come what may. “On occasion,” Kranz said, “if you were far enough off in your navigation state, [the PGNS] would point the LEM directly at the target and try to approach it in pretty much the same fashion that you would fire a projectile.” This made for an extremely hard landing, the kind that was euphemistically called dinging the spacecraft, less euphemistically known as a fatal crash.

Over in Building 2, the people on the top floors began to get nervous. At that time, the flight director’s loop and the air-to-ground loop were piped into the offices of senior management, so they could listen to what went on in the MOCR. “I’d get calls from Kraft or George Low into the phone behind the console,” Kranz remembered, “that’d say, ‘When are you guys gonna get your act together? You’ve crashed another simulation. What’s wrong over there? What’s wrong with your team, or your timing, or your judgment, or whatever it is?’” Kranz began to think of the lunar descent as going into a cauldron.

The late start for the G Mission had meant that Bill Tindall’s thousand-ring Mission Techniques circus had been kept busy up until the last minute. The simulations kept bringing up new possibilities, which then had to be thrashed out. The Instrumentation Lab people from M.I.T., the people with the main guidance and software contracts, had been especially hard pressed, since the descent and ascent depended on their new and still-untested programs. The flight controllers would go to the meeting with “straw man” mission rules, ones they knew weren’t good enough but that would provide a starting point, and Tindall would stand up there with his chalk, exclaiming and exhorting, and say, “Okay, M.I.T., what do you think of this one?” M.I.T. would say they didn’t have any data for making up their minds, and Tindall would get the SimSups, racing against the schedule, to crank a test of the rule into the next simulation to see what happened. Tindall’s final Mission Techniques meeting for Apollo 11 was just one week before liftoff.

Some time during that harried training cycle of 1969, no one knows exactly when, SimSup Jay Honeycutt went to talk to the controllers in the Flight Dynamics back room. Jack Garman, a twenty-four-year-old controller working there—smart as a whip, computer hotshot—happened to mention the computer alarms to Honeycutt. There were many such alarms in the computer software, each designated by a number.

The alarms hadn’t previously come to the SimSups’ attention because they weren’t designed primarily for the controllers or the crew. Rather, they were debugging tools for the software engineers, and they were buried “deep in the bowels of the onboard computer program,” as Bill Tindall recalled later. “We had gone through years of working out how in the world to fly that mission in excruciating detail, every kind of failure condition, and never, ever, did I even know those alarms existed.” And this was Bill Tindall, who was not only running Mission Techniques, but before that had been one of M.S.C.’s lead engineers on the onboard computer and guidance systems.

Garman and the others working the operating system software knew that the alarms existed, but they hadn’t paid any attention to them. As Garman put it, “The problems that triggered the alarms were not problems that could reasonably happen during a mission.” But there they were nonetheless, linked to the crew’s onboard displays, which meant that an alarm during a flight would produce a flashing light on the display and an audible alarm as well, like the alarms involving engines or environmental systems. This was just the kind of thing that an enterprising SimSup like Honeycutt was on the lookout for.

A seemingly unrelated event occurred in June, about a month before launch, when the M.I.T. people programming the lunar module’s onboard computer sent a Crew Procedures Change Sheet down to Flight Crew Operations. Nothing involving the Apollo missions—not a switch setting, not a number, not a time—could be changed without the documentation of a Change Sheet plus formal approval by a Change Board. In this case, the change involved the mode switch for the rendezvous radar.

The lunar module had two independent guidance systems for homing on the command module. One was the PGNS, which was used to bring the LEM back up to the command module from the lunar surface. The other system, AGS (Abort Guidance System), was for guiding an abort should one become necessary. The mode switch for the rendezvous radar used by PGNS had four settings: Off, Auto, Manual, and Slew. The crew had been instructed to set the switch to Manual before beginning lunar descent. But now the M.I.T. people had decided to have the rendezvous radar keep track of where the command module was during the descent, so that it could take over an abort immediately if that ever became necessary. The Crew Procedures Change Sheet specified that before beginning the descent the mode switch for the rendezvous radar should be set to Auto instead.

The associated changes in the software were loaded into the LEM’s computer. Then, after further consideration, M.I.T. decided that the alterations introduced too many new procedural considerations too close to the launch date. But the software changes had already been installed, and to go through the elaborate procedures required to change them back again would be time-consuming. Someone suggested that, if they didn’t want to use the rendezvous radar for this purpose after all, they should just withhold the radar data that the PGNS needed to do its abort calculations, thereby preventing it from tracking the C.S.M during the descent phase. It was a simple and apparently no-risk fix.

Two mistakes were made. First, no one realized that withholding the information didn’t make the computer stop trying to read the rendezvous radar. All it did was give the computer the impossible task of trying to find a match for a meaningless angle whose sine was 0 and whose cosine was 0; and because computers do not know when tasks are impossible, they just keep trying to do what they have been told. The second mistake was in failing to send down another Crew Procedures Change Sheet canceling the previous instruction to set the rendezvous radar mode switch to Auto—no one thought it was necessary, because (or so they thought) the original change had been disabled. These two mistakes nearly caused the first lunar landing to fail.

On July 5, just eleven days before the launch, the White Team came to the end of its training for the lunar descent. The crew was to be deployed to the Cape the next day, and the July 5 sims would be their last. By this time, the raggedness was gone. The astronauts and the White Team weren’t dinging LEMs any more, and they weren’t aborting unnecessarily. Confidence was high.

The Apollo 12 crew was in the simulator—a normal procedure on the last training sessions, to let the prime crew watch another crew in action, and to give the controllers more work, prompting a crew that wasn’t as experienced. Everybody was expecting an easy session. It was the custom for the SimSups to ease off on the controllers on the last day of integrated simulations, to throw them some nominal sims with just a few minor glitches. The theory was that crashing the last sims before launch would be bad for morale.

On the next-to-last simulation of the day, the scenario included one of the computer alarms that Honeycutt had discovered. When the alarm went off, the controllers didn’t know what to do with it. Steve Bales, sitting at the Guidance console, saw it and didn’t have a clue what was happening. The computer seemed to be saying, “I’m overloaded. I can’t do all the work I’m supposed to be doing.” If that was really true, then they had to abort—which is the call Bales made, at 10,000 feet, still mystified by the alarm.

At the end of the day, Kranz called the Trench together. The Control Center had no mission rules that covered these computer alarms, and Kranz directed them to find out what every one of the alarms was and how it should be dealt with. Time before launch was so short at this point that there was no time for a formal Mission Techniques meeting.

It was a pain in the ass, many of them thought, because there were so many failure modes on a descent that were much more likely to happen. But they couldn’t just leave the alarms dangling. Kranz’s team got together with the M.I.T. people and began to work through them. As they did, they discovered a troublesome pattern. A program alarm could be triggered by trivial problems that could be ignored altogether. Or it could be triggered by problems that called for an immediate abort. How to decide which was which? It wasn’t enough just to memorize what the program alarm numbers stood for, because even within a single number the alarm might signify many different things. “We wrote ourselves little rules,” Garman remembered, “like ‘If this alarm happens and it only happens once, don’t worry about it. If it happens repeatedly, but other indicators are okay, don’t worry about it.’” Then again, if some alarms happen even once, or if other alarms happen repeatedly and the other indicators are not okay, then they should get the LEM the hell out of there. Trying to hold this list of permutations in their heads, the Guidance controllers went back to reviewing the many other more plausible problems they might encounter on the first lunar descent.