Repairing Telequipment CT-71 Curve Tracer - part III

REPLACEMENT KNOBS

The new knob is a hair small, esthetically, but completely functional. I drilled the center hole, installed the new V/div knob and then added the thru rod and inner knob for the Series Resistance. They work great. To wrap this up, I want to add a nut to hold the V/div control a bit more firmly in place, but I can perform any device testing as this sits.

Replacement V/div knob behind the Series Resistance one

The rotating scale for the Series Resistance would align a set of resistance values such that the inner knob, when pointing at the outer .2 V/div scale position, selects the lowest of the eight resistance values that can be picked for the chosen Peak Wattage.

Originally, the Peak Wattage lever would turn the inner scale, but I can just refer to the scale and set up a spreadsheet that lists the settings for each of the four wattage peaks.

Resistance setting guide for .5 Watt peak

This is derived from this rotary scale and the movement imparted to it by the Peak Wattage lever.

Rotary scale and teeth that engage with the Peak Wattage lever

NUT TO HOLD CONTROL ASSEMBLY IN PLACE

The nut on the control assembly was a cylindrical shaft around which the scale rotated It was much too deep to allow my replacement knob to work. I tried to match the threads to bolts at local hardware stores, to determine the thread type for the nut I would buy. It was closest to Metric 10 or 3/8" Imperial, but the threads are finer than those in the stores. M10-1.0 was too coarse, as was 3/8-24.

I decided that it must be M10-0.75 although I couldn't find any of them at the big box stores or local hardware shops. Based on the likelihood that this is the proper size, I ordered some nuts online that were that size; should be here within a week.

Repairing Telequipment CT-71 Curve Tracer - part II

FURTHER DIAGNOSING OF THE HORIZONTAL POSITIONING BEHAVIOR

With the fuse FS1 installed, horizontal and vertical positioning worked properly. I ran through some initial checks of a PNP transistor I had but was still not getting the curves I expected. I had not yet put on the new outer knob and thus had no clear idea what V/div and load resistance values I was using.

Once the knobs and interlocks were working properly,  I set up the tracer on the bench and made use of my oscilloscope and VOM to verify that it was behaving properly. First up was a test of the collector voltage levels and the load resistances. The voltage was easy to look at but to I needed to drive it through my VOM to measure the current in order to properly assess the load resistors and other details.

With that working properly, and the current settings for vertical scale working smoothly, all that was left to test was the step generator that drives the base of the transistor. It was immediately obvious that I had the knob pointer set wrong.

I used the wiring diagrams and back of the control to verify when I was on a particular target setting, then moved the knob to match. Now the behavior of the curve tracer is perfect.

INSTALLATION OF NEW OUTER KNOB FOR VOLTS/DIV SELECTOR

I searched for a suitable knob to use - it had to have dual setscrews to tighten to a 1/4" round shaft and should permit drilling out the front where the inner control shaft will emerge. I picked a larger knob with a distinct pointer on it.

It arrived but it is too large in diameter, blocking the scale on the faceplate for V/div. For the time being I will use it, having drilled the hole and mounted the series resistor knob in front of it. I tried to rotate the controls to their extreme ranges but found that the V/div knob, which should allow for ten positions, would only move through eight of them. I suspect that there is a mechanical interlock from the rotating scale that I removed.

I partially disassembled the controls to check out that possibility. I had to play with this several times before I could get proper operation of the two controls, V/div and Series Resistance. I still need to acquire a smaller outer knob and to add a nut to hold the control assembly better but I am happy with the operation. The new knob is on its way, only needing some drilling once it arrives.

SAMPLE CURVE USING THE DEVICE

Here is a PNP transistor (2N2907A) that I hooked up for my initial test.

2N2907A curve tracing

Repairing Telequipment CT-71 Transistor Curve Tracer - part I

Curve Tracer to be repaired

DIAGNOSING THE FAULTS

There were five defects in this unit that I found after inspection and while testing some sample transistors. I will try to repair all of them to bring this into full operability which I can make use of in future repair projects.

One of them is cosmetic - the CRT has a blue filter plate installed under the ruled line cover plate, but that plate slips sideways and doesn't sit covering the entire tube face. I am not certain how this was supposed to be anchored originally, but it definitely needs some adjustment or assistance to sit properly.

Two were clear from a quick visual observation. There is a toggle switch that connects the instrument to the left or right set of transistor sockets, used to make quick A/B comparisons. The handle was broken off. The other issue was a broken rotary selector knob, apparently this is a common problem with Telequipment devices where the plastic decomposes and fragments into powder.

