Retroapollonasasoftwaretech-history
A Last-Minute Fuel-Valve Change Nobody Told the Software Team About Made Apollo 5's Guidance Computer Shut Down Its Own Moon-Lander Engine
On January 22, 1968, the first Lunar Module's descent engine ran about 4 seconds of a planned 39. Software engineer Don Eyles traced it to a valve change made shortly before flight, which slowed the thrust past what the software's delta-V monitor would wait for.
“The Lunar Module LM-1, also known as Apollo 5, was a 6-hour unmanned mission in earth orbit,” Eyles writes. “The date was January 22, 1968.” For the team writing the LM’s software at MIT, “it was our first flight.” The plan included “the first in-flight firing of the LM’s descent engine, lasting about 38 seconds.”
He remembers how it sounded on the loop: “We heard “Engine on”… several seconds passed… “Engine off”.”
The culprit was a safety check. “A small piece of code in SERVICER called the “delta-V monitor” had concluded that the engine had failed and sent an engine-off command.” The monitor didn’t judge the engine right away: “To give the engine time to come up to thrust, the delta-V monitor always waited some period of time after engine-on.” When the expected change in velocity hadn’t shown up by then, it called the engine dead.
The engine wasn’t dead. It was late, and Eyles says the reason has been told wrong. “Published accounts have attributed the slow DPS thrust buildup to the fact that the LM’s tanks were only partially pressurized. The author’s investigations show that the problem was elsewhere.” The control valve feeding fuel into the engine “was suspected of being leaky,” and because a leak “could have had explosive consequences,” the decision was “made, shortly before flight, to delay arming the engine until the time of ignition.” With the valve armed later, “the propellant had further to travel to reach the engine.”
The fix would have been one number. “It would have been easy for us to adjust the parameter that controlled how long the delta-V monitor waited before testing the engine — but nobody told us.”
Houston didn’t fight the software in flight. “Houston sent a signal to turn off the onboard computer. The main objectives of the LM-1 mission were achieved under ground control.” NASA’s own mission page says the burn “stopped prematurely due to overly conservative programming of the flight software” and that “despite the initial premature DPS shutdown, the mission was deemed a success.”
The software team took the hit anyway. “We who programmed the LM’s computer hung our heads in disappointment, and endured a public reaction that did not distinguish between a “computer error” and a mistake in the data.” NASA’s wording, “overly conservative programming,” still puts it on the code. Eyles credits the valve detail to a 2004 private conversation with George Silver, and the official histories he cites don’t tell it his way, so the cause stays one engineer’s account, never settled in print.
The pattern is older than most of the systems that repeat it. A check with a timeout encodes an assumption about how fast something else is, and the assumption lives in one team’s code while the thing it measures belongs to another. Eyles closes the episode by noting this “was not the last time that a seemingly innocuous parameter, relating to the performance of the descent engine, would come perilously close to ruining a mission.” Apollo 11’s landing alarms came from a different problem altogether, a radar interface that “stole approximately 13% of the computer’s duty cycle,” but it’s the same lesson about numbers nobody re-checked.