Final preparations for 50th anniversary demonstration tour with AGC

FINISHING THE LEGO LM MODEL AND STAND

I glued together an acrylic stand that would allow the LM to sit up in the air about a foot. It has a pivot to set the LM with the descent engine facing forward during the initial part of our landing demonstration and then to pivot to place the engine bell downward for the last portion.

It required a bit more bracing than I expected but a quick trip to Tap Plastic got me the extra parts I needed. It can be disassembled and carried in my suitcase for setup at each demonstration event.

I needed a small enclosure to hold the resistor boards, controller and wiring out of site. I rummaged through my parts bins and found something useful, even if not visually appealing.

BUILDING STAND FOR PATCH PANELS AND PLUGBOARDS

The stand to hold the electronics panels up is more challenging due to the combined weight. I stated with two vertical strips of 1/4" acrylic but, just as with the LM stand, I had to add bracing before it was ready for use on the trip.

Starting from the bottom, we have the right hand patch panel placed. This panel will have the 35 banana plug leads from the DSKY replica pulling forward, which is why I chose it for the bottom spot. Next is the main interfaces board which will convert spacecraft signals to modern TTL levels.

Above that is the left hand patch panel. I placed the interfaces board between them to shorten the runs of banana plug cables that splay from the interfaces to the two patch panel boards. Finally, the top position is held by the secondary interface board which provides the last five AGC C level output signals needed for my LM model lighting. These needed aluminum holders to connect them to the acrylic vertical rails.

I picked up some better bolts and nuts for assembling everything and stowed them in my luggage with the stand pieces. I had to reinforce the acrylic with thicker rectangular braces just to keep every thing standing vertically. It was quite solid and dependable once completed.

Our 'rack' of patch panel and interface boards

TESTING THE LEGO LM MODEL LIGHTING

I first set up a temporary version of the controller firmware without the input pullup resistors, thus making each input stay at ground unless I explicitly inject a high level. This let me test the key inputs - the 16 RCS jet signals that cause LEDs to light on the model's RCS quadrants. Along with that, I tried out the engine on and engine off commands, viewing the descent engine bell light at minimum thrust brightness and watching it go out again.

To perform a more comprehensive test, and to help with checkout, I set up a self-test capability at power up of the controller board. It will light each logical group of RCS thrusters in turn; up, down, forward/back and side.

It then will turn on the engine, throttle it up to full thrust, take it back to half thrust, and turn it off. This allows me to check quite a bit without needing a tester to drive the controller.

An external tester (another Arduino) produced pulse patterns to further test the throttle control portion of this model. I had it all wired together ready for testing Sunday morning. By afternoon I want to start packing everything for my departure Monday morning.

MINIMIZING HEAVY POWER SUPPLIES IN MY LUGGAGE

Our lab and my home testbench makes use of triple section power supplies as well as more than one supply box.  That would be painful to have to haul around on the demonstration tour next week. Mike is bringing the big 28V supply that will feed the AGC and supply my interface circuits.

I need to bring a beefy 5V supply to power the DSKY and the controller for the LEGO LM model. There is another voltage necessary if we will be sending pulses into the AGC (the Y type circuits) - 14V - and I don't want to drag around a separate supply. Fortunately, the AGC delivers 14V on another pin of the patch panel.

Programming Arduino to drive LEDs on LEGO LM model based on signals from AGC flying mission

PROGRAMMING THE RCS AND  DESCENT ENGINE CONTROLLER FOR THE LM MODEL

The Descent Propulsion System (DPS) is the engine for the LM landing, while the Reaction Control System (RCS) is a set of thrusters that control rotation and translation of the LM by emitting short bursts out of one or more of the 16 thrusters on the spacecraft.

The DPS is turned on and off by two signals from the AGC, Command Engine On and Command Engine Off. Its initial thrust level is 10% when it is turned on. This gives time for the AGC to move the engine on gimbals to reduce and pitch or roll movement due to off-axis thrust.

The computer then will throttle the engine up and down through its usable range of 10 to 65% or 100%. For technical reasons, it can't run long in the range between 65 and 100. This is implemented with a counter that is incremented or decremented by pulses from the AGC (Increase Thrust and Decrease Thrust signals).

When the counter is 0, the engine is at its minimum 10% thrust level and when the counter reaches 3200 the engine is at 100% thrust. That means that each increment or decrement changes thrust by .028125% but the LED I will be using does not have the granularity to show 3200 steps of brightness with an 8 bit value.

Instead, I will use 18 steps from 10% to 100% brightness. Taking the counter modulo 178 will give me a step number from 0 to 17 which selects from the table of 18 brightness values for the LED I am using.

