Sunday, 20 July 2008

Thirty Nine Years Ago

They so nearly failed. The 1201 alarm and 1202 alarm were indications of the landing computer overloading and malfunctioning. The "30 seconds" call indicates that that is how long they had before either landing or aborting.

The story of the Apollo Mission Computer makes fascinating reading. :
The LM and CM had identical computers on board, each the size of a shoe box. Each contained a total storage capacity of 36K of 14-bit words. This means total storage was roughly equal to the 64K bytes of a Commodore-64 computer. The LM's computer had a "memory cycle time" of 11.7 micro-seconds. However, virtually all cpu operations required at least 2 clock cycles making the effective memory cycle time 23.4 micro-seconds, i.e., it effectively ran at only about 43 kHz (0.043 MHz)! Note that the original IBM PC-XT ran at 4.77 MHz...
Allan, his friend Don Eyles, and about 300 others wrote their programs in the first high-order computer language, called MAC (MIT Algebraic Compiler), then compiled it BY HAND into assembly language, which they typed onto punched cards (there were no terminals or text editors).
The LUMINARY program consisted of many subprograms which were priority driven, i.e., they took turns executing according to their priority. Each program would move data in and out of the very small eraseable area of memory (2K in size). The biggest debugging challenge was to keep programs from erasing, or "overlaying", another program's data at inappropriate times. If too many tasks were demanding the computer's time, it would simply delay or THROW AWAY what it had been working on, issue an alarm, and start working on the new item.

Such frightening alarms occurred during the Apollo 11 landing (first moon landing). If you listen to recordings of the landing, you will hear the Capcom say "1201 alarm" and "1202 alarm." The astronauts' checklist had erroneously called for the astronauts to turn on the rendezvous radar before initiation of the descent. Subsequently, the program that managed the radar began demanding too much of the computer's spare margin of time. The power supply for the radar was not properly synchronized with the LM's main power supply. Consequently, as the two power supplies went in and out of synchronization, the rendezvous radar generated many spurious input signals to the LM's computer. In responding to these signals, the computer delayed some of its guidance calculations and left others unfinished.
LUMINARY was never completely bug free. Allan told me about a fascinating series of events that could have easily prevented the first moon landing and might have caused disaster. Allan was the principal designer of the LM's descent guidance program which steered the LM by gimballing and throttling the descent engine. Whenever the computer commanded the engine to increase or decrease thrust, the engine (and LM) reacted after a short time lag.
Allan's descent program needed a routine to accurately estimate the new thrust level, which could be accomplished by reading the "delta-V" (change in velocity) measured by the LM's accelerometers. He wrote a short routine that took into consideration, i.e., compensated for, the engine's lag time, which TRW's "interface control document", full of useful information for the programmers, said was 0.3 seconds. It took 0.3 seconds for the LM's descent engine to achieve whatever thrust level the computer might request.
The final version of the thrust routine, which was put into the LM, was written by Allan's friend Don Eyles. Eyles was sufficiently enthusiastic about the programming challenge that he found a way of writing it which required compensating for only 0.2 of the 0.3 seconds.
A guy at Johnson Space Center called Allan and informed him that the LM's engine was not a 0.3-second-lag engine afterall. It had been improved some time before Apollo 11's launch such as to lower the lag time to only 0.075 seconds. Correction of this item in the interface control document had simply been overlooked. Once this discrepancy was discovered, the IBM 360 simulator was reprogrammed to properly simulate the actual, faster engine. Running on the simulator, Don Eyle's thrust program, with the 0.2-second compensation, exhibited the surging that had occured on the real flights. But here's the most interesting fact: the simulator also showed that had Allan Klumpp chose to "correct" Don Eyles' program by compensating for the full 0.3 seconds that was printed in the document, the LM would have been unstable and Apollo 11 would never have been able to land. By pure luck, Don Eyles was creative enough to write the thrust routine in a way that kept the LM just inside the stability envelope and allowed successful landings!
Writing spacecraft avionics software is hard, and it's so very easy to get things wrong in minor ways, that have catastrophic consequences. Omitting updates to Interface Control Documents are one of the thousand and one ways where you can commit canine intercourse.

And on a personal note... I, along with the rest of class 6A at Newport Primary School watched that One Small Step in glorious black-and-white. Australia didn't have colour television then. It had been about 12 months since I picked the name "Zoe", and vowed that in 2001, I'd be working on a space project. I thought the first of those events was inevitable, but the last would be tricky. In a way I was right, just not quite in the way I thought. I managed both though. It took about as much luck, as well as the expected heroic efforts, to achieve as the lunar landing. Mostly luck, and I know it.


Anonymous said...

Ah, but is there an emulator for that computer?

RadarGrrl said...

...and does it run under DOS?

Zoe Brain said...

Yes, there is an emulator. It runs under Linux, Windows, and Mac OS 10.2 or later.

A rather more user-friendly version which uses the same algorithms is at EagleLander.

UWE Bristol has a powerpoint presentation on the subject, giving details about the foibles of the AGC (Apollo Guidance Computer) too.