Apollo 11

[quadz]

From the space-to-ground communication, 40 years ago today:
    ( quoted from http://history.nasa.gov/SP-350/ch-11-4.html )

EAGLE: 540 feet, down at 30 [feet per second] . . . down at 15 . . . 400 feet down at 9 . . . forward . . . 350 feet, down at 4 . . . 300 feet, down 3 1/2 . . . 47 forward . . . 1 1/2 down . . . 13 forward . . . 11 forward? coming down nicely . . . 200 feet, 4 1/2 down . . . 5 1/2 down . . . 5 percent . . . 75 feet . . . 6 forward . . . lights on . . . down 2 1/2 . . . 40 feet? down 2 1/2, kicking up some dust . . . 30 feet, 2 1/2 down . . . faint shadow . . . 4 forward . . . 4 forward . . . drifting to right a little . . . O.K. . . .

HOUSTON: 30 seconds [fuel remaining].

EAGLE: Contact light! O.K., engine stop . . . descent engine command override off . . .

HOUSTON: We copy you down, Eagle.

EAGLE: Houston, Tranquility Base here. The Eagle has landed!

HOUSTON: Roger, Tranquility. We copy you on the ground. You've got a bunch of guys about to turn blue. We're breathing again. Thanks a lot.

TRANQUILITY: Thank you . . . That may have seemed like a very long final phase. The auto targeting was taking us right into a football-field-sized crater, with a large number of big boulders and rocks for about one or two crater-diameters around it, and it required flying manually over the rock field to find a reasonably good area.

HOUSTON: Roger, we copy. It was beautiful from here, Tranquility. Over.

TRANQUILITY: We'll get to the details of what's around here, but it looks like a collection of just about every variety of shape, angularity, granularity, about every variety of rock you could find.

HOUSTON: Roger, Tranquility. Be advised there's lots of smiling faces in this room, and all over the world.

TRANQUILITY: There are two of them up here.

COLUMBIA: And don't forget one in the command module.

[kren.Z]

q

[quadz]

Cooool...!

Here's an interview with Allan Klumpp, the principal designer of the LM Computer Descent Guidance Software, about the hardware and software involved:

http://www.netjeff.com/humor/item.cgi?file=ApolloComputer

(Not sure why it's categorized under "humor" ...)

Really interesting interview ... I'll just paste a few excerpts here:

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 atleast 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
[...] Numbers were represented using
14-bit words in double-precision (i.e., 28 bits).  The 15th and
16th bit were for the sign of the number and for parity checking
(i.e., to make sure the chips were all in sync with the clock
pulses).  Calculations were fixed-point (not floating-point).

The on-board program, named "LUMINARY", was stored in read-only
core-rope memory which took months to manufacture (the program
fills about 10 cm of print-out).  Therefore the software had to be
in final form months before launch.  LUMINARY version 99 landed
Apollo 11.  Version 209 was the final version.

The computer also contained a small eraseable area of about 2K 14-
bit words to temporarily store variables in.  The computer was
built entirely out of integrated circuit NOR gates: one type of
gate for high reliablility.

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).  Incidentally, the Shuttle's software
is written in a language called HAL/S, named after Hal Lanning, the
author of MAC.  HAL/S is an improved version of MAC.

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.  This situation caused the computer to
issue alarms during the landing.  During a normal descent, the
guidance program, which brought the LM to its target landing site
using a minimum of fuel, would issue commands once every two
seconds.  Steering commands to the digital autopilot, which kept
the LM stable, were issued every 10th of a second.  Although the
landing, which had an 11-minute guidance phase, was successful, a
full minute's worth of guidance commands were never issued by the
computer due to rendezvous radar!
[...]
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.  The IBM 360 simulator showed Eyles' program worked
beautifully.  His routine was aboard Apollos 11 and 12 which
landed successfully.  However, telemetry transmitted during the
landings later showed something to be very wrong.  The engines were
surging up and down in thrust level, and were barley stable.  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
discrepency 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 enveloppe and allowed successful landings!

[reaper]

The computer also contained a small eraseable area of about 2K 14-
bit words to temporarily store variables in.  The computer was
built entirely out of integrated circuit NOR gates: one type of
gate for high reliablility.

...

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.

Interesting you'd think they would have tons of functional tests, testing all the conditions of the software.  They compiled the instructions by hand.  I wonder what the issues were, if the program couldn't work properly because of the way the operating system scheduled the process and memory access and allocation that were mentioned. 

edit:
oh it goes on to say what was going on.  still getting the alarms/errors seems a little wacky

[QwazyWabbit]

There were tons of functional tests. But as stated in the text, the rendevous mode was enabled during descent, a condition outside the normal modes tested. I believe the engineer involved in calling the GO at the first 1202 recognized this from one of their simulations on the LM hardware.

The 1202 and 1201 alarms were indications the computer was overloaded. Neil had already taken manual control and was flying the lander by hand to avoid the craters and boulders. There was no time to figure out why the overload was occurring and the intuition of the mission control lander engineers in the face of the alarms told them not to call abort. This is when you heard them say "same type, go". This was all they had time for. They didn't know the cause until long after the flight. The engineers were debugging the hardware and software continuously during the Apollo missions. This is rocket science, after all.

There were no fancy glass displays in the Apollo systems. I believe the computer displays were nixie tubes and dedicated legend plates with bulbs behind them. When the computer overloaded, all Buzz saw on the display was "1201 ALM", and he couldn't do much else with it except to scan his switches and hang on for the ride. It took long sequences of button presses to set up the computer or change any parameters and in the final landing regime there was absolutely no time for that. The state of the art in flight control computers at that time, they were leading edge. It was "thoroughly tested" in simulation on IBM 360. As you read in the text, the simulation parameters, based on the documentation, were incorrect and didn't reflect reality. You can't simulate reality if the basic data are incorrect. EVERY Apollo flight was a TEST flight.

You have to give the astronaut teams credit for getting into those machines and flying them as the experimental machines they were.

[|iR|Focalor]

You have to give the astronaut teams credit for getting into those machines and flying them as the experimental machines they were.

One word: Balls.

HUGE balls.