Oh look, it's the best thing I've ever watched on youtube.
Okay, that might be slight hyperbole, but it's solidly in my top ten. One of those where the video documentation has no flourish, and as such doesn't get in the way of how cool the actual project is.
Excellent series. If anyone knows of anything even remotely similar, please send it my way.
A technical pleasure and also very good glimpse into the Apollo team - working together, to land on the moon. It is a fun easy read, written by the fellow in charge of programming computer on the lunar lander. It is also a great snapshot of that time in history, the excitement of Apollo, and with the frustration of the Vietnam war going on, some protests, etc.
Just a hint - the main programmer, was an English major, and his use of the right words, were a key factor in the success of of creating an efficient and effective computer language.
Interesting: he says that the famous 1202 error may sometimes crash the spacecraft and sometimes land successful in some other cases. And also that it depends on many factors. So, the sane thing to do at that moment, AIUI, was to abort the landing.
The Apollo 11 landing was not a tragedy be sheer luck. IIRC Armstrong asked ground control about 1202 and they tell him to ignore it. Ground controllers, probably unknowingly, bet Armstrong and Aldrin lives.
The video strongly implies that the conditions for 1201/1202 alarms might, or might not, lead to a crash. The take in the video is that they got lucky both in sim and reality.
Alarms indicated system restart, but because landing program was designed to automatically restart with data from last checkpoint, checklists deemed it was safe to continue. The trouble though was what was causing the restarts: due to unexpected CPU time stealing from hardware, new SERVICER jobs were scheduled before previous one finished! And previous job wasn't removed from list immediately (that only happened when everything restarted with alarm), which mean that with load fluctuations previously interrupted stale jobs could be continued. In effect there were multiple active instances of routine that was never designed to be reentrant, potentially stomping over global variables and submitting stale commands. The reason that effects of this were relatively benign was that the last thing SERVICER did was updating display, and that's where unintended behavior appeared. In case hardware was stealing a bit more time and jobs would be interrupted near throttle command submission, effects would have been worse.
>It is now known that the stacking up of Servicer jobs which precedes a 1201 or 1202 alarm in the event of TLOSS can cause completely wrong throttle and attitude commands, and in one special case, random branching. This happens because the Servicer job can clobber its own erasables. Luckily this did not happen to Apollo 11, which encountered TLOSS estimated at up to 15%.
EDIT: I watched the talk and I'm not sure whether he implies there's additional CDU problem, or just discussion about exact amount of CDU-caused TLOSS, so I hope he will explain that on the channel.
Here's another lecture I really enjoyed walking through the operation of the guidance computer and the events that lead to the 1202 error, which the speaker sums up as an "out of memory" error resulting in an automatic reboot. He says the cause was a hardware bug taxing the machine with empty status updates, combined with Buzz typing "verb 16 noun 68" to have the display auto-update some stats - he was crashing the machine but didn't put together why it was happening because it never crashed the machine in simulation.
> Interesting: he says that the famous 1202 error may sometimes crash the spacecraft and sometimes land successful in some other cases .. The Apollo 11 landing was not a tragedy be sheer luck.
I recall reading somewhere that the 1202 error was caused by someone switching on the rendezvous radar, in the event of a quick take-off. This caused the computer to continuously seek for a radar lock on the orbiting craft that was not going to occur. Nothing like this happened in the simulator.
23 comments
[ 6.1 ms ] story [ 66.0 ms ] threadThis video of building a custom Apollo electroluminescent glass panel DSKY display is also fantastic! https://www.youtube.com/watch?v=Z2o_Sp2-aBo
Okay, that might be slight hyperbole, but it's solidly in my top ten. One of those where the video documentation has no flourish, and as such doesn't get in the way of how cool the actual project is.
Excellent series. If anyone knows of anything even remotely similar, please send it my way.
A technical pleasure and also very good glimpse into the Apollo team - working together, to land on the moon. It is a fun easy read, written by the fellow in charge of programming computer on the lunar lander. It is also a great snapshot of that time in history, the excitement of Apollo, and with the frustration of the Vietnam war going on, some protests, etc. Just a hint - the main programmer, was an English major, and his use of the right words, were a key factor in the success of of creating an efficient and effective computer language.
The Apollo 11 landing was not a tragedy be sheer luck. IIRC Armstrong asked ground control about 1202 and they tell him to ignore it. Ground controllers, probably unknowingly, bet Armstrong and Aldrin lives.
Cause of alarms is described there: https://www.doneyles.com/LM/Tales.html
Alarms indicated system restart, but because landing program was designed to automatically restart with data from last checkpoint, checklists deemed it was safe to continue. The trouble though was what was causing the restarts: due to unexpected CPU time stealing from hardware, new SERVICER jobs were scheduled before previous one finished! And previous job wasn't removed from list immediately (that only happened when everything restarted with alarm), which mean that with load fluctuations previously interrupted stale jobs could be continued. In effect there were multiple active instances of routine that was never designed to be reentrant, potentially stomping over global variables and submitting stale commands. The reason that effects of this were relatively benign was that the last thing SERVICER did was updating display, and that's where unintended behavior appeared. In case hardware was stealing a bit more time and jobs would be interrupted near throttle command submission, effects would have been worse.
See also https://www.ibiblio.org/apollo/Documents/LUMINARY-memo-138.p...
>It is now known that the stacking up of Servicer jobs which precedes a 1201 or 1202 alarm in the event of TLOSS can cause completely wrong throttle and attitude commands, and in one special case, random branching. This happens because the Servicer job can clobber its own erasables. Luckily this did not happen to Apollo 11, which encountered TLOSS estimated at up to 15%.
EDIT: I watched the talk and I'm not sure whether he implies there's additional CDU problem, or just discussion about exact amount of CDU-caused TLOSS, so I hope he will explain that on the channel.
Straight from NASA: https://history.nasa.gov/alsj/a11/a11.1201-pa.html
https://youtu.be/B1J2RMorJXM
I recall reading somewhere that the 1202 error was caused by someone switching on the rendezvous radar, in the event of a quick take-off. This caused the computer to continuously seek for a radar lock on the orbiting craft that was not going to occur. Nothing like this happened in the simulator.