DSKY — Volume 13 — Landing on the Moon: The Descent Programs

About This Volume

There is a temptation, looking back, to tell the story of the lunar landing as a story of a machine that flew itself, or — depending on which version you grew up with — as a story of a heroic pilot who switched the machine off and landed by hand. Both versions are wrong, and the truth is far more interesting than either. The Apollo Guidance Computer did not replace the pilot, and the pilot did not override the computer. Instead, in the last twelve minutes of a quarter-million-mile journey, the two of them invented a new way of flying: a continuous negotiation in which the computer held the spacecraft steady, did the brutal arithmetic of orbital mechanics, and offered the human a steering wheel calibrated in degrees scratched onto a window.

This volume is about the descent programs — the choreography of software that took the Lunar Module from a fifty-thousand-foot whisper of orbital velocity down to a three-foot-per-second touchdown in a sea of grey dust. It is about the young man at MIT who wrote much of that software, the elegant little display trick that let a commander point at the Moon and say “not there, there,” and the four-day-old machine that, on 20 July 1969, found itself aiming Neil Armstrong at a field of boulders.

The famous 1202 program alarms of Apollo 11 are not the subject here — that drama, and the priority-scheduling design that made it survivable, belong to Volume 12, which you should read alongside this one. Here we are concerned with the flying.

The Shape of a Powered Descent

Powered descent began with the spacecraft skimming the lunar surface in a low orbit, travelling roughly 5,500 feet per second — about Mach 5 in terrestrial terms, though there is no air on the Moon to make the comparison mean anything. The Lunar Module was flying backwards and face-down relative to its motion, its single descent engine pointed forward along the direction of travel so that its thrust would act as a brake. Some fifty thousand feet below and a quarter of a million feet of ground-track ahead lay the landing site. The entire job of the descent was to trade all of that speed and altitude for a soft, vertical arrival, while keeping enough propellant in the tanks to do it.

The AGC divided this job into a sequence of numbered programs, each one a distinct phase of flight with its own guidance law, its own targets, and its own division of labor between silicon and human. The major programs were P63, P64, and P66, with P65 and P67 waiting in reserve. They ran in order, each handing off to the next as the spacecraft crossed an invisible gate in the sky.

P63 — The Braking Phase

The descent opened with Program 63, the braking phase — the long, violent, fuel-hungry burn whose entire purpose was to kill the LM’s orbital velocity. The crew armed it, the computer lit the descent engine, and for roughly the next eight minutes the AGC steered the spacecraft along a carefully computed trajectory, throttling the engine and adjusting attitude to bleed off speed.

P63 is where the spacecraft did the heavy lifting. It slowed the Lunar Module from about 5,575 feet per second to less than 500, guiding it from fifty thousand feet of altitude and roughly 1.5 million feet of horizontal range down to a point about 7,700 feet up that the engineers called high gate — a term borrowed, like much of the descent’s vocabulary, from aircraft approach practice. Through almost all of this the crew was face-down and facing away from the Moon, flying on instruments and on faith, watching the DSKY confirm that altitude and velocity were tracking the plan. They could not yet see where they were going. The computer could not see it either, of course — it was navigating by inertial measurement and landing radar — but it knew, to the arithmetic, exactly where it intended to put them.

P64 — The Approach Phase, and the First Look

At high gate the computer rolled the spacecraft and pitched it gradually toward upright, and Program 64, the approach phase, took over. This was the moment the crew had been waiting for: as the LM came toward vertical, the landing site swung up into the commander’s window for the first time. For the next two and a half minutes — P64 typically ran about 146 seconds — the computer flew the spacecraft from roughly 7,700 feet down to around 500 feet, carrying it from well short of the site to almost directly overhead.

P64 is the phase built around the human eye. The guidance law was deliberately shaped to give the commander a steady, comprehensible view of the approaching ground, and the program continuously computed where on that ground the computer was currently steering. It then offered that information to the commander through one of the most elegant pieces of human-machine design in the whole program: the Landing Point Designator. We will come back to it, because it deserves its own section.