The two thrust change signals are pulses that add or subtract one from the counter, but limiting it to values no lower than 0 and no higher than 3200. I set up interrupt routines triggered by the rising edge of those two pulses; these routines simply bump the counter up or down by 1.

The main routine monitors the counter modulo 178 and selects the appropriate brightness value accordingly, but only when the new step number has changed. The main routine also turns the engine completely off or switches it on based on the two engine command signals.

RCS jets will illuminate the LED that represents that thruster. A pulse on the RCS jets is a minimum of 13 milliseconds long, so I will set a start time when I illuminate the LED, and won't switch off the light if the control signal becomes LOW unless at least 13 ms has elapsed.

I coded this up and loaded an Arduino Mega 2560. I now plan to whip up a testing circuit using an Arduino Uno to generate various control signals, different durations, and try stepping the engine up and down.

INVESTIGATING ACCESSING THE DOWNLINK TELEMETRY FROM THE AGC

The Apollo Guidance Computer outputs some words of data on the downlink to Mission Control in Houston, which are joined to all the other sensor and biomedical data on the same link. The telemetry circuits in the Apollo spacecraft control the link and request data from the AGC at the appropriate time in the transmission. This data rides on the same microwave (S-band) signal that carries voice and television signals.

Telemetry runs at 51.2 Kbps, high rate, as long as the unified S band link is available. When the spacecraft uses the backup omnidirectional VHF links the data rate is slashed to 1.6Kbps, called low rate. The AGC operates at either rate, controlled by the telemetry system.

The telemetry system sends a pulse on the Start Downlink signal line, followed by a stream of 40 Downlink Sync pulses at the high or low data rate, terminating the session with a pulse on a separate Stop Downlink signal line. Each session, begun with a Start Downlink pulse, occurs at a rate of 50 times per second for high rate and 10 times per second for low rate.

When each Downlink Sync pulse arrives, the AGC sends out another bit by emitting a pulse on Downlink 0 Bit signal line if the data is zero or skipping a pulse if the data value is one. This was chosen so that the stream from an inactive AGC consists of all one bits.

I am thinking of developing a box that will sent the Start, Sync and Stop pulses to the AGC, capturing the bitstream it sends back. Time is extremely limited before I head out for the demonstration tour, but if it is easy to bang this together then I will try.

Improving the interface board and patch panels for demos, plus LM Model set up to display jet firings

NEW INTERFACES BOARD CHECKOUT

I designed a replacement board to house interface circuits that allow use of modern 5V TTL or 3.3V LVCMOS devices to drive or monitor the AGC signals. The spacecraft itself uses either 28V logic levels or short 10-14V pulses on wire pairs for signalling, neither of which are friendly to an Arduino or FPGA.

Each of these new boards is essentially a rack width (almost 19 inches) and houses one third of the total input-output circuits used by the AGC. I chose that fraction because the PCB fab I used had a minimum order of three boards for their fast turnaround prototype service. Thus one of the PCBs houses 19 type D, 13 type C, 11 type Y and 18 type XT circuits. D and Y circuits are inputs to the AGC of discrete and pulse type respectively. C and XT circuits are outputs from the AGC, discrete and pulse.

Apollo to modern logic interfaces board

I built the board and then subjected the circuits to testing to be sure they worked properly. Using signal generators, oscilloscopes and the like, I produced pulses with my type Y circuit and read them with a type XT on my board. In the same way, I toggled logic levels with my type D circuit which were read correctly on the type C. I used a signal generator first but later an Arduino produced both discrete and pulse test signals and detected the results from the receiving circuits

This board will be mounted just above one of the two rack wide patch panel boards we use to route all the AGC signals from the dense A51 connector to banana jack receptacles that are easily accessible. Banana plug cables hook any chosen circuit from the AGC to the interface board and from there to switches, Arduinos etc to work with the signals.

BUILDING VISUAL DISPLAY FOR DEMONSTRATION TOUR

I began the task of soldering small 30 gauge wire to tiny LEDs that I will place inside the nozzles of the Reaction Control System (RCS) quadrants on the Lego Lunar Lander kit. I had to figure out a way to route the wires that is not distracting to the viewer. The LEDs I will mount inside the Ascent and Descent engine bells are larger.

The Lego kit also arrived today. Only 1087 parts to assemble; somehow it took five hours to build. I skipped the moon surface portion as well as the astronaut figures, concentrating on the portion I will display, but that was a small fraction of the kit.

LEGO model to install LEDs in RCS and engine bells

