Final upgrade to our AGC and working on simulating missions such as lunar landing

Adding the PRO key support to this AGC

The original version of the block II computer had a key on the DSKY marked STBY that was used to put the computer into sleep mode (and bring it out again). Soon, it was replaced by the label PRO and was used for two purposes - standby same as before, and signaling PROceed when the astronaut was ready to approve some action proposed by the computer.

Prior to having a PRO key, the astronaut had to push VERB, push 3, push 3, and push ENTR to confirm a proposed action. When there are a sequence of requests from the program, such as during the start of a landing sequence, having to mash four keys to give assent took time. In some cases, the astronaut had just five seconds to approve the start of a burn; if the VERB 33 ENTR had a typo, it might be impossible to redo it fast enough.

The original STBY function is purely done in hardware. Once the software sets a bit that allows standby, the key itself was wired directly to circuitry that dropped the switchable 14V and 4V supplies, leaving only a base level of power for functions such as pulse generation needed by other hardware in the spacecraft.

The new second use of the key for approving action requires that the software be able to see when the key is pressed. This was accomplished by a small hardware change that routed the key signal from the standby circuitry to set a previously unused bit in one of the I/O channels. Our AGC, the last of the prototypes before the flight versions, did not have the PRO key wired to the channel yet.

We recreated the change, using wire wrap, such that when my DSKY has its PRO key pushed, it sets the bit in the channel to approve a program proposed action, but will still switch off the computer if held long enough to activate the standby circuit.

Challenges running the PDI program for the Apollo 11 landing

We have been able to run program 63, the way you accomplish Powered Descent Initiation (PDI) to lower the orbit of the LM and transition through to landing on the surface. However, once the program sets up for the burn of the descent engine and is given permission by the PRO key to fire, the lack of acceleration is detected. The software flashes Verb 97 which means thrust failure and we can't slow down or reach the surface.

Marc set up an accelerometer substitute using an ATMEL processor and three potentiometers, allowing us to indicate (crudely) that acceleration is occurring on any or all of the three axes. However, the question of which direction the acceleration should be injected is not a simple one. In fact, the answer necessary to bring the LM to the ground with zero forward velocity is devilishly hard to calculate.

The inertial measurement unit of the LM (and CM) consists of a platform (called the stable member) which has three gyroscopes and three accelerometers (PIPAs) mounted so that X, Y and Z rotation and acceleration can be measured.

This stable member is suspended on three concentric gimbals so that regardless of the rotation or movement of the spacecraft, the stable member will remain locked in the same position relative to the milky way galaxy. It drifts slightly over time, which is why it is aligned using the star sighting telescope to return it to its ideal position.

Each gimbal is used to read off rotation of the spacecraft around the stable member in one axis. For technical reasons, having only three gimbals means that the inner and outer gimbals can move so they are parallel to each other. This is bad because a rotation can't be assigned to only one axis, it instead is seen as a movement on both axes simultaneously. This foils the ability to recognize movement properly and is called Gimbal Lock.

Certain rotations of the spacecraft can move it so that it approaches or reaches Gimbal Lock. Once in gimbal lock, the stable member must be reinitialized and star sightings are necessary to align it, a time consuming process. To avoid this, the people in Flight Planning (and in Mission Control) have to plan out the orientation of the stable member so that all the planned maneuvers of the spacecraft can be made without approaching gimbal lock.

Consider the way the spacecraft evens out heat and cold as it flies between earth and moon - the Passive Thermal Control mode - where the spacecraft has to spin on an axis like food on a barbecue spit, with the axis at right angles to the sun. Turning one rotation every two minutes means the stable member is rotating on its gimbals at the same rate and that motion can't be allowed to cause gimbal lock.

At many times during the mission, the orientation of the stable member relative to the galactic background is changed to put it in the best position for the maneuvers ahead. The orientation information is sent up as a REFSSMMAT, a reference stable member matrix either vocally or by the ground using 'remote control' to press DSKY keys to enter the new data in the AGC.

The flight director/attitude indicator display (the 8 ball) is tied to the stable member, thus it is showing where the stable member is sitting while the spacecraft rotates around it. That works out find when in a straight line trajectory such as during translunar coasting, but introduces problems when in orbit around the earth or the moon.

Since the stable member remains fixed relative to the background of the universe, the orbital path will cause the member to appear to rotate as the spacecraft circles the globe. If we start with the stable member parallel to the moon's surface at one point and leave the spacecraft in that same position, as we orbit our nose will appear to pitch up then nose over until we seem to be upside down relative to the moon when we are at the opposite point of the orbit, gradually rotating again until we are flat and parallel at the starting point of the orbit.

The flight director/attitude indicator will rotate around with the stable member (and spacecraft). If we cause the spacecraft to pitch at exactly the right rate, then the spacecraft 'floor' will always be pointing down towards the moon. Our stable member, as a consequence, will be rotating as we orbit and our 8-ball won't make sense.

A special device named ORDEAL will permute the 8-ball so that it seems to match the 'floor' of our spacecraft, and cause the correct pitch rate, so that the pilot does not see the stable member rotating. However, regardless of the tweaked display, the reality of an orbit means that the stable member is rotating while we circle the moon.

That means that the accelerometers idea of X, Y and Z is based on the stable member and are rotating compared to our spacecraft. During the landing, therefore, the direction of the thrust vector of the descent engine is rotating and has to be calculated based on the original setting of the REFSSMMAT, the place we are in the lunar orbit and the orientation of the LM compared to the moon's surface.

The landing of Apollo 11 begins with the crew oriented to look down at the moon's surface with the descent engine bell pointed in the direction of the orbit. Later in the descent, the LM pitches around so that the astronaut's feet are pointed down at the surface and they are looking forward in the direction they are moving. All these occur while the stable member stays fixed in inertial space.

As you can now see, the direction of acceleration we have to input to the AGC, which are given strictly to the X, Y and Z direction of the stable member, have to be manipulated based on all the factors above.

One simplification is that we don't care how the LM moves from face down to face forward since the stable member doesn't change at all. What does matter, however, is the effect of that movement on the thrust vector relative to the 1/6 G acceleration of the moon on the spacecraft. That must be factored in, both by the AGC in computing the burn and pitch up timing, but also in our injected acceleration.

We will need to issue AGC commands to look at the orientation of the stable member at the time we begin the engine burn, calculate how this rotates as we move around the orbital path/descent path, and apply acceleration appropriate to that.

So much more complicated that simply delivering input on the axis of the descent engine bell of the LM. We expect we will even see an alarm thrown after we think we have landed, unless we provide acceleration at 1/6 G in the proper direction to match where the moon surface is relative to the stable member.