Tech Support On the Way To the Moon

In honor of Boston, this week I'm telling a little story about the Apollo Guidance Computer, which was designed and built at the Massachusetts Institute of Technology.

The Apollo 11 lunar module, just after undocking from the command module.
Source: National Geographic.

The Apollo Guidance Computer* gave Apollo astronauts the data they needed to pilot the command module and lunar module during lunar landing, ascent, and docking. There was so little room for error in these tasks that the precision afforded by a computer was necessary. When the Apollo Guidance Computer was built, it was a technological feat... but it is roughly comparable in terms of processing power to today's graphing calculators. Nowadays, if you have some programming expertise and a lot of spare time, you can actually build your own Apollo Guidance Computer, no MIT degree or MIT lab facilities necessary. I wish building a Saturn V rocket was that easy!

 * = Actually, there were two Apollo Guidance Computers aboard every flight to the moon. One aboard the command module, one aboard the lunar module. Plus, there was a launch computer inside the Saturn V rockets and an abort computer in the lunar module.

An engineer with a mock-up of the Apollo Guidance Computer interface.
Source: MIT.

While shockingly simple compared to today's computers, the Apollo Guidance Computer was a very capable piece of equipment. It could multi-task, performing up to eight different calculations at the same time. It could also prioritize its memory as needed. And, it was relatively small and lightweight, an important design feature on a mission that was already consuming nearly a million gallons of fuel just to leave Earth's gravity. At a time when room-size computers were common, the Apollo Guidance Computer weighed 70 pounds and occupied about one cubic foot of space.

An MIT Instrumentation Lab engineer runs tests on the Apollo Guidance Computer.
Source: MIT.

Like any modern computer, the Apollo Guidance Computer didn't always work perfectly. Any number of problems would trip it up, and it would respond by producing an error code. There were many, many possible error codes. Some error codes signaled computer malfunctions, some required immediate corrective action, and some could just be ignored. Astronauts and mission control staff devoted considerable training time to learning what each error code meant, and how they should respond.

The crew of Apollo 11, and the "moon."
Source: ontheunspeakable.tumblr.

NASA Flight Director Gene Kranz's autobiography, Failure Is Not an Option, tells an interesting story about these error codes. Astronauts and ground crew spent weeks and weeks practicing mock missions in advance of the Apollo flights. They'd run through these fake missions just like they were the real thing, with Simulation Supervisors throwing problem after problem at them. Sometimes, mission control would work out a solution in time to salvage the moon landing and save the fake flight. Sometimes they wouldn't figure out a solution in time and the simulation would end with a fake disaster.

A fisheye view inside one of the Apollo lunar module simulators.
Source: howstuffworks.com.

The Simulation Supervisors were always relentless, with one exception. They gave mission control a relatively problem-free flight for the final pre-launch simulation. That way, the practice runs would end on a high note, with mission control engineers feeling that they were completely prepared for the real flight.

So, a few days before the launch of Apollo 11, Kranz and his crew went into the final scheduled lunar landing simulation expecting an easy flight. During the practice descent, the Simulation Supervisor sent the lunar module's Apollo Guidance Computer a "1201" error code. Not a single engineer in mission control knew what this code meant. Without any idea of what had gone wrong, the only safe choice was to abort the landing.

Richard Koos, the Simulation Supervisor, gave mission control the bad news: calling off the landing was the wrong decision. The 1201 code just meant that the Apollo Guidance Computer was temporarily overloaded; it did not indicate an impending computer crash or any other mission-critical problem. Kranz and mission control had just (in pretend) wasted the Apollo 11 flight and ruined their chance at a moon landing because they hadn't known what the 1201 code was.

Crowds in Grant Park, Chicago watch the first moon walk.
Source: Washington Post.

Recounting the story in his autobiography, Kranz tells how furious and ashamed he was. Kranz, along with Jack Garman (the engineer charged with keeping track of Apollo Guidance Computer codes), Chris Bales (a guidance officer) all had that particular series of alarm codes seared into their brains. They would never forget what a 1201 (or a related code, 1202) meant.

Astronauts Charlie Duke, Jim Lovell, and Fred Haise in mission control during Apollo 11.
Source: Wikipedia.

A few days and a few hundred thousand miles later... the real Apollo 11 lunar module was descending to the moon with less than 10,000 feet to go when the Apollo Guidance Computer produced a 1202 alarm code, and then a 1201 alarm code. Neil Armstrong and Buzz Aldrin asked mission control what the alarms meant. Thanks to the final simulation, Kranz, Bales, and Garman knew the answer right away- they were "go" on the alarm! Capcom Charlie Duke told them they could ignore the alarms and keep descending. Just a couple minutes later the Eagle landed safely in the Sea of Tranquility!

Celebrating after the Eagle landed.
Source: wallcoo.net.

What caused the 1201 and 1202 alarms? The Apollo Guidance Computer was receiving too much radar data. Buzz Aldrin (an MIT grad!) had asked MIT engineers to design the computer to be able to track both radar readings from the lunar surface and the command module. This would allow a quick decision to land or return to the module. But the Apollo Guidance Computer couldn't properly track both sets of data. So at the stage in lunar descent when the alarms occurred, the computer was getting simultaneous readings from both radar systems, and it was causing brief system overloads. 

Sources: American Space; Popular Mechanics; NASA; doneyles.com; Gene Kranz, Failure Is Not an Option; Air & Space's The Daily Planet blog; Computer Weekly; Wikipedia.