 This video deals with a very special progress report of Apollo written by a NASA engineer. Link to the NASA document |
 They say: "A tiny pin dropped out of a backup counter in the CM telescope during the Apollo 9 mission and made the motion sticky. The navigator freed up the stickiness with a hand tool and had no further problem. Since the counter information is displayed on the DSKY, the loss of it did not interfer with mission objectives" How could a tiny dropped pin make the motion of the telescope sticky? The motion of the telescope should be protected so that a such event could not result in a such stickiness.  But creating chances of mishap makes the taste of adventure. |
 They say: "Based on these data, the flight computer is loaded with compensation values for 15 coefficients describing the non-perfect behavior of the IMU. These coefficients are quite stable and repeatable in a good IMU". There is no way that problems of the IMU can be predicted and automatically corrected. But the Apollo engineers like to invent fantasy corrections provided that they sound impressive. |
 They say: "The long coasting period after the boost into orbit with no apparent output from the accelerometer was disconcerting...so much that a small translation maneuver along the Y axis was executed with the reaction control jets, just to see if the accelerometer was alive, even though the failure detection logic for the accelerometers had indicated the unit was normal." Once that the spacecraft is in orbit, its speed is constant, and therefore it is no wonder that the accelerometer shows no output, and there is no ground to worry that its output is null, especially if the failure detection logic shows that the accelerometer works normally. If they fire the reaction control jets, they create an acceleration that the accelerometer then shows. Worrying about something normal, so to evacuate the stress and later not worry about less normal things! |
They say: "In the second case, an accelerometer performance change, which must have occurred about the time of liftoff of Apollo 8, left the spacecraft indication of orbital perigee lower than as indicated from the ground tracking and the Saturn guidance". This makes no sense, for the ground tracking and the saturn guidance cannot locate the CM with enough precision to detect that the CM would make an error in the computation of the perigee because of a small error on an accelerometer of the CM. Little matters what you compare as long as you compare something, this is the rhetoric of Apollo. |
 They say: "The flight of Apollo 8 to the moon gave an excellent opportunity to watch this zero input accelerometer performance because the IMU was left running the whole 147 hours and, unlike earth orbital flights, the spacecraft stayed in sight of the telemetry receiver stations. The complete set of data obtained are shown in figure 3". The receiving stations on earth can receive the readings of the accelerometers via telemetry, but there is no way that they can deduce their bias from them, for they have nothing to compare them with; the receiving stations have no other way to make a precise measure of the spacecraft's accelerations; the radar allows to make an estimation of the spacecraft's speed with the doppler's effect, of which the derivation could allow to obtain an estimation of the acceleration, but this measure is very far from having the precision of the spacecraft's accelerometers. But these graphs sound impressive, isn't it what is required of them? |
 They say: "The IMU gyro drift term under near zero acceleration environment can also be measured during flight by measuring the angle change which the IMU realignment process requires by the time since the last alignment. These results are displayed in Figure 4 for the Apollo 8 flight" The only way to realign the IMU is by the astronaut making telescope sightings of stars. The IMU cannot automatically realign itself. And the alignment by telescope sighting is a painful process which is only very occasionally made, for the gyro drift is quite slow, and the readings of the gyro remain reliable for quite a long time. The gyro drift increases with time in a practically linear way. On this diagram, the fist graph shows the time between two realignments of the IMU, andf the three other graphs the corresponding gyro drifts of the three space angles.  On the part I have colored in blue, the period of realignment is almost constant, and so should be the three corresponding gyro drifts; instead of that, you can see that they show consistent variations. And, on the part I have colored in green, the period of realignment is shaped as saw teeth; the gyro drifts, which are close to linear functions of the period of realignment, should also be shaped as saw teeth; instead of that, they are close to constant! In short, the gyro drifts are inconsistent with the period of realignment. But, as long as the graphs sound impressive, isn't it what counts? |