The knob is a complex unit that rotates the clear knob to pick locations on the outer printed scale, with a small concentric plastic knob that independently selects positions on a rotating inner scale that sits inside the broken knob in question. The inner rotating scale will turn based on a nearby lever. Finally, this Rube Goldberg control interlocks positions, so that the outer plastic and inner knobs have constraints on their position based on how the inner scale is positioned.

A set of transistor sockets are built into a plate that plugs into the front of the unit, but that plate is missing entirely from my unit. I have to either secure a replacement or build my own sockets to hook to the unit.

Finally, while testing transistors, I discovered that the horizontal position control is not working properly. For some ranges of motion, the trace jumps wildly or disappears while some ranges seem to work okay. The first diagnosis was a bad control potentiometer, which I treated with contact cleaner. Unfortunately, that made no difference to the faulty behavior.

The potentiometer is hooked across +6V and -6V supply connections, with the wiper feeding into the horizontal defection circuits. This pot can be removed from the circuit and tested by pulling connectors from the main PCB since the pot is fixed to the faceplate and connected by wires.

One complication was that the +6 and -6 wires on this pot were paralleled to the outside lugs of the vertical position potentiometer, thus pulling the wires didn't fully uncouple the pot to be tested. After ensuring that the wipers of both position controls were unhooked from the PCB, as were the +6 and -6 feeds, I could attempt some testing using a VOM.

The two paralleled controls read appropriately, a 22K and a 500K pot yield a combined resistor a bit over 21K. That checked out fine, so I moved on to test the horizontal control wiper individually against the +6 and the -6 ends. I should see a smooth growth in resistance with movement, in reversed directions depending on the end I connected. In fact, I observed exactly that behavior. Observing the vertical pot produced odd results, until I realized that with the 22K resistor across the ends of the 500K device, the wiper would move up and down with a peak at the center, approximately 125K ohms and lower on either end.

The correct operation of the pot told me that I have a more serious flaw in the unit, not caused by the control itself but by the components on the PCB. Drat. This would take more bench time examining the behavior of the horizontal circuit. I quickly discovered that fuse FS1 (250ma fast) was blown. I ordered a new one to replace it as it may have been blown by a test on a bad transistor, but I was be prepared to discover some defect on the board itself that is causing the fuse to blow.

REPAIRING THE SELECTOR SWITCH

I found a suitable replacement DPDT toggle switch and substituted it for the broken component. I verified proper operation and correct wiring.

REPAIRING THE ERRATIC HORIZONTAL POSITION OPERATION

I have to wait for the replacement fuse before I can do more diagnostics on the positioning behavior. More on this in part II.

REPLACING THE SELECTOR KNOB

My first approach was to look for another of the knobs from a junker Telequipment machine - while I could use the acquired knob in the short term, the better approach is to use the knob to make a mold where I can cast replacements of more permanent materials.

This knob was used on two different Telequipment models - the CT-71 curve tracer that I am repairing, and the D75 Oscilloscope. I saw two model D75 on eBay but pricing has been prohibitive. One has a Buy It Now price of about $150 and the other soared to $80 (plus shipping) in a bidding war. I will keep watching but this unit is not worth my spending large amounts of money. All told I would feel remiss spending more than about $50 for this repair.

The small concentric pointer knob is one of two electrical controls operated by this assembly, the other is controlled by the outer clear knob itself. The rotating inner scale is driven by the lever which has its own (third) electrical control. I can operate the small pointer and the inner scale lever just fine, but need a method to rotate the outer knob controls while looking for a good replacement.

The two electrical controls coupled to the outer knob and small pointer are interlocked such that they can only form certain combinations of settings. The inner scale simply displays the value associated with the small pointer setting, as this changes based on the lever settings.

Position of rotating scale with right lever at .1 W setting

Position of rotating scale with right lever set at 10 W

Interlocking controls behind the complex knob assembly

The shaft for the control that is turned by the missing outer knob is set back inside the inner scale. The knob had a metal insert with setscrews that would grip the shaft. This constrains the type of temporary knob I might be able to affix to the shaft.

Since the rotating scale has no actual electrical role, I decided to remove it from the control assembly. This will allow me to mount a set of concentric knobs to rotate the two electrical controls. The outer control sets the volts per division of the horizontal sweep while the inner control chooses the collector load resistor size. The side lever which rotates the scale also picks one of four wattage peaks - 0.1, 0.5, 2 and 10.

