TALES ABOUT THE LUNAR MODULE GUIDANCE COMPUTER
 I have read the article of Don Eyles, "Tales from the lunar module guidance computer", explaining how the guidance was made in the lunar module, and it is really the most hilarious thing I have ever read, a series of absurdities that I am going to explain in this article. |
 They say that they delay the arming of the engine, because they suspect there is a leak, and arming the engine prematurely might have explosive consequences when the engine is ignited. But that doesn't remove the problem of the leak: May be the engine will not explode when ignited, but it might explode later. |
 It's just backing off to better blow up. If they suspected a leak, why not just fix the leak? |
 They complain that the AGC behaved incorrectly because the engine was slower to start than expected (because of a pressurization problem) and a parameter was not well adjusted because they were not informed of it. |
 Hey, it's not their fault, mister, "nobody told them"! May be that the one who should have informed them will say that they should have guessed by themselves! |
 I like it: "The computer program was still small enough to fit into one single listing"...See the size of the listing, LOL! |
 The computer was working with the metric system, but the astronauts didn't like the metric system and were too lazy to make the effort to work with it; so the computer had the task of converting units into anglo-saxon units for them. |
 Of course, it had plenty of time to waste, it was doing plenty of restarts during the flight, especially at the most crucial moment, because it was lacking time to perform its operations! |
 I like it: The computer sees the radar in a wrong position, but its switches are in the right position; so the crew has to put the switches in the wrong position in order to clear the alarm! |
 Armstrong has to switch the autopilot rate switch from 5 deg/sec to 25 deg/sec...But isn't an autopilot supposed to adjust itself? And the radar data can only be incorporated into the guidance system if the astronauts allow it. That means that they can decide to land without it! |
 They also say that, if the radar data is incorporated into the navigation, it will not "adversely" affect it. What would be the use of the radar if it was adversely affecting the guidance? |
 The computer has a problem, issues an alarm and waits for an order before continuing. The engineers are panicked and don't know how to react. |
 Finally Houston takes the decision to give the "Go" to allow the computer to continue (the "Go" is given by a young hero). But it takes a half minute; meanwhile the astronauts are left in incertitude. |
 I like it: "In the official transcript of communications between spacecraft and ground during the powered descent, these are the only exclamation points" So the transcripter was able to read exclamation points in the oral words of Armstrong! Some transcripter! |
 They say that they have built an revolutionary real time system because they have given to it functionalities..which can be found in any real time system and are the base of real time processing. |
 Furthermore, the very minimum for a real time system is to have a stack, and the AGC didn't have a stack. And it had no real instruction to manage real time. How were the jobs scheduled with no instruction to schedule them? |
 What's hilarious is the table of jobs they give: the job SERVICER, which contains important tasks, like the guidance which is essential and shoud run regularly, is given the lowest priority. |
 On the other hand, human interface tasks, such as display and keyboard management, are given a higher priority than SERVICER. It's the only real time system I have even seen in which human interface tasks are given a higher priority than automatic critical tasks! |
 The AUTO mode of Apollo 11 was formerly corresponding to a MANUAL mode, whereas LGC was formerly corresponding to an AUTO mode!!! So, when the astronauts were connecting on AUTO, they could have a doubt if they were not in fact connecting on MANUAL! |
 This diagram is hilarious: AUTO and SLEW do exactly the same thing. And LGC , like AUTO and SLEW connects to a line reference of 28V and 800 Hz; but this reference is dephased from the other one, and this dephasing makes that the resolver generates angle pulses even when the radar is not connected, creating wrong data the AGC works with! |
 They talk about this problem which was "documented but never corrected"! It was better to let it continue to create trouble. |
This could have been avoided just by using the same 28V reference! They also say that phasing depends on the moment the LGC is powered up!! This is absolutely wrong, it can only depend on the way the electronic is adjusted, and not the moment the LCG is powered up. They make the AGC count the hardware angle pulses with software instructions!!! These pulses should be counted with an electronic counter read though an IO operation. |
 Here is an example of electronic counter which can count hardware pulses, and such circuits were existing in the time of Apollo. |
 And the count of pulses can be read with an I/O read operation, and the AGC had an instruction which could do it, so it had no excuse not to proceed that way. |
 Counting them with software instructions is a huge waste to time cycles, and uselessly steals time from the AGC...Especially when the AGC lacks time to perform its operations and has to do frequent restarts because of it. |