They say: "By proper choice of IMU alignment, every phase of the Apollo mission can avoid gimbal lock attitudes. The forbidden zones are small and conceptually simple . Clear signals are given as these attitudes are approached. Moreover, if the IMU attitude is lost due to gimbal lock or any other cause, the IMU is not damaged, a clear warning signal is given, and the procedures for emergency and normal realignment are straightforward".  If gimbals should lock, they could do it at any attitude, not a given one. So, it is not possible to determine specific zones in which the gimbals would more tend to lock than other ones. If there really were specific attitudes at which the gimbals are susceptible to lock, they would not be very useful, for they are supposed to measure angles at any attitude. And, if there is a problem with a gyroscope for locked gimbals, it would not be possible to know if it gives no output because it is locked, or because there currently is no variation of the angle it measures, as there is no other way to acquire angles. Making up fancy gimbal lock zones was so much fun for the Apollo engineers. |
 They say: "Although the computer can take over the task of watching for gimbal lock and avoiding it by appropriate schematic maneuvers, this feature has not been authorized for the computer fixed memory program". This is ridiculous, the computer reading the gyros, and, when they come to zones of potential gimbal locks, acting on the RCS to get away from these zones! Totally delirious! And, if it was really making sense to make this watch, why would it not have been implemented in the fixed memory program if it could avoid a gimbal lock which would be nefarious to the navigation? Making the computer do useless work is so much fun after all! |