As the volts per division goes up, so does the collector voltage. Power is the square of the voltage divided by the load resistor, thus one thing the lever does is set the smallest load resistor value possible to implement the wattage limit.

For example, with a 2W limit, the highest setting of 100V/div applies 400V peak to the transistor under test. The load resistor needed to hit 2W at that peak is 80K ohms. Selecting 0.1V/div or 4V peak and a setting of 2W, a 2 ohm resistor is the low value. The absolute smallest resistor, for 10W and 0.1 V/div is .016 ohm and the very largest resistor needed is for 100V/div and 0.1W would be 1.6 Megohm.

The volts/division and resistor controls have interlocks that limit the maximum spread - higher voltages enforce higher minimum resistances, but the inner control can select even higher values to drop the power below the max selected by the side lever. The lever itself shifts the range of resistors being selected by the inner knob. In a sense the interaction of these three cause the inner knob to select 10 linear steps from least to max power.

Based on this, I determined that the rotating scale is not really necessary to my operation. I can use pictures of the position of the scale for each of the four sliding lever power limits and refer to that if I need to know the load resistance being selected by my inner knob position. In most cases, if the power limit on the sliding lever is safe, I can dial any of the 10 power percentages. Occasionally I will want to limit it partway - a 5W transistor with the power lever at 10W would be safe only with the first five (highest) resistances.

I found a knob that I could place on the outer shaft to indicate the V/div setting. The inner knob was installed to show, by the angular position, which of the power values was selected. My four pictures of the scale, one per power limit, let me correlate that with the resistance value.

REPAIRING THE LOOSE SCREEN FILTER

After examination of the design of all the parts, I could see that this had simply been misinstalled. I rotated it to the proper orientation and put together the stack of filter, gratule and cover on the machine. This is repaired.

REPLACING THE TRANSISTOR SOCKET BLOCK

Initially I hooked up the transistors to be tested using jumpers. I saw an eBay auction of the plate I need, but the opening price including shipping is fairly high already. As well, the sockets provided fit only a few types of transistors making this of limited utility. If I were a collector of Telequipment testers and wanted to restore this, the original block would make sense, but to use this as a bench tool I thought of a better approach.

I whipped up a design for a small project box that would house several useful transistor sockets plus other means of connection. I will build this and hook it to the CT-71 to perform transistor and diode testing. I have a number of sockets and pins on order to make the adapter box. More on this in part II.

Will perform lunar landings and show some of the AGC support gear at Vintage Computer Festival West

We will be at the Vintage Computer Festival West this weekend at the Computer History Museum in Mountain View, California. August 3 and 4.

Mike will hook up his FPGA gate by gate exact replica of the Apollo Guidance Computer and fly some lunar landings to demonstrate the central role the AGC plays in operating the LM. We will have the DSKY replica and LEGO LM model operating in demo mode, not hooked to an AGC. Also on hand are other devices we created to do the restoration and make use of the computer.

If you are in the area, stop by and say hello. Mike Stewart and I will be there both days, Ken will join us on Sunday and we expect Marc to stop in during the festival.

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.

Taking the AGC on a tour and demonstrating Apollo 11 landings

TRAVEL CHALLENGES

I flow into Houston on Monday the 15th to meet up with the Apollo Guidance Computer and its owners, Jimmie and June. Early the next morning we would fly to Florida and visit Eldon Hall, the chief designer of the AGC, to demonstrate his 'child' operating once again.

The AGC is large and heavy, but old and fragile. We transported it in a large case with foam padding, placing it into a seat next to me for each flight. This is possible if you buy a seat for the item, it weights less than 165 pounds and can be strapped into the seat securely without blocking other passengers from seeing the overhead signs or exiting the aircraft.

Due to the size, it had a business/first class seat to be sure it could be fit into the seat and fastened in place using a seat belt extender. It was in a window seat and I was traveling next to it. Two big challenges existed - getting it through the army of bridge trolls who would insist it has to be checked as baggage, and lifting a 95 pound unwieldy case up over one seat to place it into the window seat.

On each of the three flights involved, I faced a minimum of five challenges and a peak of seven on the last flight. The ticket was made with a name of Incabin Baggage Claunch and the reservation checked carefully with the airline. Checking in to get boarding passes was no problem, but things went downhill fast.

