|Jack Ganssle's Blog
This is Jack's outlet for thoughts about designing and programming embedded systems. It's a complement to my bi-weekly newsletter The Embedded Muse. Contact me at email@example.com. I'm an old-timer engineer who still finds the field endlessly fascinating (bio).
For novel ideas about building embedded systems (both hardware and firmware), join the 28,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
SUNBURST and LUMINARY – An Apollo Memoir
August 22, 2018
I read voraciously and am particularly fond of books about the space program. The Lunar Module is a family spacecraft. My dad and Bob Rosenthal (my sadly-departed mentor) invented it in the 1950s. They called it the "lunar taxi" and proposed it to NASA while working for Grumman. Grumman lost the bid, but later NASA recompeted the LM and the company won the job. I remember climbing on LMs on the production line while quite young.
Don Eyles has a new book about the LM's software. SUNBURST and LUMINARY were the names of the two flight versions of that code, and his book recounts six years of his life writing and testing the landing software. This is a book only a techie could enjoy as it's rife with acronyms (an appendix cheat sheet helps a lot) and there's lots of intricate detail about aspects of how the code worked. Some of it I couldn't follow.
The book starts uninterestingly, with, I thought, a rather poor writing style. But it quickly picks up steam as he delves into the LM program itself. The plodding initial style gives way to wittiness and flashes of brilliance. When he's covering details of the software it's heavy going, but the story captured my interest. A non-software person would be completely at sea.
At first it appeared he was responsible for all the LM code, but it turns out that later in the book he says he wrote 2200 lines of the final 36,000-line program. I think he's underselling himself as there were hundreds of versions of the code, a number of which had truly unique algorithms that never flew.
We're all familiar with the 1201 and 1202 error codes that plagued Apollo 11; his explanation of these excels. And one is left rather astonished at the brilliant architecture of the system that could handle all sorts of unexpected upsets. Turns out there were some hair-raising problems discovered in several missions that could have, but didn't, cause aborts or loss of the spacecraft.
The book does have 7 glossy pages of black and white pictures – some rather odd, like one of a band he momentarily played bongos for. I wished for more, as there are some compelling images extant from the Apollo program.
There's a well-known story about how on Apollo 14, with the LM and CM separated in lunar orbit, a solder ball shorted out an abort switch. Legend maintains that an FBI limo picked him up at home and raced him to MIT for a patch to the program. That's not at all correct. He was already at MIT – who would miss a landing? And, surprisingly to me, he did not patch the code. He came up with a sequence of commands that tricked the code (via manually setting variables) into behaving. It was a success and 14 went on to land safely and complete its mission. He was awarded many laurels for this feat, but declined a chance to meet President Nixon on anti-war grounds.
In the oh-so-cool department, he frequently "flew" landings in the various LM simulators scattered around the country, often in partnership with the astronauts that later walked on the moon.
Do you want to know who he slept with? How much dope he smoked? How about details of his vacations? I didn't, but it's there in all its boring irrelevance. There's nothing about his post-Apollo life other than a paragraph about doing some early work on the Shuttle's computers. I would have liked to know more, but the scope of the book really is limited to some early autobiography and those six years on the LM.
I enjoyed the book, but stay away from it if you aren't well-versed in software or aren't an Apollo junkie.
Don is currently a sculptor and photographer. His web site is here.
Feel free to email me with comments.
Back to Jack's blog index page.
If you'd like to post a comment without logging in, click in the "Name" box under "Or sign up with Disqus" and click on "I'd rather post as a guest."
Recent blog postings:
- GPS Will Fail - In April GPS will have its own Y2K problem. Unbelievable.
- LIDAR in Cars - Really? - Maybe there are better ideas.
- Why Did You Become an Engineer? - This is the best career ever.
- Software Process Improvement for Firmware - What goes on in an SPI audit?
- 50 Years of Ham Radio - 2019 marks 50 years of ham radio for me.
- Medical Device Lawsuits - They're on the rise, and firmware is part of the problem.
- A retrospective on 2018 - My marketing data for 2018, including web traffic and TEM information.
- Remembering Circuit Theory - Electronics is fun, and reviewing a textbook is pretty interesting.
- R vs D - Too many of us conflate research and development
- Engineer or Scientist? - Which are you? John Q. Public has a hard time telling the difference.
- A New, Low-Tech, Use for Computers - I never would have imagined this use for computers.
- NASA's Lost Software Engineering Lessons - Lessons learned, lessons lost.
- The Cost of Firmware - A Scary Story! - A hallowean story to terrify.
- A Review of First Man, the Movie - The book was great. The movie? Nope.
- A Review of The Overstory - One of the most remarkable novels I've read in a long time.
- What I Learned About Successful Consulting - Lessons learned about successful consulting.
- Low Power Mischief - Ultra-low power systems are trickier to design than most realize.
- Thoughts on Firmware Seminars - Better Firmware Faster resonates with a lot of people.
- On Evil - The Internet has brought the worst out in many.
- My Toothbrush has Modes - What! A lousy toothbrush has a UI?
- Review of SUNBURST and LUMINARY: An Apollo Memoir - A good book about the LM's code.
- Fun With Transmission Lines - Generating a step with no electronics.
- On N-Version Programming - Can we improve reliability through redundancy? Maybe not.
- On USB v. Bench Scopes - USB scopes are nice, but I'll stick with bench models.