Editing Apollo Guidance Computer (section)

== 1201 and 1202 program alarms ==<!--linked from [[Cycle stealing]]-->
[[File:AS11-36-5391 (21710608621).jpg|thumb|DSKY and [[Buzz Aldrin]] on the Apollo 11 [[Lunar Module Eagle|Lunar Module ''Eagle'']] en route to the Moon]]
[[Apollo PGNCS|PGNCS]] generated unanticipated warnings during [[Apollo 11#Lunar descent|Apollo 11's lunar descent]], with the AGC showing a ''1202 alarm'' ("Executive overflow - NO CORE SETS"),<ref>{{citation |url=https://history.nasa.gov/SP-350/ch-11-4.html |title=A Yellow Caution Light |first1=Michael |last1=Collins |first2=Edwin |last2=Aldrin |editor-first=Edgar M. |editor-last=Cortright |publisher=NASA |year=1975 |pages=Chapter 11.4 |place=Washington, DC |work=NASA SP-350, Apollo Expeditions to the Moon |isbn=978-0486471754 |access-date=2009-08-30}}</ref> and then a ''1201 alarm'' ("Executive overflow - NO VAC AREAS").<ref>{{Cite web|url=https://github.com/chrislgarry/Apollo-11/blob/master/Comanche055/EXECUTIVE.agc#L146|title=chrislgarry/Apollo-11|website=GitHub|access-date=2016-07-17}}</ref> The response of the AGC to either alarm was a soft restart. The cause was a rapid, steady stream of spurious [[Cycle stealing|cycle steals]] from the rendezvous radar (tracking the orbiting command module), intentionally left on standby during the descent in case it was needed for an abort.<ref>{{citation |url=https://www.nasa.gov/history/alsj/a11/a11.1201-pa.html |title=Apollo 11 Program Alarms |first=Peter |last=Adler |editor-first=Eric M. |editor-last=Jones |publisher=NASA |year=1998 |work=Apollo 11 Lunar Surface Journal |access-date=2009-09-01}}</ref><ref>{{citation |url=https://www.nasa.gov/history/alsj/a11/a11.1201-fm.html |title=Apollo 11 : 25 Years Later |first=Fred H. |last=Martin |editor-first=Eric M. |editor-last=Jones |publisher=NASA |date=July 1994 |work=Apollo 11 Lunar Surface Journal |access-date=2009-09-01}}</ref>

During this part of the approach, the processor would normally be almost 85% loaded. The extra 6,400 cycle steals per second added the equivalent of 13% load, leaving just enough time for all scheduled tasks to run to completion. Five minutes into the descent, Buzz Aldrin gave the computer the command ''1668'', which instructed it to periodically calculate and display DELTAH (the difference between altitude sensed by the radar and the computed altitude).<ref group="nb">More specifically, verb 16 instructs the AGC to print the ''noun'' (in this case, 68, DELTAH) approximately twice per second.  Had Aldrin known this, a simple ''0668'' (calculate and display DELTAH, once) would have only added approximately 5% load to the system, and would have only done so once, when ENTER was pressed.</ref> The ''1668'' added another 10% to the processor workload, causing executive overflow and a ''1202'' alarm. After being given the "GO" from Houston, Aldrin entered ''1668'' again and another ''1202'' alarm occurred. When reporting the second alarm, Aldrin added the comment "It appears to come up when we have a ''1668'' up". The AGC software had been designed with priority scheduling, and automatically recovered, deleting lower priority tasks including the ''1668'' display task, to complete its critical guidance and control tasks. Guidance controller [[Steve Bales]] and his support team that included [[Jack Garman]] issued several "GO" calls and the landing was successful.<ref>{{citation  |url=http://www.abc.net.au/science/moon/computer.htm |title=The Lunar Module Computer 
|editor-first=Edgar M. |editor-last=Cortright |publisher=NASA |year=1975 |work=Apollo 11 Lunar Surface Journal |access-date=2010-02-04}}</ref>

The problem was not a programming error in the AGC, nor was it pilot error. It was a peripheral hardware design bug that had already been known and documented by Apollo 5 engineers.<ref name="tales-from-the-lunar-module-guidance-computer">
{{citation |url=http://klabs.org/history/apollo_11_alarms/eyles_2004/eyles_2004.htm |title=Tales From The Lunar Module Guidance Computer |first=Don |last=Eyles |publisher=American Astronautical Society |date=February 6, 2004 |work=27th annual Guidance and Control Conference |place=Breckenridge, Colorado}}</ref> However, because the problem had only occurred once during testing, they concluded that it was safer to fly with the existing hardware that they had already tested, than to fly with a newer but largely untested radar system. In the actual hardware, the position of the rendezvous radar was encoded with [[synchro]]s excited by a different source of 800&nbsp;Hz AC than the one used by the computer as a timing reference. The two 800&nbsp;Hz sources were frequency locked but not phase locked, and the small random phase variations made it appear as though the antenna was rapidly "dithering" in position, even though it was completely stationary. These phantom movements generated the rapid series of cycle steals. It was caused by a radar switch set incorrectly, causing the cycle steals and thus a ''1202.''

[[J. Halcombe Laning]]'s software and computer design saved the Apollo 11 landing mission.  Had it not been for Laning's design, the landing would have been aborted for lack of a stable guidance computer.<ref name="tales-from-the-lunar-module-guidance-computer" /><ref>{{cite magazine |last=Witt|first=Stephen |date=June 24, 2019 |title=Apollo 11: Mission Out of Control |url=https://www.wired.com/story/apollo-11-mission-out-of-control/ |magazine=Wired |location=San Francisco |publisher=Condé Nast Publications |access-date=September 18, 2019}}</ref>