Apollo 11's "1202 Alarm" Explained

“Got the Earth straight out our front window.” As the lunar module Eagle yawed into a windows up orientation, Buzz Aldrin looked away from the computer to see the Earth nearly a quarter of a million miles away.

“Sure do,” agreed Neil Armstrong, adding, “Houston, [I hope] you’re looking at our Delta-H.” The Earth wasn’t his main concern for the moment. The mission’s commander was laser focused on getting the spacecraft down onto the Moon’s surface for the first time in history. He had just 30,000 feet to go …

“That’s affirmative,” replied Capcom Charlie Duke. The room full of flight controllers listened to the exchange while keeping a close eye on the numbers filling their screens, looking for any little anomaly that could force an abort.

Then came Armstrong’s voice over the radio again, this time marked a slight note of urgency. “It’s a 1202 … What is that? Give us a reading on the 1202 Program Alarm …”

The 1202 program alarm is featured is just about every retelling and dramatization of Apollo 11’s lunar landing. Understandably so; it was a dramatic moment in an already dramatic event that could have forced an abort and left the commander of Apollo 12, Pete Conrad, as history’s first man on the Moon. But it didn’t. As we know, Apollo 11 made it to the surface and the alarm has become little more than a story point. So what exactly was the 1202 program alarm that could have killed Apollo 11’s landing? To answer that question, we need to go back and understand a little more about how the Apollo Guidance Computer worked.

By the time Apollo missions flew to the Moon, the software program that ran the mission could fit — though only just fit — into a set of read-only magnetic cores. This meant the pieces of information could be called up at any time and run nearly simultaneously, which was pretty important. Take the moment of landing on the Moon, for example. The computer needed to take in a lot of data points simultaneously to facilitate a good landing. It had to know where the lunar module was and where it was moving, information called state vector. It needed to maintain the right attitude based on that position, as well as velocity, altitude, and engine performance data. It also needed to adjust the abort trajectory constantly, ready to get the crew back into orbit should something force an abort.

Now think about a full lunar landing mission for a second — getting into Earth orbit, burning the engine to travel towards the Moon, recovering the lunar module, adjusting the course mid-way to the Moon, getting into orbit, landing, leaving the Moon’s surface, and traveling home. You can start to appreciate how many pieces of information would be going through that computer at any given time.

For the sake of simplicity, each task (a task in this case would be a single mission event like the lunar landing) was broken down into parts. These parts or programs were manageable modules that could be run individually while rendering the whole system more reliable.

If you’re following along you can see how this creates a potential new problem. The Apollo Guidance Computer was a single processor computer, computer. So how could it run multiple programs — the parts that make up a whole mission event — simultaneously? Well, it didn’t. Not really. But between relatively fast processing speed and relatively slow human perception it was simultaneous enough to run the mission smoothly. The programs were also scheduled and run based on priority with measures in place to interrupt any program should something vital come up.

In the case of the Apollo Guidance Computer, it had a 12-word data area called the Core Set. This contained all the information to execute a given program. There were six of these Core Sets in the Command Module and seven in the Lunar Module. In each 12-word Core Set, processing information took up five words, one each for the program’s priority, entry point address, copy of the BBANK register, flags, and the last pointed to the Vector Accumulator or VAC area. The seven remaining words were left for temporary variables or extra storage … whatever they might be. They’re called Multipurpose Accumulator or MPAC.

So in short: twelve words in the Core Set, five words of memory to execute a program, and the seven MPACs deal with the extra information as needed.

Scheduling a program falls to the Executive. It starts by looking at the task’s starting address and its priority, then passes that to the NOVAC routine. This scans the core set to see if there is any available space for the program to execute, and if so where that space is. It then schedules and runs the program.

Through exhaustive testing, the team at MIT’s Instrumentation Lab designed the computer such that it would never be full at any point in a mission. There would always be space available for the next program, rules in place to interrupt a program if something needed to be run immediately, or space to schedule the program after whatever was currently being run through the computer. But when Apollo 11 was descending towards the lunar surface, the computer ran out of Core Sets. This is where the 1201 and 1202 program alarms come in.

Not long after the lunar module got into its 69 mile by 50,000 foot orbit in preparation for landing, the crew turned on their rendezvous radar to track the command-service module. This was was a safety measure. The radar tracked the CSM so it knew where to direct the lunar module in the event of an abort. The crew left the radar on in SLEW mode meaning it had to be manually positioned by an astronaut, and also meant that it wasn’t sending data to the computer.

What neither the astronauts nor the guys in Mission Control knew was that radar Coupling Data Units were flooding the Apollo Guidance Computer with counter interrupt signals. This was due to an oversight in the computer’s power supply design structure. These signals were taking up just a little bit of the computer’s processing time, and the spurious job kept running in the background, taking up space. So unbeknownst to anyone, this signal prevented vital programs associated with the landing from completing. When a new task was sent to the computer there was nowhere for it to go. The running and scheduled jobs were holding their Core Set and VAC areas.

Eventually the Executive found that there was no place to put new programs. This triggered the 1201 alarm signaling “Executive Overflow — No Core Sets” and the 1202 alarm signaling “Executive Overflow — No VAC Areas.” These in turn triggered a software reboot. All jobs were cancelled regardless of priority then started again as per their table order, quickly enough that no guidance or navigation data was lost. But it didn’t clear up the issue. The computer was still overloaded by the same spurious radar data, stopping new programs from running. In all, it triggered four 1202 alarms and one 1201 alarm.

Eventually Buzz Aldrin noticed a correlation. At the second 1202 alarm, he called down, “Same alarm, and it appears to come up when we have a 16/68 up.” The 16/68 code — Verb 16 Noun 68 — was used to display the range to the landing site and the LM’s velocity. The command in itself didn’t place a heavy load on the computer, but with the existing load that extra bit of processing power seemed to trigger the 1202 alarm. Realizing this, the solution was simple: ask Houston for that data instead of calling it up from the computer.

Houston, meanwhile, gave Apollo 11 a GO in spite of the alarms because of how spread apart they were — they came at mission elapsed time 102:38:22; 102:39:02; 102:42:18 (that was the 1201); 102:42:43; and 102:42:58. If they had been closer together it could have wiped out navigation data during a reboot, but being separated even by as few seconds as they were meant that that vital information was retained. The computer behaved exactly as designed, protecting itself in a way that wouldn’t cancel a lunar landing without just cause.

The 1202 program alarm wasn’t something either Neil Armstrong or Buzz Aldrin had seen in training. Their time simulators had been filled with other alarms, most of which had them reaching for the abort button. Which was the right response. In simulations you train for the right reaction. But when they saw the 1202 and 1201 program alarms it was the real thing, which meant the right response was completing the mission objective. They weren’t going to give up on landing on the Moon if they didn’t have to.

The guys in Houston had the same response. “We’re go on that alarm,” Charlie Duke called back up, though he wasn’t entirely calm when he said it. The astronauts and flight controllers watched the second 1202 alarm blare on board the Eagle, followed by a 1201 alarm three minutes later then the last two back-to-back 1202 alarms almost immediately.

“Eagle, looking great. You’re Go,” came Duke’s call from Mission Control. Thanks to a handful of clever computer programmers, he passed up that Apollo 11 was still clear to land on the Moon.

Sources: NASA; NASA; NASA; The Apollo Guidance Computer by Frank O’Brien.