The guards hired to police the lines into TSA for security checks are focused on making passengers check large suitcases. They enforce size rules and are trained for instant and aggressive action. Usually gentle but persistent discussions, flashing of the boarding pass and unwavering commitment to proceed forward would win out.

In Boston, however, we met a gatekeeper who went ballastic and was dialing for security, refusing to listen to me. She began to berate the porter who was wheeling Jimmie in his wheelchair, until he was able to penetrate her fixation and bring her to listen for a minute. Once she truly comprehended that it had a seat, she let us pass.

TSA was a challenge as well. For two of the three flights, the case with the AGC would fit through the X-Ray scanner throat with about 3/8" of clearance, a tight fit but able to move through. In Boston I had to help move it forward on the exit belt where it was jammed. On the flight from Tampa, the X-Ray machine was smaller and the case could not fit at all. It had to be hand examined there.

The case had wheels that were balky and induced major oscillations as I tried to wheel it, a kind of POGO problem. On the bottom, Jimmie had fastened small casters that would move adequately on stone flooring but drag unmercifully on carpet. They also make an ungodly din, sounding like they were scratching up the floor below; Fortunately it was all bark and no bite.

Airports with an airside tram to the gates have their own gate trolls, fighting viciously to keep the case from traveling on the train. Gate agents needed to be carefully approached and shown the ticket before they understood that the case would be pre-boarded and placed in a seat.

I was able, with some help from Mike or June, depending on the flight, to wrestle the case up into its seat and strap it down. In most cases we were safely past the trolls, but on the last flight one of the flight attendants decided that the bag had to be up front next to a bulkhead, not in the last seat as required by the airline and as it flew on the prior flights.

Yet another troll popping up just when I had it strapped in! I was fine if he wanted to force the people in row 1 to move back to 4 so we could put the case there, but his proposed solution was to strap it into row 7 in economy. I reminded him that I had paid for a first class ticket for the bag. While he was focused on that, his partner went back, saw that the case was securely strapped in, and permitted me to sit down next to it for the rest of the flight.

I don't want to give the impression that all these people were uniformly ill-intentioned or obstructionist. The flight crew on the trip to Tampa were delighted to know what they were transporting. The captain came down to see it and admitted to being a big space fan who happened to live near and know Gene Kranz. We took pictures and they were very helpful.

The other crews offered to help me push it up the ramp when deplaning, or to wheel my carryon bag. Even the ones that initially tried to relocate the bag or get it checked softened and were very friendly and helpful by the end of the flight. Too, TSA agents were willing to work with me, helped to lift the case up and down from the luggage cart to their examination table, and even let me take a luggage trolley into the secure area to wheel down to our gate.

THE AGC PERFORMS FOR ITS FATHER

Eldon Hall, who was the lead designer of the AGC at MIT, is retired and living in Naples Florida. Jimmie had promised to show him the AGC working again, which meant a trip to Naples and setting up in Eldon's condo. The place was packed with family and space fans looking to meet Eldon and see the AGC work.

It took us two hours to assemble everything, cable it up and test it out, but finally we were ready to provide a demonstration. We had to move furniture and place his large TV near the table with the AGC in order for Mike to see the screen for the landing in addition to the audience. There was a minor issue with the LEGO LM model such that it couldn't be hooked up in time to show the thruster and engine fire, but the DSKY and everything else was working fine.

Mike flew the mission from about four minutes before Powered Descent Initiation (PDI) where he began the landing from the 50,000 foot orbit altitude by firing the descent stage engine. Mike took us through the process, from Program 63 which braked and lowered our altitude through the approach phase of Program 64 and then the semi-manual landing under Program 66 where he flew past some boulders and craters to reach a desirable spot to land. The landing was a success, to the delight of all.

Eldon had a souvenir core rope module which he allowed us to read and archive using the AGC. Mike has shared this code with the world and begun working on understanding how it relates to earlier and later versions of Apollo software.

CRADLE OF AVIATION MUSEUM IN LONG ISLAND, NY

We flew up to the NYC area to exhibit at the Cradle of Aviation museum in Garden City, near where Grumman built the Lunar Modules. We had the chance to view a nearly completed LM (LM-13) which would have flown to the moon had not NASA cancelled Apollo 18, 19 and 20 missions. Too, we could see an LM simulator and plenty of Apollo related equipment.

