Apollo Guidance Computer ancillary gear - testing, testing and more testing

RAPID UNSCHEDULED DISASSEMBLY OF LEGO LM MODEL (AND REPAIR)

The LEGO model of the LM that I had outfitted with LEDs, to display when the Apollo Guidance Computer was commanding RCS thruster fire or controlling thrust on the descent engine, was in my carryon bag along with the DSKY replica for the recent tour of the east coast demonstrating lunar landings.

As we returned the AGC to its home in Houston, my bag toppled out of the car and smashed into the ground. The LEGO model inside had undergone a rapid unscheduled disassembly into a myriad of pieces and fragments - a pile of LEGO components and not an LM any more. I knew from the sound of hundreds of shifting plastic parts even before I opened the bag to check.

Reassembly was slightly harder because I had used superglue on a few points to keep the model suitably robust for display and rotation on the stand as the LM simulation flew the descent and then pitched forward for the final stages of the landing. Of course, these joints held but the parts they were connected to in turn disassembled, in some cases in a way that blocked straightforward reassembly.

I persevered, gently opening the glued connections and rebuilding until I had the model back together. Next up was a test of the lighting and wire integrity, which was easy because the Arduino controller has a built in self-test at powerup.  The results were mixed and upon inspection I even saw one wire ripped off an LED. With it repaired, I had fifteen of the sixteen thrusters working - the quadrant I up thruster had failed previously and remains offline.

I built in a demo mode in the controller so that I can display the LEGO LM with its thrusters and DPS engine firing. I can easily disable it with a quick firmware update for the next time this will be hooked to an AGC flying a mission.

TESTING DSKY REPLICA AFTER ITS FALL TO EARTH

Since the DSKY replica was in the same bag that fell to the ground in the airport parking lot, I had to verify its correct operation. Visually it appeared intact. I added power and connected +14V to the line that informs the DSKY that the AGC is powered and not in standby mode. The EL lines and legends on the right side panel lit as expected. I then tested a few of the left side warning lights, which properly lit based on the input wire that comes from the AGC.

More complex testing requires that I control 15 signal wires simultaneously as the digits on the display are set by the AGC emitting specific word values on the output channel. To do this and to ease checkout for any future trips, I decided to build a permanent DSKY test fixture. This used 24 relays to switch the 28V signal lines that come from the AGC, plus some resistor voltage dividers to reduce the 8 outputs from the DSKY to 5V from the 28V signalling levels used with the AGC.

An Arduino Mega 2560 was wired up to the relays and those were hooked into the main patch panel that connected the DSKY the the AGC. This involved soldering about 35 wires to a new connector on the patch panel, adding a few new D type circuits on my interface board to use temporarily for the testing and then wiring all the relays and resistors to the Arduino.

After a bit of confusion over the proper direct port access method to flip on a few of the relays, I got the code right and began to test the DSKY. Next up I saw that my relays weren't switching, even though the light was going on that should indicate actuation.

At this point I remembered that the relay board I was using was a 12V part, not a 5V part. Arggh.Enough to light the select light but not enough current to pull in the relay arm. I dropped my BPLUSSW (14V) supply down to 12, which was still high enough to take the DSKY out of standby, but could now do double duty powering my relay coils.

I did some partial tests before all the wiring was in place and was satisfied that the DSKY substitute is still working properly. Now to complete the final wiring. The DSKY will now have an HD50 connector for insertion into a special socket on the right hand patch panel, wired to the proper A51 pins.

The DSKY tester will get the banana plugs, allowing me to wire it into the patch panel to test the DSKY but otherwise leave it clean and empty. My cable had arrived so the wiring party began. Thirty five wires added between patch panel plugs and the new HD50 connector.

Then disassemble the DSKY cable to remove the banana plug wires and add the new HD50 cable. A bit tedious as I have to pick each wire in the cable and beep out up to fifty destinations on the patch panel. Once done, the DSKY is a quick plug into the panel for any future demonstrations of the AGC.

My tester had to be wired to each of the banana plug wires I removed from the DSKY cable. The tester will be plugged into the patch panel, while the DSKY has its HD50 cable connected, to accomplish testing. Many, many hours of sore back and tired eye later, it was done and ready for a test.

I successfully tested the seven discrete warning lights and whether the DSKY switches to and from standby mode based on 14V. Next was testing of the relay commands that light the remaining seven warning lights, Comp Acty light and display digits and signs.  That all worked perfectly as well.

With the tester working properly, I can use it as a demonstration driver to light the DSKY up with simulated output, in addition to its role in validating that our DSKY works. For this purpose, I worked up a demo mode that produces realistic looking displays and behaviors. I will use this at Vintage Computer Festival West this weekend.