P65, P66, P67 — The Last Five Hundred Feet

Below P64 the design forked, depending on how much the commander wanted to do himself.

P65 was the fully automatic endgame: a velocity-nulling program that would zero out the spacecraft’s horizontal motion, hold a steady rate of descent of about three feet per second, and lower the LM straight down onto whatever spot it was over — no further position control, just a patient vertical settling. Had the crew done nothing at all, P65 would have engaged automatically near 150 feet and landed the spacecraft on its own.

P66 — the program that actually flew most of the Apollo landings to touchdown — was the shared-control mode, and it is the heart of this volume’s argument. In P66 the commander threw the guidance-mode switch from “automatic” to “attitude-hold” and clicked the rate-of-descent (ROD) switch, and control split cleanly in two. The human now controlled the spacecraft’s attitude — which way it tilted, and therefore which way it drifted horizontally — flying it like a hovering helicopter with the hand controller. The computer kept control of the descent engine’s throttle, holding whatever rate of descent the commander dialed in, nudging it up or down a foot per second at a time with each click of the ROD switch. The human chose where; the machine managed how fast down. Neither could have done the job alone, and that division is the template for every fly-by-wire aircraft since.

P67 was the final fallback: full manual, with the computer disengaged from controlling the vehicle entirely, still faithfully displaying altitude and descent rate but no longer flying. It was there if everything else failed. It was never needed for a landing.

Don Eyles

Somebody had to write all of this, and a great deal of it was written by a young man named Don Eyles.

Eyles came to the MIT Instrumentation Laboratory — the Draper Lab, as it would later be called — in 1966, a twenty-something Boston University mathematics graduate with no particular aerospace pedigree, looking, by his own cheerful account, for interesting work in Cambridge. He was handed the lunar landing. Beginning with the unmanned Apollo 5 test of the Lunar Module and continuing all the way through Apollo 17, Eyles was responsible for much of the onboard software that flew the descent and landing — the guidance equations of P63, P64, P65 and P66, the logic that read the landing radar, the code that drove the very LPD display we are about to examine.

It is worth pausing on what that means. The programs in this volume were not the anonymous output of a faceless agency. They were the work of a small, identifiable team of human beings, several of them barely out of university, writing rope-memory code that a few dozen astronauts would bet their lives on. Eyles wrote about it later with rare candor — the all-nighters, the simulator sessions with the astronauts, the arguments over a single throttle command — in a memoir, Sunburst and Luminary, named for the two software builds he is most associated with.

His most celebrated single intervention came not on Apollo 11 but on Apollo 14, when a faulty abort switch in the LM’s cabin kept randomly signaling “abort” during the descent — a glitch that, untouched, would have caused the computer to throw away the landing the instant the engine lit. With the spacecraft already in lunar orbit and a landing only hours away, Eyles and his colleagues devised a sequence of DSKY keystrokes the crew could enter to fool the software into thinking it was already in an abort, so that it would ignore the spurious switch and fly the descent anyway. It worked. Antares landed. Eyles received a NASA Public Service Award, and a permanent place in the folklore of people who saved a mission with a keyboard.

The Landing Point Designator

Now to the small miracle that ties this volume together.

During P64, the AGC faced a communication problem that no amount of computing power could solve by itself: it knew, precisely, where it was steering the spacecraft to land — but the commander, looking out the window, had no way of knowing which patch of the rushing grey ground that was. The computer could not point. The window had no cursor. How do you let a machine show a human a specific spot on the Moon, using nothing but a number?

The answer was the Landing Point Designator, or LPD, and it is so simple it feels like a magic trick. Onto the commander’s triangular forward window, the engineers etched a vertical scale of angle markings — a reticle, calibrated in degrees, on both the inner and outer panes so that they lined up only when the commander’s eye was in exactly the right place. The scale measured the down-angle: how far below straight-ahead a sightline pointed.

