THE WEIRD GUIDANCE PROGRAM OF THE LUNAR MODULE
 This part deals about a document on Apollo from the MIT, "APOLLO GUIDANCE, NAVIGATION AND CONTROL". Link to this document I have found this document in the Virtual AGC Home Page of NASA. It shows that the guidance program of the lunar module contains many aberrations, and these aberrations are intentional. |
 The electronics schemas which are shown in this document appear senseless to me. Their anomalies are not easy to explain, but I have selected some of them for which I think that the explanation is understandable. |
 This the schema of the IMU turn on mode. There are some strange things on this schema. |
 The coil extremities I have circled are connected to nothing. And the COS input of the 1X block is connected to nothing. |
 This is the Antenna Microwave Electronics Functional block diagram. |
 The block I have framed in green is a phase modulator. A phase modulator modulates in phase a high fixed frequency signal with a variable signal. The variable signal comes from the left of the block. There are three signals coming on the left of the DRIVER block (framed in orange); they all have a fixed specified frequency. The DRIVER block combines these three signals to make a common signal which mixes the three fixed frequencies, and this signal should come into the PHASE MODULATOR block to be modulated in phase by the incoming variable signal. But, instead of an unique signal coming out of the DRIVER block, there are three signals which come out of it, and which come into the PHASE MODULATOR block. |
 This is what we should have seen on this corrected schema: An unique signal coming out of the DRIVER block, combining the three fixed frequency signals, and which is to be phase modulated by the incoming variable signal on the left. |
 This is the Self Test Assembly functional block diagram. |
 There are three fixed frequency signals, I have circled in blue, which come into the block "PHASE SHIFTED", I have framed in orange. So, the signal, I have outlined in red, which comes out of this block is also necessarily a fixed frequency signal. This signal comes into a block "PHASE MOD", which is a phase modulator which modulates in phase the high frequency signal produced by the block "XTAL OSC" (which is a crystal oscillator), I have framed in green, with the incoming signal on the right, the signal coming from the block "PHASE SHIFTED", which, as pointed out, has a fixed frequency. But it makes no sense to modulate the high frequency signal with a fixed frequency signal; the high frequency signal is always modulated with a variable signal! |
 This is the block diagram of the central processor. |
 It's the memory buffer register which has the parity bit, which should give it to the parity logic so that it can check it. So the arrow of the parity bit should go from the memory buffer register to the parity logic, and be oriented as the arrow I have represented in red. And this is the parity logic block which checks the parity and gives the result to the memory buffer register, so the parity check should be oriented from the parity logic to the memory buffer register, and be oriented as the arrow I have represented in orange. So we here have on the schema two arrows oriented in the wrong direction. |
 This is the Caution and Warning Indicator logic diagram. |
 The "NO ATTITUDE" indicator is connected to "Coarse alignment". What is the relationship between this indicator and "Coarse alignment" which has nothing to do with the attitude of the lunar module? |
 Now we are going to see the functional diagrams of the programs of the AGC. |
 There are two ways of making the rendez vous; normally the active vehicle is the one which manages the rendez vous; it flies under the passive vehicle (because it much fly faster than the passive vehicle in order to be able to catch it), overpasses it, arrives on the orbit of the passive vehicle a little ahead of the latter, and docks to it. Normally it is the lunar module which is the active vehicle, for it starts from the lunar surface while the command module orbits the moon. |
 But, in some cases, it can be the command module which is the active vehicle; in that case, the lunar module goes on an orbit above the one of the command module, and it is the command module which is going to manage the rendez vous, and it does it the same way as the lunar module does it when it is the active vehicle. |
 The document says that the lunar module updates its own state vector when it is the active vehicle, and manages the rendez vous. But, when it is the command module which is the active vehicle, the document says that the program of the lunar module updates the state vector of the command module instead... |
