In the movie First Man we see that there were problems with some button, when Buzz said "We should tell them about that." Also there was an alarm, that they then turned off.

  • 13
    $\begingroup$ I guess we're overdue for a canonical answer about the 1202. $\endgroup$ Commented Jul 16, 2019 at 19:45
  • $\begingroup$ @Russel Borogove not only 1202, but also about some black button (during moon landing). $\endgroup$
    – R S
    Commented Jul 16, 2019 at 20:44
  • 1
    $\begingroup$ @RS I'm not much on watching videos. $\endgroup$ Commented Jul 16, 2019 at 21:04
  • 2
    $\begingroup$ @RS - since the movie clip you reference starts (with "we should tell them ...") just before they are "GO for powered descent", perhaps it is related to the real Aldrin saying, one minute earlier than the 'GO', "And, Houston, we got a 500 alarm early in the program." $\endgroup$
    – amI
    Commented Jul 17, 2019 at 4:23
  • 3
    $\begingroup$ The incident in the video does not show up in the voice transcript: apollo11.spacelog.org/phases/5 $\endgroup$
    – Hobbes
    Commented Jul 17, 2019 at 16:43

5 Answers 5


These were the "1202" and "1201" program alarms, which were warning signals that the lunar module's computer was becoming overloaded.

During Apollo 11's descent to the moon, the crew left the LM's rendezvous radar, which was used to find their way back to the command module, switched on in the "SLEW" mode, so it would be ready if they had to abort the landing.

This meant that the guidance computer was processing the data from the rendezvous radar at the same time as it was trying to run the landing guidance program. This nearly overloaded the computer's processing capability.

When Aldrin asked the computer to compute and display a certain figure called delta-H, this was just enough additional processing load to put the computer over the edge; it began dropping low-priority tasks like updating the display, but the software was designed to keep the high-priority tasks, like steering the lander, running. When it dropped the low-priority task it would activate the master alarm and display an error code, 1202. Aldrin and Armstrong weren't familiar with this code, so asked mission control for an explanation:

102:38:30 Armstrong: (To Houston) It's a 1202.

102:38:32 Aldrin: 1202. (Pause)

102:38:42 Armstrong (onboard): (To Buzz) What is it? Let's incorporate (the landing radar data). (To Houston) Give us a reading on the 1202 Program Alarm.

Fortunately, just days before Apollo 11 launched, the team working on the computer assembled a list of all the possible program alarms, and steps to be taken if they occurred. The notes for 1202 said that if it happened intermittently there was no need to abort. The controllers consulted the list, gave the go to CAPCOM Charlie Duke, who relayed it to Eagle:

102:38:53 Duke: Roger. We got you...(With some urgency in his voice) We're Go on that alarm.

A short while later, the alarm fired again. Aldrin made the connection that the alarm occurred when he was trying to monitor delta-H; mission control told the crew they could monitor delta-H from the ground.

A little later on, the computer started giving 1201 alarms, a very slightly different symptom of the same basic issue, and again they got the go:

102:42:19 Aldrin: Program Alarm. (Pause) 1201

102:42:24 Armstrong: 1201. (Pause) (onboard) Okay, 2000 at 50.

102:42:25 Duke: Roger. 1201 alarm. (Pause) We're Go. Same type. We're Go.

The alarms were very distracting, forcing Armstrong to direct his attention inside the cockpit right as he needed to be focused on finding a good landing site, which may have contributed to the long descent time and high fuel usage of the landing.

  • 7
    $\begingroup$ Note that "the crew left the LM's rendezvous radar, which was used to find their way back to the command module, switched on" was per the checklist. And it was not that it was "on", it was that the mode was in AUTO or SLEW. "Sunburst and Luminary", Eyles, p. 167 The reboots also blanked the DSKY display. $\endgroup$ Commented Jul 16, 2019 at 20:08
  • 1
    $\begingroup$ Note that the difference between the errors is that the 1201 refers to a lack of available core memory, whilst the 1202 refers to a lack of VAC (Vector Accumulator) memory. The jobs requested these for use, with the latter being requested if the core wasn't enough for what the job needed. $\endgroup$
    – Dan
    Commented Jul 18, 2019 at 16:26