The DSKY shows a request to run Program 63 (braking phase of lunar landing), brings up a mission elapsed time monitor, then requests some landing data via noun 68. At this time, Apollo 11 experienced a Program alarm and so do we. I have the PROG light illuminate, show the verb and noun to display alarm codes, and put up the 1202. The AGC goes back to displaying the landing data and then the entire demo loops to run again.

INITIAL TESTING OF AGC DOWNLINK DEVICE

The telemetry downlink from Apollo was driven by a sequencer that sent data from throughout the spacecraft, word by word, including some words that would come from the software running in the Apollo Guidance Computer. It requested the AGC data by a simple serial protocol, with the external sequencer as the master and the AGC a slave device.

I developed an Arduino Mega based machine that would produce, I hoped, the proper sequence of control and timing pulses to cause the AGC to shift out the bits of the downlink words. There is a Start bit, a series of forty Sync bits and a terminal Stop bit for each of the 50 words sent to the downlink each second.

My box should be producing the pattern of Start, Sync and Stop bits, at the correct timing and rates. While I need an AGC running its software to see the data coming out, I could verify the pulses I am sending as the master in the serial protocol, using an oscilloscope.

This is a bit more complicated than it sounds, because the hardware counter/timers in the Arduino are driven by inputs from the AGC of its 1 MHz master clock and won't work without those pulses. I don't have a handy AGC. The solution will be a function generator set up to produce nice 1MHz square waves that will drive the Arduino timers.

First up was watching for the Start pulse followed by a proper train of forty Sync Pulses. The scope triggered on the Start pulse, while I worked the controls to count and time all the pulses. I found and corrected a few flaws in my logic until I was satisfied that I was seeing the trains of Start and Sync pulse.

Start pulse on bottom followed by 40 Data Sync pulses above

These looked great but too short in both duration and spacing. I was expecting to produce pulses of about 4 us duration with an overall spacing of 20 us between pulses, but instead was seeing 2.5us pulses every 12.5us.

I varied all the counter values that should be controlling the AVR processor chip counter/timer, but it had no effect on the pulse widths. This was quite confusing, so I headed down two paths. In addition to reading the detailed ATMEL documentation, I experimented with different counter values.

Once I realized I had to clear existing interrupt requests before turning on the counter with it set to 0, I was able to control both the duration of pulses and the spacing between them. The granularity wasn't perfect, but I was able to tweak the trigger values to give me a 4.5 us pulse width and a cell that was essentially exactly on target at 20us.

Second was a confirmation that the Stop pulse follows the forty Sync pulses correctly. Triggering on the Stop, I backed up to verify that the last of the Sync pulses had been emitted. Third was a check that the next Start pulse follows a Stop pulse by 1/50th of a second, which my scope reported as frequency when I triggered on either Start or Stop. I chose a repeat rate of about 46 Hz, a bit slower than in real life but well within spec for telemetry.

End of forty Sync pulses above, followed by Stop pulse below

I then wired the Sync pulse output to my interface circuits board, into a Y type circuit that would produce a differential pulse output. That was patched over to an XT type circuit that would receive the pulse and produce a TTL level single wire pulse. I used the scope to look at the Sync pulses as received by the AGC, using the output of the XT circuit I just wired.

Output of Y (AGC pulse input) circuit drive by the Data Sync pulse

Back side of interface board while testing XT and Y circuits

Output of XT (AGC pulse out) going into Arduino

The pulses are as I expected, with transits that could go below zero because the diode in place has too slow a recovery time. Soon I will replace those diodes with 8ns recovery time diodes which will make the signals very safe for 5V inputs. For the time being, however, I could test my logic this way.

The AGC sends pulses on the Data bit 0 line to shift out a zero value. Absence of a pulse means that data bit is a one. In the test setup so far, I should be seeing all ones in the captured downlink since I was not injecting any Data bit 0 pulses. If I routed my Sync bit through Y and XT circuits back to the Data Bit 0 input, then I would see a pulse soon after every sync bit which should give me a downlink word of all zeroes.

Data received with no pulses arriving from AGC

Data captured when Sync pulses are fed back as data inputs

Indeed, I do get a zero now that I am hooked to the data sync pulses, but ones when no pulse arrives. This is what I expected. Until I have a more sophisticated test setup that can send a string of mixed one and zero pulses, this is as much as I can validate.

At this point I believe the downlink box to be working properly, although it will have to be hooked to the AGC to fully verify its operation. Before that happens I should learn what words are sent over the downlink, allowing me to format what is emitted into data more like the controllers in the Mission Operations Control Room in Houston would have seen.

I can see that this is already known, based on work by the virtualAGC project, so I only need to use that as a reference source to complete some mission control screens. This will be the next live display hooked to the AGC, for whenever we next have access to the machine.