During the approach phase, the computer continuously calculated the angle from the commander’s eye down to the spot it was currently aiming for, and displayed that angle as a two-digit number on the DSKY — in the right-hand digits of Register 1, paired with the LPD’s azimuth information. The commander would glance at the DSKY, read the number — say, 47 — then look out the window, find the 47 mark on the etched scale, and follow that sightline down to the surface. Wherever his gaze landed was the spot the computer intended to touch down. The DSKY and the window together formed a primitive but completely functional head-up display, turning an abstract guidance solution into a finger pointed at a real crater.

And then the genuinely radical part. If the commander looked down the LPD sightline and did not like what he saw — a crater, a boulder, a slope — he did not have to take over the spacecraft to fix it. He simply nudged the hand controller in the direction he wanted to move the target: forward, back, left, right. Each click told the computer to shift the aim point a small increment downrange or crossrange. The AGC accepted the correction, recomputed its trajectory to the new spot, and updated the LPD number accordingly — all while staying in fully automatic flight. The commander could redesignate the landing site a dozen times, walking the touchdown point across the lunar surface with little flicks of his wrist, and never once take manual control. He was editing the computer’s intentions, not overriding them.

This is the partnership in miniature. The machine did the flying and the arithmetic; the human did the judging and the choosing; and the LPD was the shared language between them — a number on a glass display, a scale on a glass window, and a steering input that meant “keep flying, but aim a little more over there.”

Apollo 11 — Eagle and the Boulder Field

Which brings us to 20 July 1969, and to the limits of even the best automation.

Eagle’s descent did not go smoothly. The spacecraft came in long, overshooting its target by several miles, for reasons traced afterward partly to residual velocity from undocking and a slightly under-pressurized tunnel. And then, beginning at about high gate, the computer started flashing program alarms — the now-legendary 1202 and 1201 alarms, the executive-overflow warnings that nearly aborted the landing and that are the subject of Volume 12. We will not retell that story here, except to note its consequence for the flying: the alarms pulled Armstrong’s and Aldrin’s attention inside the cabin, onto the DSKY and the comm loop with Houston, during the very minutes when Armstrong most needed to be looking out the window and reading the LPD.

When he finally did look — as P64 brought the site up into view and the computer dutifully displayed its LPD angle — Armstrong followed the sightline down and saw that the AGC, flying flawlessly, was steering them straight into trouble. The computed touchdown point lay in the boulder-strewn ejecta field around a sharp crater later named West Crater, a roughly three-hundred-foot pit ringed with rocks “the size of Volkswagens,” as the popular telling has it — rocks big enough to wreck a landing gear or tip the spacecraft over.

This was exactly the situation the descent’s whole design anticipated. Armstrong could have redesignated with the hand controller and let P64 retarget; in the event, with the site rushing up and the boulder field spread across his intended path, he did something more decisive. He switched into P66 — the shared-control rate-of-descent mode — took the spacecraft’s attitude into his own hands, and flew level. Pitching the LM back to near-horizontal, he skimmed it forward across the lunar surface, holding altitude while the computer obediently managed his descent rate, hunting past the boulders for a clear patch of ground. It was, in effect, a low-altitude reconnaissance flight improvised on the spot, made possible only because the software let him take the steering without taking the throttle.

The flying ate fuel. As Armstrong searched, Aldrin called out altitude and rate from the DSKY, and Houston began counting down the propellant. The famous calls of “60 seconds” and “30 seconds” were Mission Control’s estimate of fuel remaining before a mandatory abort. Eagle settled onto the Sea of Tranquility with the gauges nearly dry — telemetry at the time suggested something like seventeen seconds of margin, though later analysis put the real figure closer to forty-five. Either way, the first humans to land on another world did so with under a minute of fuel called, flying a hybrid of human hand and computer throttle that neither the pilot nor the programmers had rehearsed in quite that combination.

Apollo 12 — Pinpoint