What happened:

With just seven and a half minutes remaining before they were set to touch down on the moon, Armstrong and Aldrin reported a program alarm. "It's a 1202."

The 1202 alarm indicated that the guidance computer was being overloaded with tasks. It was having trouble completing its work in the cycling time available.

"We looked down at the list at that alarm, and, yes, right, if it doesn't reoccur too often, we're fine," reported Garman.

Give us a reading on the 1202 program alarm," Armstrong radioed, with a bit more urgency in his voice.

"We're go on that, Flight," Bales advised Kranz. Before the flight director could respond, capcom Charlie Duke relayed the news to the crew, "We're 'Go' on that alarm."

The alarms were not over, though. Less than minute later, there was another 1202 alarm, followed by three more — a 1201 and two 1202 alarms — in under 40 seconds.

"When it occurred again [it was] a different alarm but it was the same type," Garman recounted. "I remember distinctly yelling — by this time yelling, you know, in the loop here — "Same type!" and [Bale] yells "Same type!" I could hear my voice echoing. Then [Duke] says, "Same type!"

The cause:

So what was happening during Apollo 11, as I recall, was that repeated jobs to process rendezvous radar data (that of course were not really there) were scheduled because a misconfiguration of the radar switches. Thus, the core sets got filled up and a 1202 alarm was generated. The 1201 that came later in the landing was because the scheduling request that caused the actual overflow was one that had requested a VAC area.

What happened next in either case was what you described as, 'The computer has been programmed to recognize this data as being of secondary importance and will ignore it while it does more important computations.'

On Apollo 11, each time a 1201 or 1202 alarm appeared, the computer rebooted, restarted the important stuff, like steering the descent engine and running the DSKY to let the crew know what was going on, but did not restart all the erroneously-scheduled rendezvous radar jobs.

Root cause:

So what happened? Crossed wires. During the design of the guidance computer at MIT’s Instrumentation laboratory, Buzz Aldrin wanted the computer to be able to simultaneously handle radar data from the lunar surface and the Apollo Command and Service Modules in lunar orbit, just in case Apollo 11 needed to abort the landing and rendezvous with the CSM. Despite discussions, the added capability was never built into the system, to Aldrin’s surprise on July 20th. (Simulations had never fully tested the feature and failed to reveal its absence.)

  • 3
    $\begingroup$ I just read Sunburst and Luminary by the guy who programmed this. His chapter on it is, I think, the definitive write-up, but this is a decent summary. Your last sentence is maybe misleading, though - the problem was found on the ground independently twice before the flight. I'll write a supplemental answer on that. $\endgroup$ Commented Jul 16, 2019 at 19:54
  • $\begingroup$ I think a few details around that go as follows: During training and simulation, the LM rendezvous radar was switched off because it wasn't needed. However, during the Apollo 11 lunar descent, the radar was switched on because the crew thought it to be a wise precaution in case of an abort - a deviation from checklisted and practiced procedures. $\endgroup$
    – Anthony X
    Commented Jul 16, 2019 at 20:00
  • 1
    $\begingroup$ @AnthonyX according to Eyles (LEM guidance programmer) the crew was following the checklist. $\endgroup$ Commented Jul 16, 2019 at 20:16
  • $\begingroup$ @OrganicMarble I'll have to see if I can find my source... maybe wasn't a reliable one. $\endgroup$
    – Anthony X
    Commented Jul 16, 2019 at 20:37
  • $\begingroup$ It's a common misconception - the Eyles book lists the common misconceptions and goes through each one. $\endgroup$ Commented Jul 16, 2019 at 20:38