...and it sends the updated state vector of the command module to the command module via the voice communication link so that the command module can use it to manage the rendez vous. But it is absurd for two reasons. |
The first absurdity is that it is up to the command module to update its own state vector when it is the active vehicle, and manages the rendez vous, for it also has a guidance system and does not need the lunar module to do it instead of itself. |
 The second absurdity is that the lunar module should not send the updated state vector to the command module via the voice communication link (I have colored in red on this schema of GRUMMAN), but on the data communication link (that I have colored in green on the schema) which is fit for that purpose unlike the voice communication link. |
 In this test of the program 20, the astronaut is asked if he wants to wait for the range to the CSM is less than 400 nautical miles; a nautical mile makes 1.852 kilometer; so 400 nautical miles make 740 kilometers. But the command module orbits at 110 kilometers over the lunar surface, and the command module and the lunar module orbit the moon in the same direction. Sure the command module is not exactly at the vertical of the command module, but even so, the distance between the lunar module and the lunar module could not be that much; for instance, if the lunar module was seeing the command module under an angle of 45°, which is more than the reality, the distance between the two would only be 156 kilometers, much less than the distance corresponding to 400 nautical miles. So, this test is senseless, the distance between the two spaceships will always be consistently less than 400 nautical miles. |
 The part of the flow diagram I have framed is executed if the bit TRACK FLAG is reset; but this bit is set at the beginning of the program and reset nowhere in the program; so it should logically never be executed, and thence it appears as useless. |
 And the loop I have framed will be executed, for it is in the branch which is executed when TRACK FLAG is reset. It waits as long as TRACK FLAG is reset. But this loop is useless as there is nothing to set TRACK FLAG in this loop. |
 The verb 73 allows to provide an octal increment for the LGC clock. But octal increment means nothing, for the increment is made bit by bit. |
 The verb 70 provides an octal increment for both the LGC clock and the TEPHEM. But how can the TEPHEM be incremented without the LGC clock also being incremented? |
 A LGC update allows to provide load capability for a block of sequential erasable locations. But it is possible to read and write any location of the erasable memory at any moment, it does not need to be "enabled". |
 In the program 25, the flags P25 and TRACK are initially set. So the "YES" branches will be executed in the test of these two flags. |
 And then the astronaut is given the choise to terminate or not. If he chooses not to terminate, the whole loop is executed again, with the flags P25 and TRACK still set. It means that the program has no way to automatically terminate; the astronaut can block it indefinitely if he wants...or omits to answer the question. Isn't it a little dangerous? |
 In the test which is framed in red (in program 27), a variable "INDEX" is tested, and the program is exited only if this variable is outside a given range. The problem is that this variable is defined nowhere, except in a branch which is executed only when the program is exited, but not before the test of INDEX. So, at the moment that the variable "INDEX" is tested, it has to definite value, it can have any random value, which means that this test is meaningless. |
 In sheet 2 of program 27, there is a storage address which is calculated for each loaded data. But, if there is data which is already stored somewhere in memory, why store it somewhere else in memory and not directly use it where it is already stored? And, if the stored addresses are consecutive, the calculation of each address is not very complicated. |
 The astronaut has the possibility of terminating the update before all the data have been transferred. But why would he do that? And, if he terminates before all the data have been transferred, he does not have the possibility of correcting any of them. |
 The astronaut can also terminate the update after all the data have been transferred, but, in this branch, he has the possibility of updating any of the transferred data, unlike the case that he would terminate the update before all the data have been transferred. The conclusion is that the astronaut should not be given the option of terminating the update before all the data have been transferred. The first terminate option should not exist. |
 In this part of flow diagram (in P30), the flag UPDATE is reset before a treatment, and is set immediately after; but why do that since this treatment does not use the flag UPDATE? This is totally useless. |
 This part of the flow diagram of the program 32 is rather tricky. There is a treatment which is called from the sheet 2 (through the point 2 circled in red); when sheet 2 calls this part of sheet 1, the flag TERMINATE is already set. After the treatment, which resets the flag UPDATE, in case that there is no alarm (which is the normal case), the left branch is executed, in which the flag UPDATE is not set because the flag TERMINATE is currently set, and the sheet 2 is called again; this time the sheet 2 makes an exit because the flag TERMINATE is set...with the flag UPDATE currently reset! |
 The document says: "It (The RCS program) also calculates and displays the gimbal angles which would result from the present IMU orientation if the vehicle is maneuvered to the preferred LM attitude for thrusting" I am going to explain whay it makes no sense. The IMU angles are not directly the attitude angles of the LM. |
 In order to be able to use the IMU, it first must be initialized, in order to initialize the measured angles. As we are in a three dimensional system, the initialization is made by pointing a reticle toward three different stars. |
 In case that the spaceship is near a planet (in this case the moon), the third star can be replaced with the local gravity which gives the direction of the planet's center. |