They say: "An experiment performed in earth orbit on Apollo 8 used the IMU and the erasable memory in the computer to take over attitude control in a wide deadband automatic control. This was extremely efficient in the use of reaction control fuel. But, of significance here, this crew felt that they would be perfectly willing to operate in this mode while all three slept; the control system would keep attitudes well away from gimbal lock." So, while the three astronauts were sleeping, the control system would fire the thrusters of the RCS each time the spacecraft was getting close to imaginary zones of potential gimbal lock, thus uselessly wasting reaction control fuel of which it certainly was making an "efficient" use!  LOL! |
 They say: "The lunar landing will be made with the present 3-gimbal IMU. The question as to whether the complexity and performance compromise of the all-attitude 4-gimbal configuration was worth avoiding under the prevailing circumstances at the time of design commitment will not be answered." The 3-Gimbal IMU already measures three angles, and, as much as I know, the space is 3D, even close to the moon. So the 3-Gimbal IMU is already an all-attitude IMU. So, what may be a 4-Gimbal IMU? a more-than-all-attitude IMU? The Apollo engineers love to work with the 4th dimension! |
 They say: "For added confidence, after marking on two stars, the computer program provides a check of the star angle difference displayed to the operator. This is the difference of the measured angle calculated from the computer's catalog of star coordinates for the identified stars." Star coordinates don't allow to know the orientation of these stars relatively to the spacecraft. If if was that simple, the astronaut would not have to make star alignment, these coordinates would allow to directly realign the IMU. The Apollo engineers love to make fantasy check, they think that it is still better to make fantasy check than no check at all! |
 they say: "Not forecast, however, was the confusion caused by the debris cloud from the SIVB after separation. Confusion of particle and stars was so bad that is was not even possible to calibrate the sextant by superimposing star images on top of themselves while near this debris cloud." The debris get away very fast from the CM; and after, they become practically invisible. The sextant calibration is not made so fast that it would not give time to the debris to get away. And furthermore, the astronauts are not going to make a calibration just at the moment of the separation, it is obvious that they are going to wait a little. It is impossible to confuse a star with a debris, because the stars are way more luminous. The Apollo engineers love as much to exaggerate the non existent risk as they like to underestimate the real one. |
 They say: "CM IMU alignment was exercised using the coordinates of Jupiter as a non-catalog star inserted into the computer's memory. Automatic optics pointing was called and Jupiter appeared in view with a fine display of her moons". Like said before, coodinates of Jupiter (in what system???) don't allow to know the orientation of Jupiter relatively to the spacecraft. Furthermore Jupiter is too far away to appear in view "with a fine display of her moons".  Jupiter is sure very useful to the navigation! |
 They say: "A sun filter is provided to make it possible to use the sun as an alignment target and was exercised the first time on Apollo 9. The filter worked well functionally -- even sun spots could be counted -- but the actual alignment was not performed". A sun filter would decrease so much the luminosity to counter the intense luminosity of the sun that it would make the crosshair disappear. Furthermore, for the precision of alignment, small targets are privileged, and the sun is relatively too big to be used for the alignment. And sun spots are so many that it would be illusory to count them. Only Apollo engineers could have a so weird idea as to use the sun to make the alignment. |
 They say: "Using the P20 rendezvous program, the computer pointed the sextant at the LM and the navigator picked it up in the eyepiece 2700 nautical miles away and was able to keep track of it until it was blocked from view". At 2700 nautical miles away the navigator could see the LM? A nautical mile represents a minute of arc of latitude; a minute is a 60th of degree; the circumference of the earth corresponds to 360°, and 360*60=21600 minutes, so the distance corresponding to a nautical mile is equal to the circumference of the earth divided by 21600; if you make the computation, you can see that this corresponds to a distance of 1852 meters; so 2700 nautical miles correspond to a distance of 5000 kilometers! The CM 's navigator could see the LM at a distance of 5000 km! But, what's really weird is that the diameter of the moon is 3474 kilometers. So, how could the LM be at a distance of 5000 kilometers? Unless the nautical mile is here to be considered as a minute of arc of the moon and not the earth. Even so, it still would make a distance of 1362 kilometers. No way that the CM's navigator could see the LM at such a distance, it would be way too small, and, even if he could, it would anyway be blocked by the lunar horizon. And, we are in a rendez-vous maneuver, which means that the LM gets closer and closer to the CM; so, once that the CM's navigator has the LM in view, he should keep it in view till the docking as there is nothing to block its view in the lunar void, and the LM arrives frontally relatively to the CM! If the navigator lost the LM from view after he could see it at such a distance, it probably means he had visions because he drank a little too much booze! |
 They say: "A 16mm movie camera was adapted to the sextant and carried on Apollo 8. Motion picture film of the lunar surface were obtained from orbit in this manner". Look at the sextant on this image, and explain me how it would have been possible to adapt a 16mm movie camera on it! But the Apollo engineers are capable of miracles, aren't they? |
 They say about the AGC: "Its necessary features include the ability to handle a number of different computational problems simultaneously in real time, interleaved in a single central processor on a priority basis".  Oh, yes, the AGC was so performant that the tasks had to test themselves if a more prioritary task had been scheduled!  A true revolution in task management! |
 They say: "The change control activity alone has seen over 750 program change requests from the various government teams and contractors processes through the program change board at MSC, Houston". wow, 750 program changes! Did they weave the memory again at each program change? Weaving the core rope memory is so much fun! |
 They say: "Considerable noise arriving from the telemetry receiver appeared at the up telemetry channel to the computer. The error checks and alarm in the decoding in the computer was able to reject the noise when the signals failed the logical test and bad data into the erasable memory was avoided". The error checks and alarm could only detect bad data, but not correct it. The bad data which has not been written in the erasable memory cannot be replaced with good data; no data corresponding to the bad data can be written in the erasable memory. Rejecting the noise would mean that the error checking is able of turning the bad data into good data, which it is not able of. But what do we know the magical error checking of the AGC is able of! |
 They say: "For many situations, the computer program associated with the keyboard is able to detect illogical inputs to the DSKY due to mispunched keys. The DSKY will signal "operator error" so that the astronaut can try again". The computer can test that values typed by the astronaut remain in acceptable bounds, but, if they are, the computer cannot check that what the astronaut typed is actually what he meant to type. Unless the computer is equipped with a magical crystal ball. |
 They say: "Other error detection has been designed and experienced in flight which causes the computer to restart automatically. Restart causes the program to go back a few steps to a point where the computation state was put into memory and then start fresh from that point".  In the program, at regular points, the data was saved; these points where the data was saved were called "waypoints" ; restarting was done by going back to the closest waypoint, restoring the data which had been saved at this waypoint, and restarting from this point with the data that the computer had at this point. But, if the computer restarts from this point with the data it had at this moment and executes the same program, once that it reaches the point it got blocked, it will have the same data as it had when it got blocked. So, that means it will make useless work it already did, and lose time making this useless work. Furthermore, the fact of having to save data at the waypoints eats power from the processor, a power it is already lacking of. The computer gets stuck because of the waiting SERVICER tasks (periodical guidance task) having drained all the available resources. So, it would be simpler to just drop all the waiting SERVICER tasks when the computer gets blocked, since they will never be serviced, and free their resources so that they can be made available again for the other tasks. But, why make simple when you can make more complicated! |
 They say: "More serious internal logical problems of procedural errors have raised alarms requiring the astronaut manually to recycle back to the start of the program in progress. In few cases experienced, the crew have been able to recover without help". If the computer is able of raising an alarm requiring the operator to recycle the program back, it should also be able to do it itself. The AGC probably requires the intervention of the astronaut because it is a baby which needs to be taken by the hand! |
 They say: "In such situations, the ground has examined the state of the memory to verify that memory corrections do not need to be telemetered up." In order to examine the state of the memory, the ground should have access to the memory of the AGC. But, to have access to this memory, the contents of the memory should first be telemetered down to the ground, and given the size of the memory, it would make quite a lot to telemeter down. What happens if an astronaut has restarted the program, and the program uses a data memory before the ground has telemetered up a correction for this data? Probably that the ground is extremely fast in examining the memory, finding the memory to modify, and telemetering up the correction before the restarted program uses it. And the time delay? Let's forget about the time delay, we are not going to get embarrassed with it, are we? |
 They say: "Computer program changes are not made easily and can be unsafe without time-consuming retesting." "But, in many cases, changing the program to accomodate hardware problems has nevertheless saved considerable time, effort, and expense". So they say that making program change is both time consuming and also saves time. Isn't it contradictory? But the Apollo engineers are not afraid of contradictions, are they? |
 They say: "The attitude signals come from the IMU in quanta steps of about 1.01 degree, and, at low rates, no new information is available for rate indication until the next angle increment occurs. The system gets around this problem by providing in the computer a model of the spacecraft response to applied torques" But, if the IMU does not send measure steps, that means that the angle is not changing and it is not an anomaly. So, there is nothing to get around a problem which does not exist. It makes no sense to build a model of the spacecraft response to be substituted to the actual response of the spacecraft as measured by the IMU. But the Apollo engineers are probably fond of models, and they need to build one even when it is useless. |
 They say: "With this knowledge of spacecraft mass, predetermined polynomials can be evaluated to give good estimates of spacecraft moments of inertia which directly allow an estimate of the angular acceleration produced by the controlled torques". Even if it was possible that they could actuate the mass with the knowledge of the burnt fuel, the knowledge of this mass in no way allows to estimate an angular acceleration produced by controlled torques. The Apollo engineers love to make estimations, even when they are irrelevant! |