We set up to begin demonstrations at noon, attempting a landing on the moon using the software from the Apollo 11 LM Eagle running on our AGC. It was crowded and hectic, but we had the chance to meet quite a few fans of our restoration, who had read from our blogs and YouTube videos that we would be available today for public viewing.

We didn't have microphones and the space was kind of cramped, set up next to the LM Simulator, but we did our best to run many landings, answer questions and interact with the visitors during the day. Due to a private evening event at the museum, we had to tear down and pack up before five.

We did get the chance to visit the museum archives and see the documents given to them by Grumman - a treasure trove. We hope to be able to digitize some of the more important content in the coming months. One document we spotted would be a great aid in building our own LM simulator. It contained all the data and math equations used to build the simulation. That document was perhaps 5 inches thick.

DRIVING UP TO CAMBRIDGE AND ARCHIVING MORE CORE ROPE MODULES

The following morning, July 19, we drove up to Cambridge Massachusetts to the MIT Museum where we had a chance to examine part of an AGC that they have on display. It contained some core rope modules of the Sundial program, which is the test suite for the Command Module which is analogous to Aurora which tests the LM.

Those modules were read and archived, giving Mike even more disassembly and analysis to distract him from sleep over the coming days. We then set up our equipment that evening for the following days events. Given that setup takes about two hours, it was very helpful to complete it tonight.

It also allowed us to get everything cabled and working, including the LEGO LM model. This model will light LEDs on the RCS quadrants of the model as the AGC commands that the thruster fires. It also lights the descent engine bell and modulates the brightness as the engine is varied from 10% up to nearly 100% thrust by the computer.

DEMONSTRATIONS DURING MIT MUSEUM LUNAR DAY EVENT AND MOON SHOTS!

We had large crowds, with many lined up outside the room after people had filled in aisles and were sitting on the floor in front of the first row. As a result, we ran as many landing demonstrations as we could. While we didn't keep exact count, I believe it was around 11 during the day.

In a couple of them, things went awry but Mike was able to safely achieve a landing even with some challenging conditions. A consequence of how Mike is delivering the landing radar data from the Orbiter/NASSP simulator into the AGC counter memory locations is that the timing between simulator and AGC can misalign.

Since radar data is altitudes and velocities in three dimensions, sequentially entered into the counter, if the timing is off the computer sees a velocity as an altitude, or vice versa, which throws off its computed position and velocity for the LM. In one case, the computer believed we were 1000 feet higher than we really were.

Mike saw based on the shadow, dust clouds and other features that he was much lower than reported, so he took control by moving to Program 66 where he could ask the AGC to control rate of descent while he controlled horizontal velocity. He hovered, nulled out the horizontal velocity over a likely point and gently lowered us to the surface. In that case we were down to 2% propellant left, tight but still safe.

Many more fans of the restoration and the AGC had heard about this visit from our blogs and YouTube videos, as well as the advertising by the MIT Museum. It was a delight to meet with them and talk even though time was tight as we cycled through landing after landing.

Don Eyles sat in the first row and watched one of the landings, quite a distraction to us. He then graciously offered us access to two of his Core Rope modules in order to archive the data on them. After the end of the daytime museum event, there was a break before the adult-only Moon Shots! party began. We used that to read the ropes (and to eat and rest). The evening event allowed us to run through a couple more landings and interact with the visitors before our day drew to a close.

ATTEND 50TH ANNIVERSARY APOLLONAUT BRUNCH AND DEMONSTRATION

On our final day, July 21st, we had the great privilege of being invited to the 50th anniversary brunch for the Apollonauts, the MIT staff who designed, built and programmed the AGC and related gear. There were over 100 people there who had worked at the Instrumentation Labs, later Draper Labs, including children and grandchildren.

We did perform one landing for the crowd, after a hurried assembly of our equipment amid the bustle of a large brunch meeting in a big tent at the Newton Marriott. We didn't bother setting up the LEGO LM as it would be too hard to see across the large tent. Something was wrong and the DSKY wasn't working either, but again only the closer tables would have been able to see it anyhow.

We did ask that any of the group who had Core Rope modules consider loaning them to us for archiving and we did get a number of commitments that will keep us busy studying the evolution of Apollo software for quite some time.

AGC GOES HOME

That evening, I hauled the AGC for its final flight back to Houston. It went home with Jimmie and June while I slept at an airport hotel for my final flight back home to California. It felt odd to board an aircraft without the AGC although the process of check-in, security and boarding went much, much smoother.

