Faultory

Case file 58 · Engineering & technology

A computer that kept restarting

Apollo 11 landing, 1969: why did the guidance computer keep restarting, and why was it safe to land?

Subject
Apollo 11 program alarms (1969)
Reading
15 min
Evidence
5 exhibits
Reasoning
4 steps
Level
Advanced
The Apollo 11 Lunar Module Eagle in its landing configuration, seen against the Moon from the Command Module.
20 July 1969 The Apollo 11 Lunar Module Eagle, photographed in lunar orbit from the Command and Service Module Columbia. Photo: NASA · Public domain · Wikimedia Commons.
Illustrative signature. A strip-chart trace of computer load that stays high with brief spikes, standing in for repeated alarms and restarts (a sketch, not data). Drawn to explain the case, not plotted from source data.

01 · The briefing

Begin with the question.

On 20 July 1969, the Apollo 11 Lunar Module Eagle descended toward the Moon under the control of its Apollo Guidance Computer, which the crew read through a display and keyboard unit. About five to ten minutes after powered descent began, the computer began issuing program alarms. Alarm codes 1201 and 1202 meant that the executive had run out of resources for scheduled jobs, and each alarm led to a software restart. The landing was the most demanding phase of the mission, so the alarms mattered. The explanations discussed afterward included a possible error in how the crew had set the rendezvous radar switch. The mission report records the alarms as symptoms of possible computer overloading and records a decision to continue. This investigation separates what caused the overload from why the restarts did not stop the landing, and asks what the controllers knew when they judged the alarms acceptable. The record used here includes the 1971 Mission Report, the Lunar Surface Journal transcript and annotations, and a participant's memoir. Keep the question concrete: which resource ran out, what drove the load, and what evidence supported the decision to go on?

The Houston Mission Control room, with a large projected display of the Apollo 11 descent trajectory.
Where it happenedPhotographed 25 July 1969 The Mission Control room in Houston with a projected display of the descent trajectory, photographed five days after the landing. Photo: NASA · Public domain · Wikimedia Commons.

The timeline

  1. The Apollo 11 crew training summary records that about 30 percent of Armstrong's training hours, and 33 percent of Aldrin's, were in lunar module simulators.

  2. Apollo 11 launches from Kennedy Space Center, Florida.

  3. During powered descent, the computer issues five program alarms, starting with a 1202 at 102:38:22 mission elapsed time, and Eagle lands.

  4. Grumman test work on the rendezvous radar interface, cited in a report dated 9 August 1969, gives a maximum counter-interrupt drain of 13.36 percent and reproduces alarms similar to those in flight.

  5. The reformatted 1971 edition of the Apollo 11 Mission Report records the descent alarms as executive overflow and notes that the radar was set to SLEW with circuit breakers off for ascent.

A researched reconstruction for learning. These reasoning steps simplify a complex record; no score can capture the full history.

02 · The evidence

What does the record show?

An Apollo display and keyboard unit, the crew interface to the guidance computer, in a museum display.
On the evidence tablePhotographed 2018 An Apollo display and keyboard unit, the crew's interface to the guidance computer, at the Computer History Museum in 2018. Photo: ArnoldReinhold · CC BY-SA 4.0 · Wikimedia Commons.

Read each exhibit before settling on an explanation. The source links below every exhibit lead to the record behind it.

Exhibit 01

Five alarms in a short window

The mission report's event table lists five computer-determined alarms during descent: 1202 at 102:38:22, 1202 at 102:39:02, 1201 at 102:42:18, 1202 at 102:42:43 and 1202 at 102:42:58, all in mission elapsed time. The report says the alarms came five to ten minutes after the start of powered descent and that they are symptoms of possible computer overloading. It establishes the timing and the alarm types. It does not say how long the computer was overloaded at each moment.

Source record s2apollojournals.org

Exhibit 02

More than 10 percent of computer time

The mission report says the alarms were of the executive overflow type, meaning the computer could not complete all the processing requested in a computation cycle. It states that more than 10 percent of the computer's capacity was preempted by unexpected counter interrupts generated by the rendezvous radar's coupling data units, and that the computer normally runs at about 90 percent of capacity during peak descent activity. It establishes the cause class and the magnitude. It does not give the share at each alarm.

Source record s2apollojournals.org

Exhibit 03

The rendezvous radar switch in Slew

At 102:35:38 the Apollo Lunar Surface Journal transcript has Armstrong asking about Slew, and an annotation says this is where the rendezvous radar mode switch went to Slew, shortly before the alarms. A journal annotation attributed to Fjeld says that with the switch not set to LGC, the computer is continuously interrupted by radar tracking data, and that the computer was overloaded five times during the descent. A journal annotation also notes post-flight controversy about whether the crew had made a mistake. It establishes the switch position and the annotated explanation. It does not settle whether the procedure was wrong.

Source record s1apollojournals.org

Exhibit 04

Restarts that shed some load but not all

Eyles, a member of the guidance software team, explains the restarts. In P63 the software restart rebuilt only the most recent SERVICER job and flushed the stubs that had built up, so the problem partly cleared itself. Adding landing-site redesignation processing in P64 left the essential software with a duty-cycle margin of less than 10 percent, and three 1201 and 1202 alarms came within 40 seconds. Each restart flushed the executive queue but could not shed enough load. He describes the crew moving to attitude hold, then semi-manual P66, which eased the load. It is a participant's memoir rather than a contemporaneous log.

Source record s3doneyles.com

Exhibit 05

Houston's go decision