If Apollo 11 proved you could land on the Moon, Apollo 12, four months later, proved you could land exactly where you meant to — and that the descent guidance could be trusted to the precision of a parking space.

The goal was audacious: set the Lunar Module Intrepid down within walking distance of Surveyor 3, an unmanned probe that had been sitting in a crater since 1967, so that Pete Conrad and Alan Bean could walk over and cut pieces off it. Hitting a specific crater after a quarter-million-mile flight and a twelve-minute powered descent required correcting the kind of downrange error that had carried Apollo 11 miles long. The solution lived partly in the navigation: a couple of minutes into powered descent, controllers uplinked a correction that shortened the computed range by about 4,190 feet, nudging the AGC’s solution onto the trajectory that would thread the needle.

It worked spectacularly. Conrad, flying the last few hundred feet semi-manually in P66, brought Intrepid down about 535 feet from Surveyor 3 — close enough that the spacecraft’s exhaust actually sandblasted the old probe. It was the first true pinpoint landing on another world, and its significance went far beyond a single mission: it told NASA’s planners that future crews could be sent to scientifically chosen sites in rough, interesting terrain, confident that the descent programs would put them where they aimed.

The J-Missions — Flying into the Mountains

The confidence Apollo 12 bought was spent on the J-missions — Apollo 15, 16 and 17 — the long-duration scientific expeditions that deliberately went to the kinds of places earlier planners would never have risked.

Apollo 15 flew into Hadley-Apennine, a site tucked against a mountain front so tall that the standard shallow approach simply would not clear it. The descent programs were retargeted for a far steeper trajectory — an approach angle of around 25 degrees, against the 14 or 15 degrees flown on earlier missions — so that Falcon could pitch over the twelve-thousand-foot wall of the Apennines and descend into the narrow plain beyond. The same software, the same P63-P64-P66 sequence, the same LPD on the window — but now flying a descent profile that would have been unthinkable in 1969, into terrain rough enough that Falcon came to rest tilted nearly ten degrees with one footpad hanging over the lip of a small crater. Scott and Irwin landed safely, several hundred meters from the aim point, in mountains that earlier mission rules had ruled out of bounds.

That progression — from “can we land at all” on Apollo 11, to “land beside the Surveyor” on Apollo 12, to “land in the mountains” on Apollo 15 — is the measure of how thoroughly the descent programs were trusted. The code Don Eyles and his colleagues wrote did not just work once. It became infrastructure: a reliable, retargetable foundation that mission planners could push into ever-harder geometry, secure that the partnership of computer and commander would hold.

The Point

It is easy, watching the grainy films of Armstrong hunting for a clear spot with the fuel running out, to read the lunar landings as the moment the human triumphed over the machine — the brave pilot seizing the controls from a computer that was about to crash him. And it is just as easy, reading the guidance reports, to read them the opposite way: a machine so capable it could have landed entirely on its own, the human a nervous passenger.

Both readings miss what actually happened, which was something genuinely new. The AGC did not replace the pilot, and the pilot did not switch off the AGC. P66 was not “manual flight”; it was a careful, deliberate split of the flying task, with the computer holding the throttle steady so the human could spend all of his attention on choosing a place to live. The LPD was not the computer telling the human what to do, nor the human telling the computer what to do; it was a shared sentence, spoken half in a DSKY number and half in a flick of the hand controller, that meant let’s aim over there.

This is fly-by-wire before the phrase was common — control of a vehicle mediated through a computer that is always in the loop, always doing the part it does best, always leaving the human the part the human does best. Every airliner that lets a pilot “ask” for a bank angle and trusts the flight computer to deliver it, every spacecraft that lands itself while a human supervises, every drone steered by a wrist while software holds the hover — all of them are descendants of those twelve minutes over the Sea of Tranquility, when a four-day-old machine and a test pilot worked out, in real time and on the first try, how to fly something together. Volumes 14 and 16 follow that thread out of Apollo and into the world it made.

Next — Volume 14: The Whole Mission — Command Module, LM & Fly-by-Wire.