Prepared to process telemetry downlink data from the Apollo Guidance Computer running Luminary 99

DOWNLINK OVERVIEW

Apollo spacecraft stream telemetry information down to the ground as part of the Unified S-band radio link. Data is collected from sensors throughout the spacecraft, covering items like propellent quantity, EKG readings, and the state of various switches. A part of the data to be sent down comes from the Apollo Guidance Computer.

The circuitry that is sequencing the different data onto the downlink will poll the AGC for its data when the proper slot in the stream is reached. It does this by triggering a downlink start pulse, sending forty data sync pulses and then emitting a downlink stop pulse. The rate of polling is fifty times per second, with each set of data from the AGC taking a bit over 800 microseconds.

The AGC produces a master clock signal at 1MHz which is used to synchronize other spacecraft systems including the downlink controller which does the polling. The controller sends the pulses roughly once per 20 us with each pulse lasting about 4us.

After each downlink data sync pulse is received, the AGC either sends out a pulse to indicate a zero bit value or does nothing to indicate a one value. This pulse occurs a bit later than the data sync pulse but well within the 20 us alloted to each pulse.

APPROACH USING ARDUINO

This would be trivial to do in hardware, such as an FPGA or even discrete TTL logic, but I am already traveling for the demonstration tour and only have a spare Arduino Mega in my luggage. I therefore have to find a way to produce pulses of 4us, timed around 20us apart, with relationship to the 1MHz master clock timing

The approaches I used exploit parts of the ATMEL processor that are not normally accessed by Arduino programmers using the development environment, but this gives me the control over timing and low overhead that is essential to have the controller keep up with the demands. As a 16MHz system and with an interrupt typically taking about 16 instructions to process, the 1MHZ master clock from the AGC would keep the Arduino pegged at 100% without doing anything useful for me.

The overhead of the usual Arduino method of timing in microsecond ranges, the micros() call, has a resolution of 8 us which is too crude for our purposes. Too, the Arduino sets up a timer to keep track of micros and milliseconds - these take cycles and can shift the accuracy of outputs if you use these for timing.

The chip on the Mega 2560 has six timer/counters built in, with two of them able to be stepped by external pulses rather than the internal 16MHZ clock. I will wire up the AGC master clock to one of them (timer 5) and it will step at 1MHz rate and synchronized to the AGC.

Outputs that I emit based on the interrupts will occur about 1 us behind the actual clock. Since it takes a few instructions to set the output state, I will be lagging the timer change by something on the order of half a microsecond. To compensate for this, I will have the timer step based on the falling edge of the AGC master clock, which puts my delayed output very near the rising edge of the next pulse.

I chose three output pins that are on the same ATMEL port (PORTA) so that I can pass in a bit mask to the interrupt routine which will just OR or AND it with the PORT to flip the pin states. I can choose externally which of the three pulse types we are producing at any time. This keeps the instruction count in the interrupt routine down on the order of half a microsecond duration.

To detect whether the AGC has sent in a pulse, indicating 0 value, or did not, for a 1 value, I hooked that signal up to pin 2 which is wired to an interrupt routine that will fire on a rising edge. Thus, during the time that we are asking for a data bit (one of the forty data sync intervals of 20 us), I will latch in a flag if the pulse arrives from the AGC. The main routine, at the end of the 20 us period, looks at the latched flag to tell if the bit returned was 0 or 1.

A simple integer based state machine will move from idle through the 42 pulses to be sent. Its states are idle, start, sync1, sync2 . . . sync40, and stop. I set up the bit masks to use with PORTA based on whether I am in start, stop, or one of the sync states. At idle, I disable the timer so it doesn't interrupt until we begin the next round of forty bits for the downlink.

It is a simple matter to save the forty bits as they are detected and then write them out on a serial link over USB during the 20 milliseconds we wait before starting the state machine again. This gives us the 50 polls per second rate that the downlink controller would request.

Using external clocks, timer routines, rising edge interrupts and tight coding with direct port access is the key to making this task feasible on an Arduino. I finished the coding over the first couple of days of the trip and hoped to plug it into the AGC to begin testing.

Unfortunately, the pace was more hectic than we had imagined. It took almost two hours to set up for a demonstration, with assembly of panels, cabling and checkout. The demonstrations themselves were public and demanded all our attention. Teardown and packing began immediately after the demonstration time ended.

I never did get to cable the downlink system into the panel while we were running the AGC software. It will have to wait for a future session where we once again are running the computer.