Hacker News Reader

Comment by dave_blob | Hacker News Reader

The real fun with the AGC on landing happened on Apollo 14, with a flipped bit in the abort landing flag. Percussive maintenance temporarily flipped the bit back, giving enough time for ground control to develop a hack. Didn't they just ignore the warnings on Apollo 11? And I think it was non synced timing references rather than strictly resource availability that got them on 11

View on HN

The docking (like find your way back to the mothership radar) was still turned on, so the CPU was receiving the data and having to process it.

The CPU was throwing an I'm overloaded signal, but dealing with it, as the process priority put docking radar as less priority than the landing sequence.

So the CPU was complaining but still doing it's job.

All this is from memory :P

Yes, just looked it up.

I was (partially) wrong about the un-synced frequency though. The synchro's for the docking radar ran from a different power circuit than the AGC, and whilst they were frequency locked they weren't in phase; resulting in timings getting thrown off and the priority issues.

Edit: Superb deep dive on AGC in Ars from last week https://arstechnica.com/science/2020/01/a-deep-dive-into-the...

The reason for warnings on 11 was that the landing was done in what was essentially an unsupported configuration. Still the “kernel” behaved as designed, didn't run low priority task (that was not supposed to be running in the first place) and raised an warning about doing so.

Actually radar counter wasn't handled by any software task, it was hardware interrupt hardwired to steal CPU ALU cycles to increment/decrement memory location. Abnormally high steal time caused main navigation job to run too long, and it was getting scheduled again before previous instance finished. That led to memory exhaustion and BAILOUT software restart.

source: https://www.doneyles.com/LM/Tales.html

Reply on news.ycombinator.com