After the measured angles have been initialized, they are constantly updated by the IMU which sends to the guidance not angles, but angle variations which allow the guidance to update the measured angles. |
 When the RCS program wants to to give the LM a definite attitude, it commands the thrusters till the measured angles (updated from the IMU data) match the the desired angles. |
 So it's not the IMU angles which should be displayed on the AGC, which are irrelevant (and that besides the AGC doesn't even have the information of), but the measured angles updated from the angle variations sent by the IMU. |
 In the program 70, a variable TG is tested (it is even also tested in some other places), but it is never defined anywhere in any program. Of course, it could be explicitly specified by the astronaut, but, in this case, there should be a noun allowing the astronaut to input it. |
 The noun 68 contains a parameter which corresponds to this variable TG. (there also is the noun 61, but this noun is never called). |
 In the program, this noun is only used with the verb 06. |
 But the verb 06 is not a verb for inputting data, it is a verb for displaying information. It means that the variable TG is never inputted by the astronaut either. |
So we here have a variable TG which is defined nowhere in the whole guidance program, and not specified by the astronaut either, and which thence contains an unknown random value, and which is yet tested like it was containing something relevant. |
 In this test (of the program 70), H DOT means vertical speed (as defined by NASA itself). So this test says that, if the vertical speed is greater than a certain value (40 feet per second), then the rotation flag must be reset. But what relationship is there between a vertical speed and a rotation? |
 And now, the cherry on the cake, may be the tastiest trick of the guidance program. The test shown can execute two different possibilities, one which sets a data MGA to -00002, and another one which sets this data to -00001. This kind of test is repeated in several places of the guidance program, like the engineers wanted to bring our attention on it...and you are going to understand why. |
 In fact MGA is a gimbal angle I have circled on this schema. |
This angle is specified in hundredths of degree, which means that a branch of the test sets it to -0.02°, and the other one sets it to -0.01°. There is 0.01° difference between these two values. It means that the guidance program should be able to set this angle with a precision of 0.01° at least. |
 The IMU circuitry receives analog commands. The guidance program uses a digital representation, and in order to send an angle variation to the IMU, it uses a digital to analog converter. |
 But the least significant bit of the digital to analog converter corresponds to an angle variation of 0.044°. It means that the guidance program can set the IMU angles, and that includes the MGA angle, with a precision which is not better than 0.044°. |
So, while the guidance program should be able to set the MGA angle with a precision of at least 0.01° to correctly execute these two branches of the test, it can in fact set it with a precision which is not even 0.04°! |
 Do you see the irony? |
 So, the whole document is a heap of nonsense, and this nonsense can only be intentional. |
 So, all these aberrations are as many hints the engineers are giving us to make us understand that the AGC never helped a lunar module to land on the moon. |
 What's funny is that, in all the programs, the astronaut is requested to provide information: - He is asked if he wants to exit the program or not. - He is asked if he wants to exit a loop of not. - He is asked if he wants to update data. |
 So, the astronaut in charge of the DSKY would have been very busy constantly interacting with the programs of the AGC in the powered descent. |
 But, if Buzz Aldrin was questioned on all the interactions he logically had to do with the AGC during the powered descent, he would say: "But what are you talking about? I was just watching the computer do its job!". |
 Definitively, Apollo is just a fairy tale for adults who have forgotten to grow up. |