Supplementary answer (these answers cover it well, but there are a few other things of interest):

For anyone interested in the details of this issue, the book Sunburst and Luminary by Don Eyles has, I think the definitive treatment. Eyles was the LEM descent guidance software programmer!

Eyles explains that the problem was actually found on the ground twice, independently.

The first time was by Grumman running tests at Bethpage on LM-3 in May 1968.

The report correctly diagnosed the problem but then, instead of proposing a fix, dismissed the issue with the breathtaking rationalization that the rendezvous radar switch would only ever be in SLEW or AUTO if the PGNCS had failed - oblivious to the fact that this unguarded switch had the potential to cause the PGNCS to fail, as it almost did on Apollo 11.

(S&L, page 168)

The second time was by George Silver, an MIT employee stationed at KSC.

George Silver identified the rendezvous radar interface problem at Cape Canaveral a month or two after Grumman discovered it in Bethpage. He wrote up the problem....and devised a solution that required a small hardware change.....We can only fault Silver for not making a bigger stink. He might not have gained approval for his fix, but a larger group would have known about the problem....

(S&L, page 169)

The crew had the radar configured per the checklist, but the checklist had been updated very shortly before flight and therefore had not been exercised very much in training.

The baseline circa 1965 was to have RR on, mode in LGC, and tracking the CSM during the descent. At some point...the plan became RR off, mode in LGC...in June 1969...the plan became RR on with mode in AUTO or SLEW.

(S&L, page 167)

Explanation of the radar mode switch:

The mode switch had three positions: LGC, AUTO, and SLEW.

  1. LGC (LEM Guidance Computer) - the antenna angle resolvers used as their reference signal an 800-Hz signal from the PGNCS and therefore the data made sense to the guidance computer
  2. SLEW - Manual slew mode. The 800-Hz reference signal came from LEM hardware
  3. AUTO TRACK - Antenna tracks an acquired target. The 800-Hz reference signal came from LEM hardware

enter image description here

(Image from Apollo Operations Handbook - Lunar Module - LM10 and subsequent - Volume 1)

If the switch was not in LGC and the radar was on, the LGC could have problems processing the data depending on the phase relationship between the two 800 Hz signals, and this relationship was completely random, determined by when the LGC was powered on. The hardware fix proposed by Silver would have synchronized the two signals, eliminating the problem.

(Condensed from S&L pages 159-160)


Addressing the "problems with some button" part of the question. Following is a quotation from a news source.

“It's generally been reported that when Armstrong returned the lunar module after the moon walk, his backpack broke a circuit breaker switch," said the source, an employee of North American Aviation who is one of the last to see Apollo astronauts before they are locked in their spacecraft.

“When that happened, it knocked out the normal ascent sequence firing program.”

Fortunately, Aldrin used a pen on the broken part of the switch to get it to work.

“But if he hadn't been able to, that would have thrown the whole ball of wax over to the abort guidance sequence," the story continued.

“And unless he could have activated it, there is no back-up for it– they would have had real problems. The only hope would have been the 16 little jets on the reaction control system. And I doubt if that could have taken them back to the command module.”

  • 1
    $\begingroup$ I didn't get about "ball of wax", could you explain? $\endgroup$
    – R S
    Commented Jul 16, 2019 at 20:37
  • 5
    $\begingroup$ @RS "the whole ball of wax" is an American colloquial expression meaning "everything" - emphatically. grammarist.com/idiom/whole-ball-of-wax $\endgroup$ Commented Jul 16, 2019 at 20:39
  • 2
    $\begingroup$ @Fred I mean this button (before the walk): youtu.be/XtnIfu1qkoM?t=100 $\endgroup$
    – R S
    Commented Jul 16, 2019 at 21:28

Regarding the "button" problem you were pointing to more precisely in another comment:

According to the Apollo 11 Journal, around the 102:03:35 mark and before, it seems related to the CWEA switch (Caution and Warning Electronics Assembly)


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.