I needed to work on an anchor point to hold and orient the LM. I can't use the top of the LM because the ascent stage pops off the descent half, the weight would be enough to have it fall aprt if supported only by the top. I needed  something that holds the descent stage and rotates, which will allow me to orient it engine bell forward for part of the descent and then engine bell down for the last portion of the landing.

The solution was some clear acrylic with a stand and pivot. A trip to Tap Plastics nearby will give me the materials I needed. While there I will buy materials for the rack stand to hold the two patch panels and my interface circuit boards. They have to disassemble to travel in my luggage for the demonstration trips, otherwise I would just build permanent stands or use a half height rack enclosure.

Installing the LEDs for the RCS engines was quite challenging. My first plan was to use 0603 surface mount LEDs with wires tacked onto them, super-glued into the model. The problem is the delicateness of the LED and the small size. I had wires break off ruining the LED as I tried to place them into a thruster cone.

Preparing 3mm LEDs

Inserting 30 ga wire through drilled holes in LEGO pieces

I then bought some 3mm thru hole LEDs, bright red when illuminated but transparent white otherwise,  and prepared them for mounting. Using my 30 gauge black wire to tack onto the base of the LED leads, I could cut the rest of the leg off and use heat shrink tubing to insulate. Two wires per LED until downstream where I can combine all the common wires.

I put a 1/8" plastic drill in a small press, placed the lego pieces in a soft vise and drilled out openings inside the four thruster cones. I also drilled out an opening near where the quadrant attaches to an arm on the LM body. This gave barely enough room to fit eight wires through the final hole.

Using my stereo microscope, various tweezers and lots of patience, I threaded the wires through the LEGO parts and pushed in the LEDs. After a bit I had two of the four quadrants done and found that it was not too frustrating as long as I took my time on each.

By Thursday morning I had all four quadrants, 16 thrusters in all, with LEDs wired out to a terminator breadboard which also housed the 16 resistors. The wires ran into the descent stage and out along the bottom, where the black wires blended pretty well against the black LEGO bricks.

Light in RCS quadrants in place, wiring exiting at bottom

It was a simpler job to wire up an RGB serial addressable LED into the Descent Engine Bell. That completed all the lighting I need to use the LM model to show in real-time the thruster and engine firings that occur during the lunar landing we will perform for our demonstrations.

PATCH PANEL COMPLETION

I wired up every signal from the AGC to its circuit pin on the patch panels. This gives us the flexibility to interact however we want, making use of the interface board to do so using regular TTL and LVCMOS devices and controller boards. There are more than 300 wires involved in completing this task, spread over two days to give my back a rest between sections.

Next up was building the stand for the two patch panels and the interface circuits board. The main principle was to use screws and nuts to assemble the stands but allow them to fit compactly in my luggage for transport. It will take a few days for Tap Plastic to cut all the pieces I need but by Saturday I should be assembling the stands.

PROGRAMMING ARDUINO TO LIGHT MODEL LEDS BASED ON ENGINE FIRINGS

I put an Arduino Mega 2560 into duty as a controller for my LEGO Lunar Module display. It hooks to 18 of my type C interfaces and 2 of my type XT circuits. Since my one interface board implements only 13 type C interfaces, I had to partially build a second board to provide the patch positions for the remaining 5 C interfaces.

That build was done quickly, although I was short three red banana plug receptacles which are needed for type C circuits. I had to make do with three yellow jacks which normally would be used for XT circuits.

From the Arduino viewpoint, a type C circuit coming from my interface PCB is simply an INPUT_PULLUP, an input with a weak pull-up resistor inside. The type XT circuits produce pulses that must be detected by the Arduino so I used interrupt service routines for those two pins triggered on rising edges.

Using the MIT documentation of the equations used in their hybrid digital/analog simulator of the LM, I collected the information I needed to properly simulate the throttle of the descent engine. Our AGC will increment or decrement a counter in the engine controller to vary thrust. That engine has a minimum thrust level of 10%, achieved even when the counter is at zero. The counter goes up to a maximum equivalent of 3200 which represents full thrust of the engine.

I also have the lag characteristics they used for the engine. It takes 2.3 seconds from when the Engine On command is received until it is producing the minimum 10% thrust, and when switched off it takes 380 ms. Every thrust change command requires about 300ms to take effect.

I am attempting to model the engine LED in the model based on the MIT defined characteristics. This adds some complexity to the Arduino program but the results should be worth it. More on this soon.

Final preparations for public display and demonstrations for the 50th anniversary of Apollo 11

Current Switch Module failed diodes

We will mill away all the rest of the potting on this module, drill out the 26 diodes that we haven't yet replaced and populate the module with suitable replacements. That will restore the erasable (traditional core RAM) memory to full operation.

Improving demonstration for spectators