And the radar interface outputs a fixed frequency signal, which is not even modulated by the angle pulses, and which is transformed into another signal with a different fixed frequency. A complete nonsense! |
 George hurried to arrive at Houston just one hour before the lunar liftoff, to talk to MIT representatives about something stealing time from the CPU; he still would have had time to find a solution on the AGC's program...if it was not currently on the moon. But the MIT representatives still had time to make a prayer for the astronauts! |
 Something was "stealing" time from the AGC, but they never found out what it was, so they had to preserve a margin of time for the AGC...A margin they were eating by uselessly converting units, and counting hardware pulses with software instructions! |
 The simple fact of adding a display makes the duty-cycle margin fall from 13% to 10%, causing more often alarms and computer restarts! And the astronauts had more work clearing the alarms than actually guiding the ship! |
 Hilarious: Because SERVICER had the lowest priority, it was served after all the other processes; but because it was stealing memory from the other processes, the other processes could not run when SERVICER had drained out all memory resources...it could not use because the other processes, which had more priority than it, were not leaving it the necessary time to run! |
 It's the snake which bites its own tail! |
 The moment that the AGC was most disturbing the astronauts, with more frequent alarms, is precisely the moment that their attention for the guidance of the ship would have been most needed! It was obviously a computer which was needing attention! |
 The programmers notice "throttle oscillations", for which they imagine two different origins: 1) The IMU which would be "slung" and would perturb the reading of the accelerometers. 2) The throttle command would have a little delayed effect and would not immediately be taken into account by the engine. Both explanations are aberrant! |
 1) The IMU cannot be slung, because the navigation is "normally" very smooth (especially since there are no atmospheric perturbations on the moon), thanks to the very "reliable" guidance system, and could not cause the IMU to be slung that way; if it really was slung that way, it would mean that the lunar module has a very dangerous behavior, and has every chance to crash on the moon! 2) It doesn't matter if the throttle command has a little delayed effect on the engine (only fractions of seconds), the guidance system still remains smooth and can in no way produce throttle oscillations (In aviation too, the effect of the command is a little delayed, but it creates no oscillations). So both explanations are irrelevant, there can't be any oscillations (unless the computer screws up). |
 So a programmer applies a compensation of 0.2 sec because of the delay between the throttle command and the resulting thrust. His superior tells him it's not enough and that it should be 0.3 sec. But the programmer says that "it's like medicine, don't compensate more than necessary". |
 His superior knows that it isn't "like medicine", and thinks that the compensation is not sufficient to correct the oscillations, but lets his subordinate do, "to nurture his self-reliance", hoping he will eventually correct it. So a good understanding between the programmers is better than insuring the safety of the ship, isn't it? |
 Finally, Apollo will be saved, because the performance of the engine had been improved, and that the insufficient compensation was now enough and correctly countering the oscillations. If the correct compensation had been programmed, Apollo might have crashed, just because the software team had not been informed of the improvement of the engine. |
 So the combination of a tolerant superior and a faulty documentation saved Apollo! That's a real Hollywood scenario! |
 And the funniest thing is that no compensation should be applied! |
 What's the use of compensating the lag time of 0.3 or 0.2 seconds of the engine, when SERVICER was only running every 2 seconds (at best), and that SERVICER could randomly be cut by another job between the readings of the accelerometers and the making of the correction...especially when no compensation can be applied in fact for the readings of the accelerometers cannot be predicted. |
 So, we are here swimming in an ocean of absurdities! But the "compensation" offered a nice Hollywood story! |
 They also say that they fixed the IMU bob by removing the velocity changes caused by the IMU motion. That's a total nonsense. |
 There can't be any IMU bob, like I explained, because the navigation is (normally) smooth, and there's also no way that the velocity changes caused by the IMU motion may be calculated! Furthermore, if the IMU was really causing a problem, it was way simpler to fasten it correctly than to make velocity corrections based on its supposed motion (which are not even possible to do). |
 They say that they had added a possibility that the crew could select the throttle level desired by guidance!!! But, if they select it, it's no more desired by guidance! |
 They also say that they had planned to add a possibility that the astronaut was taking the control of the throttle while the AGC was keeping the control of the attitude! That's a total aberration, for the couple |
 It's like the driver of a car was saying to his passenger: "I now close my eyes, you check the road, but I keep the steering wheel"! |
 Because SERVICER was sometimes unable to perform its operation in the given period of 2 seconds, thus causing a crash of the computer and a restart, they now imagine to give it a flexible period it can measure by itself, so that it will always have the time to do the job it has to do. |
 It may avoid crashes, but it's no more real time, because, in real time, a critical task always has to perform its processing in a determined given time it must not go over! There's no such thing as "flexible" real time. |
 They have a spurious signal on the abort switch which causes an unwanted abort, which could spoil the guidance of Apollo. So, you might have thought that they would just have electronically filtered this spurious signal in order to prevent it from generating an abort? |
 No, not at all, they provided an "Apollo" solution, by fooling the abort procedure in making it believe an abort was already in progress! |
Sometimes the system was jamming because SERVICER had drained out all the VAC areas other higher priority jobs were needing, (and that SERVICER could not use because it was prevented from working by the other higher priority jobs), but they were planning to waste still more VAC areas by installing snippets of code into them; that way, alarms and restarts would occur still more often! |
 So, this tale, while most people think that it is very serious, when seen from the point of view of an engineer, is in fact very funny, and has no credibility whatsoever. |
 There is no way that this tale can be serious, and it makes no doubt for me that this tale contains a hidden message from the engineers who worked on the AGC. |