They say: "Each iteration cycle of the autopilot examines the existing angle error and angle rate error. If either of these are outside chosen deadbands, the computer schedules and executes open loop the time history of two reaction jet firings which should bring both angle and rate errors to zero". The autopilot cannot examine an existing angle error and angle rate error, for there is no way it can estimate it. So, it makes no sense that it would fire reaction jets to correct imaginary errors...especially if it could not bring back both errors to zero! Unless the Apollo engineers love to play with the reaction jets! |
 They say: "The crew were desirous of having the control system in free-fall orbital flight respond to orbital rate calculated within the computer so that the spacecraft would hold attitude with respect to the local vertical without their attention. This feature has been proposed earlier as a program in fixed memory but had not been incorporated." If they are falling in free-fall, there is no need of holding the spacecraft's attitude with respect to the local vertical, for the spacecraft naturally holds this attitude. Moreover, it is completely disavised to make a landing on the moon in free-fall, it would be the worst way of landing, a guarantee to crash on the lunar ground. And, if this control had really be useful and desired, why wouldn't it have been implemented in the fixed memory? It's probably because I don't understand the very special logic of the Apollo engineers! |
 They say: "A week before the scheduled launch, a simple procedure to load a program and data into erasable memory by means of a few dozen DSKY keystrokes was transmitted to the astronauts. This provided the crew with the desired feature which operated in orbit as advertised". So, the ground is able of telemetering down the memory, telemetering up memory modifications, as we have seen earlier, but it is not able of telemetering up a small program into memory and need the astronauts to do it? Furthermore, if entering the program is done manually by the astronauts, they could easily make a mistake which would make that the program would not work, and it could even work in a way which would result in catastrophic consequences! I know why the ground asked the astronauts to manually enter the program instead of telemetering it up into memory, I know, and I am going to tell you: It's because the ground likes to run a risk, to create suspense. You know, the taste of adventure, like when Armstrong landed when he had less than a minute fuel left. Good old hollywoodian suspense! |
 They say: "The LM ascent powered flight autopilot obtains control torque only by means of the reaction jets. The engine is fixed; it cannot swivel. This control then operated very similarly to the free-fall coasting flight autopilots described above, but with the addition that the system estimates the torque arising from the offset of the main engine thrust from the center of gravity. Controlled limit cycles then will normally operate so that, unless error margins are exceeded, reaction jets will be fired only to oppose the main engine thrust misalignment torque" The problem of the ascent part of the lunar module is that, unlike the descent part, on one hand the fuel tanks were not disposed symmetrically to the module's axis, which makes that its center of gravity was excentered, and that, on the other hand, the ascent's engine could not be swiveled.  The consequence is that the main engine's thrust could not be aligned with the center of gravity, and was tending to make the lunar module rotate. This rotation had to be countered with the vertical thrusters of the RCS. This was giving an irregular attitude to the lunar module, and was wasting the RCS fuel. It could have been avoided by making it so that the main engine's thrust could be aligned with the module's center of gravity. It was not even necessary that the engine could be swiveled for that purpose, just disposing the fuel tanks symmetrically would have sufficed. But the Apollo engineers took it as a challenge not to make things rationally to see if, in spite of the erractic guidance and the wasted fuel, the lunar module would still be able to make its rendezvous with the command module. You know, the spice of adventure! |
 They say: "The computer compares estimated spacecraft rate with the desired rate being commanded by the guidance programs. The resulting rate error is integrated and shaped by a seventh order difference equation filter, the output of which command the engine swivel servos". This is an heresy. In normal guidance, the desired rate is compared with the actual rate as measured by the acquisition devices (gyros & accelerometers). Comparing it with an estimation given by a model makes absolutely no sense and cannot work. They make it sound impressive by using the term "seventh order difference equation", but it remains senseless. But the Apollo engineers think that it is more important to sound impressive than to make things rationally. After all, God will watch over the lunar module, won't he? |
 They say: "The benefits of this nonlinear control law became particularly evident when it appeared that the total time downward firing jets could operate in the descent configuration was severaly limited because of the danger of burning the descent stage by the jet plume". So they are saying that the navigation should avoid to use the down firing vertical thrusters of the RCS, because they are susceptible of burning the lunar module! What about disposing them so they can be fired without danger for the lunar module? You know, the taste of danger! |
 They say: "Since the radar antenna and the IMU are mounted at separate locations in the spacecraft, the processing provides for an unknown but assumed constant misalignment between the two and corrects the line-of-sight calculation for a computed estimate of this misalignment". So they can apply a correction although they admit that the misalignment is unknown! Anyway there is no point aligning the IMU with the radar antenna, for the angles measured by the IMU also apply to the radar. The IMU measures angles, not distances. But the Apollo engineers love to apply corrections they have concocted in their own special way. |
 They say: "This onboard solution matched the ground tracking solution within a fraction of a foot per second". The ground solution cannot compute a trajectory all in advance, for it depends on parameters which are dynamically acquired and are not known in advance. So, there is no point making this comparison. But the Apollo engineers love to make irrelevant comparisons. |
 They say: "The computation capability for the final criticial TPI maneuver to put the LM on an intercept trajectory with the CSM was included in the CM computer program so that this solution was also available. The LM navigation and computation indicated (+19.4, +0.4, -9.7). The CM navigation and computation indicated (+19.6, +0.5, -9.0). The ground tracking solution was (+19.6, +0.1, -10.5)." If the LM and the CM run their computer program with the same data, they should have obtained the same computed result. If they didn't, it means that each one run the program with their own local data. The ground, on its side, obtained a computed result which is different both from the LM and the CM. Question, what data did the ground use, it if is neither the one of the LM nor the one of the CM? Data it would have itself acquired? Impossible, the ground is too far to acquire data by itself, it can only use telemetered down LM data or CM data. So, did the ground mix the LM data and CM data to build up its own data? Probably fabrication secret! |
 They say: "When superposition is achieved, the navigator pushes the mark button which signals the computer to record the navigation angle and time of mark. Using a kalman optimum recursive filter formulation, the computer then determines the state vector change this measurement could cause if incorporated and displays the resultant position and velocity change magnitudes. If the navigator is satisfied subjectively with his mark, he allows the computer to incorporate the state vector change". How do you want the astronaut to make a judgment on the state vector change which is displayed before him? How can he decide if it is acceptable or not? And what would he do anyway? If he makes his alignment again, the state vector change will remain the same. So, it is obvious he will always accept the incorporation of the vector state change. It is not up to the astronaut to make the decision that the state vector change is correct or not, it is up to the computer; if the computer sees that the change is too important, it warns the astronaut to make his measure again. But the Apollo engineers like the astronauts to feel important. |
 They say: "Although ground tracking navigation was the primary system, the onboard navigation system had the task of confirming a safe trajectory and providing a backup for return to earth in remote chance that ground assistance became unavailable for onboard use." So now the AGC is able itself to make the trajectory computation which is made by the mainframe computers on earth! The Apollo advocates have kept repeating ut that it was unimportant that the onboard computer was not very powerful because the computation of the trajectory was done by the mainframe computers on earth, and now, in this document, they say us that the onboard computer was also able to do it, as a backup in case that the ground assistance would become unavailable. So it was a computer which was very powerful in the same time that it had little power. Special Apollo logic! |