While we can accomplish a lunar landing using just the AGC and DSKY, it requires the spectator to visualize quite a bit after they are taught to interpret various numbers displayed by the DSKY. We want to help visitors visualize what is happening so we worked on some improvements.

Mike worked on changes to his test monitor board, the one that plugs into the AGC test connector A52 and also runs with his FPGA replica of the AGC. He made corresponding changes to the NASSP plug-in for the Orbiter simulation, such that the simulation will use the real AGC (or FPGA AGC) rather than a virtual AGC inside the package.

Using this, we can interact with our AGC but see the results on the screen showing the inside of the Lunar Module and the view outside the windows. All the displays such as the altitude tape meter and FDAI flight director work properly. This gives a compelling simulation of the landing, with the engine thrust climbing, the view pivoting as the LM is maneuvered, and appropriate sounds emitting from the screen.

In addition to this, we will bring the LEGO Lunar Lander with LEDs placed in the RCS thruster jet openings and in the bells of the Ascent and Descent engines, driving them based on the pulses emitted by the software running in the real AGC during the mission. An Arduino interprets the pulses and controls the LEDs.

Organizing demonstration tour for 50th anniversary of Apollo 11

Now that the AGC is running well and we are prepared to demonstrate it supporting portions of the Apollo 11 mission, we have to set up public appearances for later this month. Having just completed booking the trip, I can share where we will be appearing.

At the start, we will bring the AGC to the home of the lead designer, Eldon Hall, and let him enjoy the sight of his masterpiece working again after all these years gone by. This will take place in Florida, after which we will fly up to the Long Island, NY area for the first public appearance.

We expect to give short talks and demonstrate landings at the Cradle of Aviation Museum, near LM 13 and CM 2 plus a LM Simulator and other Apollo era artifacts. This will occur on the 18th of July. We are waiting for the museum to define times more exactly.

The following day, July 19th will have us setting up in the MIT Museum in advance of our public appearance all day and evening of July 20th, the fiftieth anniversary of the landing on the moon. We will give talks and demonstrate portions of the flight including landings multiple times on the 20th. Once again, we don't have exact times yet.

That concludes the public demonstration portion of our trip, but we will have a chance to meet with many of the original programmers and designers from MIT and others who supported the success of the Apollo program.

Another diode bites the dust in the AGC Current Switch Module

Setback with erasable memory, failure in Current Switch module

Near the end of our time with the AGC, we were running various portions of the Apollo missions such as LM powered descent initiation, LM rendezvous calculation to rejoin CM, or CM burn calculation to hit the earth entry interface.

Suddenly, we were seeing hardware restarts and the software was not running correctly. Using Mike's test monitor we quickly realized that erasable memory was not working properly. We could rapidly trace this down to a failure in the Current Switch module (again).

Testing diodes after powering down the computer led us to a third diode that failed open, just as the first two had been. We didn't have enough time left to mill out new windows in the polyurethane foam encapsulation, drill out the bad diode and insert a replacement.

This module has 28 such diodes - three have already failed and NASA documents show that Raytheon switched from the original diodes to new types due to failures similar to what we experienced. The original diodes had a mesa construction, something the semiconductor industry quickly moved beyond.

We kept the Current Switch Module here so we could remove all the encapsulation on the module, then replace the 26 original diodes with modern 1N914B diodes like we did with the first two we found. This should be completed so that we can rejoin the module with the AGC for live demonstrations we will do in July.

Back to Houston until our next session

The AGC flew back to its home in Houston, until our next session and subsequent demonstrations.

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.

Interacting with the running Apollo Guidance Computer using DSKY

Testing the DSKY substitute

We hooked up the DSKY substitute to the Apollo Guidance Computer and verified that all the lights, displays and keys worked properly. We now have a physical manifestation of the interface used by the astronauts to interact with the computer.

Video of DSKY working with AGC

Testing Ben Krasnow's electroluminescent panel

Ben (Applied Science YouTube channel) came over with the EL panel he built to NASA specs and we worked to interface it to my DSKY substitute. After a bit of work, I got it mirroring the display on my DSKY as the AGC ran various Apollo era software.

Video of Applied Science electroluminescent panel used with AGC

It was great to see a real electroluminescent display providing the output from the computer. Realism of the interaction took a step up.

Using the DSKY with the AGC

We ran several portions of the Apollo 11 LM mission, using the DSKY to interact with the Luminary 99 flight software that flew in the spacecraft. This included calculating the rendezvous burn after ascent from the lunar surface and of course the powered descent down to the surface. No 1202 alarms for us, because we didn't have a simulated Rendezvous Radar feeding pulses to overload the computer.