The transcript records the crew reporting the program alarm at about 102:38, and Houston replying Go after the 1202 was reported. A journal annotation says the 1202 was caused by data overflow in the computer, that the overflow concerned rendezvous radar pointing data the computer was programmed to treat as secondary, and that Steve Bales, the control room's expert on LM guidance, determined the landing would not be jeopardized. The same annotation says the team had not seen this alarm in simulation. It establishes the controllers' judgment and their stated reasoning. It does not show that the judgment was tested against the exact data flow.

Source record s1apollojournals.org

03 · Your reasoning

Follow the strongest explanation.

Choose an interpretation, then compare it with the evidence. You can revise your choice. The goal is understanding, not a perfect score.

Reasoning step 01 of 04

What was the most direct cause of the alarms?

Evidence-based explanation

The mission report and Eyles both attribute the alarms to counter interrupts from the rendezvous radar coupling data units, which fire when the radar switch is in Slew or Auto. The interrupts used a large share of the computer's time, so the executive could not finish scheduled jobs and raised alarms. The sources give slightly different figures, more than 10 percent in the report and about 13 percent in the memoir, but they agree on the mechanism.

Weigh it against

Exhibit 01Five alarms in a short windowExhibit 02More than 10 percent of computer time

Reasoning step 02 of 04

Which observation best supports overload over a failure of the guidance system?

Evidence-based explanation

The mission report states that the alarms did not occur continually, that proper navigation functions were being performed. Eyles describes the alarms as scheduling overflows, which are resource limits rather than broken guidance. A failed memory or sensor would more typically produce wrong results than a pattern of intermittent alarms with navigation still running. The sources do not describe every hardware test made during the descent.

Weigh it against

Exhibit 01Five alarms in a short windowExhibit 02More than 10 percent of computer timeExhibit 04Restarts that shed some load but not all

Reasoning step 03 of 04

Why was the decision to continue the descent defensible at the time?

Evidence-based explanation

The mission report notes that before flight it had been decided that bailout-type alarms would not by themselves prevent continuing the flight, although such alarms could break other mission rules. Houston's assessment treated the overflow as data the computer was programmed to ignore while it did more important work. The decision was a judgment made in real time on that basis, so it was reasoned rather than proven safe in advance.

Weigh it against

Exhibit 01Five alarms in a short windowExhibit 05Houston's go decision

Reasoning step 04 of 04

Which factor best explains how Houston could say Go within half a minute of the first 1202?

Evidence-based explanation

Eyles reports that Steve Bales, the guidance officer who gave the go, supported in the back room by Jack Garman of NASA, had taken part in a recent review of LGC alarms, which had deemed 1202 a go unless it occurred too often or the trajectory deviated. The ground's Go calls follow that rule. The journal also says the team had not seen this exact alarm in simulation, so the earlier review, rather than experience of this alarm, is the best-supported basis for the quick decision.

Weigh it against

Exhibit 05Houston's go decisionExhibit 04Restarts that shed some load but not all

04 · The findings

The chain behind the outcome.

The 1201 and 1202 alarms reported a shortage of computing resources, not a broken guidance system. The executive could not always finish its scheduled jobs in time. With the radar out of LGC control, its coupling data units sent counter interrupts, each taking one memory cycle of about 11.7 microseconds. The mission report says these took more than 10 percent of the computer's capacity, on top of a peak descent load of about 90 percent. An executive with no free core sets raised a 1202, and one with no free VAC areas raised a 1201. Restart protection rebuilt the most recent work and flushed stalled tasks, which cleared some backlog in P63. P64's extra landing-site processing left too little margin, and three alarms came within 40 seconds. The crew then eased the load by moving to attitude hold and semi-manual P66, and the lander touched down. Before flight, it had been decided that alarms of this kind would not by themselves prevent continuing the flight. A guidance specialist in Houston judged the overflow to be secondary data, and the controllers called Go. The alarms had not been seen in simulation, and the postflight tests of the radar interface came after the landing. The safety argument rested on evidence about the computer's behavior and on judgment made in real time, not on a prior test of this exact condition.

Contributing causes and conditions

  1. The rendezvous radar mode switch was in Slew, not under computer control, while the radar was tracking during descent.
  2. With the mode switch out of LGC, the resolver signals to the coupling data units came from a different 800-hertz supply than the guidance system's reference voltage, so any phase or amplitude difference between the two made them register false angle changes.
  3. Each counter interrupt used one memory cycle of about 11.7 microseconds, and at peak rates the interrupts took more than 10 percent of the computer's capacity.
  4. The executive could not finish scheduled jobs on time, ran out of core sets (1202) or VAC areas (1201), and restarted the software.
  5. Restart protection rebuilt only the most recent SERVICER job and flushed stalled tasks, which cleared some load in P63, but the added P64 processing left too little margin to stop the alarms.
  6. Houston judged the overflow to be secondary data, and the crew moved to attitude hold and semi-manual control, which reduced the computing load enough to land.

OutcomeApollo 11 program alarms (1969)

Take the method with you

  1. When an alarm fires during a fast, safety-critical sequence, ask which resource it reports and what the system keeps doing, not only whether it is an alarm.
  2. A rule set in advance, such as a go unless the alarm recurs or the trajectory deviates, lets a decision be made in seconds, but the rule should be checked against the evidence at the time.
  3. A design built for one kind of failure can give useful protection against another, but that is not a reason to rely on it without analysis.

You can read findings at any time. Exploring every reasoning step marks this case as complete in your notebook.

Open another investigation

The open record

Sources & further reading

Read the original record and its scope before relying on a conclusion. Source references support the exhibit summaries; Faultory’s reasoning prompts are editorial reconstructions.

  1. s1
  2. s2
  3. s3

Written and curated for Faultory by Yunus Emre Vurgun, with AI-assisted research and drafting. Sources and interpretations can need correction. Read our editorial standards or report an issue.

From the journal

Field notes that use this case

Keep investigating