AGC connectors and chance to use Applied Science EL panel

DSKY SUBSTITUTE FOR THE APOLLO GUIDANCE COMPUTER

Bottom case

The DSKY aluminum case is not deep enough to comfortably fit the power supplies for the EL wire and any connectors I add. Thus, I designed a 3 1/2" box that will fit underneath. On a side note, the resulting combined size is closer to a real DSKY.  I designed this from 9mm thick acrylic and sent the work out to Ponoko.

For connectors to the outside world, I chose to use a very similar connector to the one selected by MIT in their design of the DSKY. It is a Bendix 85 pin circular connector, readily available on eBay and on its way to me. I chose a similar but smaller two pin connector for my main 5V supply to the unit.

Power connector - total overkill for 5V supply

Connector to AGC signals and power

Planning for possible replacement EL panel

Ben Krasnow created a true electroluminescent panel as a replica of the one used on the MIT DSKY, as announced on his (watch video) Applied Science YouTube channel. He has loaned it to us and I now need to find a way to make use of this marvelous creation in the short time left before we are again working on the AGC.

Once I pick it up, I will see if its size is suitable to fit inside the aluminum enclosure I am working with on my DSKY replica. If it is, then I can remove my 7-segment display parts from my PCB, drop the mounting of the PCB lower and place his panel in the enclosure opening. His replica is programmable over USB serial link, which I should be able to accommodate from my Arduino in my replica.

The worst case situation is that I can't fit it in, thus we will need to use my replica as built with his panel sitting beside it and linked over USB cable. More on this soon, once I have completed the measurements and detailed planning.

Restoring and testing the Core Rope Simulator boxes for the Apollo Guidance Computer

Testing the Core Rope Simulator boxes

Ken Shirriff and I have been testing the two Raytheon built boxes that provide the Core Rope functionality for the AGC. We have been using some pulse generators and power supplies to send in the signals that will come from the AGC as it attempts to read a word of core rope memory.

One of the two core rope simulator boxes; Dipsticks on left, cordwood modules on right

There were a few problems we found and fixed early - a couple of broken off wires we resoldered, a screw that failed in one of the IC chip holders (DipStick), materials failure in the DipStick holders that compromised connectivity of chip leads to the holder terminals.

The early testing of the input side, where we introduced the various address bits and control signals coming from the AGC,  went well. All our address, module and strand selection signals, plus the set and reset control signals, were properly detected in the simulator boxes.

We then focused on the outputs from the simulator boxes to the AGC - 16 differential signal pairs representing the 15 data and 1 parity bits of the word that was being read. The last data bit, number 16 as the AGC numbers memory bits, did not produce a good pattern.

The signal from the AGC requesting to read some address is a 1 microsecond pulse. If the differential data coming from the external system over the 85 pin connector is a binary 1, then the pulse from the AGC causes a pulse in a transformer for that bit position. The other side of the transformer produces a 500 millivolt differential signal, one side of the winding going negative while the other side goes positive.

What we saw on the 15 working bit transformers was such a differential signal, but the failing transformer showed us zero volts on one lead and a much larger positive voltage on the other lead. It still added up to 500 mv, but it wasn't swinging the two leads in opposite directions like the other transformers.

Blue and green signals are not moving in opposite directions

After some thinking and some investigation, we realized that one of the output leads of the transformer had to be shorted to ground. Both the transformer and the resistor that is connected to that lead are sitting in a cordwood module in the simulator box, with no visible connection to ground.

Cordwood stacks components between two end plates, with the parts fitting perpendicular to the plates. This allows resistors, capacitors, transistors, transformers and other parts to be fit very close together, like bottles of soda sitting in a carton, with a plate at the bottom and top of the bottles. Wires connect the parts only on the outside, along the two end plates.

While the end plates we could see were made of nylon, with the wires from a transformer routed out of the hole in one end plate and connected to resistors or other parts, for heat dissipation reasons, the transformers are actually set in drilled holes in an aluminum body that is only covered on the ends with nylon.

Thus, we realized that the lead from the failing transformer was stretched taut in its connection from transformer to its associated resistor in the adjacent cordwood module. Somehow, we thought, the insulation has rubbed on the edge of the aluminum body and caused a short.

Ken tested the short while I manipulated the transformer lead with a toothpick. Immediately, the short went away! Our permanent fix will be to glue a small bit of insulating plastic under the lead to keep it from rubbing against the aluminum body.

Now that we had proven that all the inputs and outputs between the AGC and core rope simulator modules worked correctly, it was time to test the interior logic. That is some timing and control circuits, the conversion of module, strand and core to linear addresses, and the interaction over the thick cables with Ken's external system.

We began setting up conditions and testing the parts of the linear address generation, but soon found another problem. The generated signal for an even numbered strand worked properly for 5 of the 6 even values, but strand 10 did not work.

There are some diodes and a transformer involved in this process, so we began checking continuity and diode voltage drops. The diodes and wires were fine, but the transformer output was not operating. Again, we did some testing and a lot of thinking. Finally, we began looking at the wiring from the transformer, wondering if we had another short.

One of these orange transformer wires has a failed weld at the  left resistor post

However, we instead saw that a weld had failed. The wire from a transformer stuck up through the end plate of the cordwood module, where another wire was tack welded to carry that signal off to other circuits. Our toothpick moved the other wire, which was not in contact with the transformer lead. Next time we work on the module, we will solder the contact back, verify that our problem is resolved, then move on to the remaining interior logic of the simulator boxes.

When they are checked out, Ken can test his external system and its interaction with the core rope simulator boxes. The final test will have to wait until Jimmie comes to visit with the AGC and we can test the entire system - AGC, core rope simulator boxes and Ken's external system - and get it all working properly.

Recap of Core Rope Simulator function

The Apollo Guidance Computer (AGC) uses Core Rope Modules to store its read-only programming. Each of the six modules hold 6K words of memory, each word being 15 data and one parity bit. The programs are 'stored' in the core rope during its construction when wires are woven either through or around the cores to permanently set the value of that bit to 1 or 0.

During development of the programming it would be too cumbersome to wait many weeks for the weaving of new core rope modules anytime a change is made to read only memory contents. Several methods were used to avoid the delay, by simulating the read-only core rope using some type of regular computer memory. One such method installed two Core Rope Simulator boxes into the AGC in lieu of the six core rope memory modules it normally uses.

The Core Rope Simulator box is connected by two thick cables to some ground-side racks of machinery. The simulator box will intercept the address and control signals that come from the AGC to the core rope modules, communicating those requests to the external system which in turn feeds the word of data that is associated with that address.

One of the two 85 pin connectors on the core rope simulator boxes

The simulators never fly into space, but are used on the ground either for development or testing when rapid changes of the read only memory contents are needed. The AGC we are restoring was installed in the Lunar Module Test Article 8, which is a Lunar Module built by Grumman for ground testing purposes. The LTAs were too heavy and not fully qualified for operation in space.

LTA-8 was the unit used to certify the follow-on LMs for use in space. LTA-8 was set in a large vacuum and thermal test chamber in Houston, where astronauts worked with the machine to ensure that the flighty-ready LMs were safe for human flight.

A core rope module implements the 6K words of 16 bits each using only 512 large cores in a module. Each core stores the data for 192 bits (12 words). It does this by weaving the wires for all 12 words through the single core if that bit is to be a 1, otherwise the wire is woven outside of the core ring.

Connectors representing three of the core rope modules; these plug into the AGC

The address coming from the AGC is broken up to select one of six core rope modules, one of 12 strands (word number inside a core) and one of the 512 actual core rings. The selected core ring in the chosen module is set to the on magnetic state, while the other 511 are left in the off state.

When the control signal requests the reading of the content, the core ring is reset. Any wires that are woven through the center of the core ring will see a pulse as the core ring is rest, while the wires bypassing the core don't see any signal.

The strand number selects which of the 12 words of that core are to be channeled back to the sense amplifiers inside the AGC. Thus, the address and control signals are pulses that select and set cores, then reset them to cause the core to send pulses back to the sense amplifiers.

The core rope simulator boxes we are restoring do not have actual core rings, nor are they organized into six modules or 12 strands of words or 512 core ring addresses. The box has to interface with the same circuits that normally set, reset and select core rings, which it does by using small transformers that electrically act like the cores.

While the core rope modules are organized into six modules, 512 core rings, 12 strands and 16 bits to the sense amplifiers, the actual memory address inside the AGC is a linear range of 36K continguous word addresses. The external system connected to the core rope simulator boxes also sees a linear range of 36K contiguous word addresses, not modules, strands and cores.

Thus, the core rope simulator box accepts pulses from the AGC that would, in real core rope modules, set or reset a core ring at specific times. It has to save those module, strand and core addresses from the six sets of pins where the six real modules plug in. It will convert the addresses back to the linear range and send that address out to the external system.

The external system looks up the contents of the linear range address it received over the thick cable and sends that word back to the core rope simulator boxes. The box will then take the 16 bit value and use it to generate signal pulses via transformers that will look, to the sense amplifiers in the AGC, just like a pulse that was generated by a real core ring resetting.

We received the core rope simulator boxes with the AGC, but did not have any documentation at all about them. No schematics, no diagrams, no description of how they worked. Worse, we didn't have the ground based external system or the thick cables that run between external system and core rope simulator modules.

Ken had to reverse engineer the two boxes, understand their operation and build schematics. He then had to design and build an external system that would connect via thick cables and work properly with the simulator boxes. It had to recognize the linear address coming from the boxes, interact with the control signals at the right time, and feed the desired word of data back to the simulator boxes in time for them to pass the data into the AGC.

The external system is built around a Beaglebone and a custom printed circuit card, makes use of the same 85 pin aerospace connectors that are on the outside of the core rope simulator boxes, and will allow us to hold onboard all of the known versions of Apollo software, so that we can select which version is active to the AGC. For example, we can pick Luminary 210 which is the software that flew in the LM on Apollo 11.

DSKY closed up and ready for testing with a purpose built test rig

DSKY SUBSTITUTE FOR THE APOLLO GUIDANCE COMPUTER

Assembly

After detailed examination of the space available inside the DSKY enclosure, I decided that there was insufficient space to arrange the power board - boost converter, relay and EL driver module - without compromising the remaining components. I therefore decided to mount this board externally, on the outside bottom of the enclosure.

I was ready to assemble when I detected that one lead of the cable to the EL wire had broken loose. That needed to be repaired before I could install the display board with all its cabling. It was soon fixed.

The display PCB was screwed into place inside the enclosure. I did the epoxy gluing of the light dam over the PCB, then worked on covers and panels to get them glued together and onto the faceplate. Now that everything fits together nicely, I can put on the front screws and some mounting standoffs on the  bottom of the enclosure, to complete the physical construction.

Testing

I had designed a test fixture driven by an Arduino Uno, leveraging 24 relays and other circuitry to act in place of the Apollo Guidance Computer, sending control signals to the DSKY and receiving the results of operator keypresses. I had to wire this up and set up a triple power supply with 5V, 14V and 28V sources that are required by the DSKY substitute.

A real DSKY would have 28V and 14V, as well as 115V 400Hz AC, but not 5V. That last voltage is needed to power my modern components inside the DSKY substitute. The 115V supply illuminates bulbs under the keycaps of the real DSKY, but is not used on my implementation.

I began wiring together the relays in the text fixture and connecting it to the DSKY cables. 

Refining the incandescent simulation: measuring the real bulb behavior

Refining incandescent simulation

I set up the Arduino to attempt to produce 32 steps of illumination for the incandescent bulb, simultaneously setting the LED to the same step number. Each would illuminate for 2 seconds, giving me time to compare both brightness and color of the two light sources, side by side.

On my first try, I didn't get great results. My method of driving the bulb was too crude - X milliseconds on followed by Y milliseconds off, for example 2 on and 3 off. Clearly this didn't work well. Also, I could see that my LED, even at half brightness level, was noticeably brighter than the real incandescent bulb at its maximum brightness.

I adjusted the spreadsheet to produce the exponential curve across 32 steps from 0 to 100% on at a max brightness level of 15% of the LEDs maximum. . I did an abbreviated test with the LED and the bulb both full on. It looked roughly identical, but I will use a phototransistor to measure more accurately later.

With the top of the curve set, I needed a better ratio between turn-on and turn-off time of the filament. Too, if I can refine the shape of the curve as it turns on or turns off, that will make the LED levels even more realistic.

My existing measurement tools weren't working - the original photosensor board with its ADC is too slow to sample the bulb and even at slo-mo speed with the iPhone video, I don't have enough resolution. Too, judging brightness in video frames is hard. Ken Shirriff suggested using a phototransistor connected to a scope, where I could capture and freeze the curves, getting good speed and brightness percentages.

I bought one and continued the testing with the simple cases of bloom from full off to full on, and with fade from full on to full off. These gave me a very nice exponential curve for the fade - taking about 300 ms to fade completely.

Phototransistor trace (inverted illumination level in blue) for switching off the bulb

The trace for the bloom of a bulb from cold to a full on illumination was less ideal. While you can roughly fit the data points to an exponential curve of shorter duration, perhaps 100 ms maximum, the shape is distorted by reversals in direction.

I looked for the cause of this distorted shape, thinking about flaws in my experimental method, the possibility that illumination of a filament exhibits very complex physics, and the nature of the IBM lighting circuit driving the bulb.

The bulb is powered by 7.5 VAC connected through a Silicon Controlled Rectifier (SCR) and the bulb. This means that the SCR will only conduct on the positive half cycle of the AC and switches on when the input lead is above a threshold and the instantaneous AC voltage is above the diode junction voltage drop.

This means that even with a full-on logic signal applied to the SCR input, the bulb will see a varying positive voltage over approximately 8.35 ms, with a slightly longer period of zero voltage as the AC swings down and through the negative half cycle. Since power changes as the square of voltage, there is a dramatic oscillation of power through the filament.

When I looked at a shorter timescale I could see that the reversals or irregularities in the trace do appear to fit a 16.7 ms cycle time. Thus I have to conclude that the console lamps of IBM 1130 and 360 systems will turn on with the odd illumination pattern seen in my scope capture.

Turn-on of filament with shorter timescale seems to match the 16.7 ms period of 60Hz AC

My simulation of turn-on would need to be quite a bit more complicated than a simple exponential curve to capture this effect. Whether that is necessary to fool the human eye and brain is an open question, but I will build the initial implementation with solely exponential timing.

Working on installation of the IBM 1130 light panel using LEDs to simulate incandescent bulbs

Wiring and assembly of power supply

I have the two filter capacitors mounted on the swing down rear door, along with the bridge rectifier module. Next I assembled the two buck converter boards onto the laser cut adapter plates I made. These were also mounted on the door.

I did discover that the filter capacitors were too tall to fit in the orientation I expected, but if I swing them 90 degrees they could be oriented in the long (width) direction of the enclosure and fit properly. I did some test fitting of the adapter plates and components until I was satisfied with their fit.

Components of power supply in place across rear door of panel enclosure

With all of these installed in place I could finalize the lengths of the wiring and begin wiring them together. These are soldered in some places such as the PCBs, attached with lugs onto screw terminals in others, and inserted into screw tightened terminal blocks for the remaining connections.

The use of lugs permits removal of the PCB along with the harness and supports replacement of any modules that may fail in the future. I made use of color coded wiring - black for ground, yellow for 7.5VAC, blue for rectified unregulated voltage, green for 3.3VDC and red for 5VDC. A white wire connects the Lamp Test voltage from the computer to the signal input pin on my PCB.

After completing most of the wiring harness, when I was ready to solder the last few connections, my Weller soldering station expired. Something went wrong in the tip (PES51) and the station is dead in the water. Replacement coming later this week, thus will continue wiring power supply at that time.

Physical construction work for IBM 1130 console display panel alternative lighting

Mounting the power supply components

I have four components to the power supply for the panel, three of which can be mounted with a screw onto the posts conveniently provided on the swing-down rear door of the panel enclosure. None of the holes in the components line up well with the posts. The fourth component is a fairly large filter capacitor, a cylinder shape without mounting points of its own.

The classic method to mount the filter capacitor would be a clamp that circles the capacitor and provides screw holes. The cylinder would project upwards from the door, the axis of the cylinder at right angles to the door, way too tall to fit inside the relatively shallow enclosure. Instead I want a mount that places the axis of the cylinder parallel to the rear door, so that the capacitor projects outward only by a bit more than its diameter.

The challenge will be fitting everything between the board and the swing door. There is a bit less than 2" clearance from the back of the PCB to the swing door, but the posts and a raised lower ridge on the door eat into the space by up to 5/8".

Assuming that I can fit the capacitor between posts, a clamp can be attached to one of the posts to secure it in place. These are 1 3/4" diameter capacitors, which can be mounted with a bracket that I just ordered from Digikey. These should just fit. In a few days I will have the hardware here and can mount the capacitors onto their final position on the swing door.

Filter capacitors used for power supply

The two buck converters needed adapter plates since neither of them have mounting holes that directly match the posts on the rear swinging door of the 1130 enclosure. I am having the adapters laser cut at Ponoko out of 1/16" plastic.

Interfacing with the computer wiring system involves connection to the 7.5VAC main lighting power, ground and the 155 discrete signals for 154 lights and the lamp test control. There is a terminal strip on the left side of the enclosure (viewed from the front) which provides the 7.5V on the top two lugs, common ground on the middle two lugs, and lamp test signal on the bottom two lugs.

The way that IBM designed the 1130 computer, they have a 7.5V AC transformer wired with one side tied to ground, so that the other side swings to both positive and negative excursions during every cycle. This does present problems with my initial power supply design, which was going to use a full wave bridge rectifier to give me DC for the buck converter boards. However, if one side of the input is tied to the negative output, the full wave design won't work properly.

AC feed tying one side of transformer to ground

Supply connections inside light panel enclosure

Instead, I must use it as a single diode of the component to rectify, producing only positive half cycles. This requires a filter capacitor to smooth out the more substantial ripple I will be experiencing.  I selected 9000 uf caps for the output of the rectifier diode and again for the output of the 5V buck converter.

To attach properly to the barrier strip inside the 1130 enclosure that provides the 7.5VAC, ground and lamp test signals, I have to create wires with lug ends to fit on the strip. My wire has to be bigger than 20 gauge (or two somewhat smaller wires, each attached to a barrier strip terminal) to properly carry the max current. I chose 18 gauge stranded wire.

The lamp test wire can be much thinner, since I am simply detecting the voltage level with a PCA9505 multiplexer chip. I do need to put a push-on connector for the lamp test to fit it over the pin on my PCB for this connection.

The power connections are flat solder plates thus only one end of the ground wire needs a lug end. The other solder plates run to the buck converter boards supplying 3.3 and 5 VDC. A lug plate is needed on the wire to provide the AC to the rectifier diode. The two filter capacitors need lugs on one end of the wires connecting them to the rectifier and the buck board, otherwise connections are soldered.

Since I must wait for the adapter plates to mount the two buck converter boards, I figured I could complete everything else and wait for the final physical assembly when they arrive next week. I installed the rectifier and two capacitors along the swinging rear door, but left the two converter boards dangling so they can be screwed onto the plates later.

Adding insulation and support material to the rear of the panel

The honeycomb behind the front panel is actually a number of blocks that are glued together and then anchored to the face plate by two threaded studs rising along the mid-line of the face plate. A metal plate extends across the mid-line and is held in place with two screws.

The PCB has solder mask and no components along the line where it will sit atop the metal plate and screws, but with time the screw heads may dig into the solder mask and eventually short. Further, since the PCB is planar but the screw heads make elevated points on the rear of the honeycomb, the PCB wobbles and won't sit flat.

My solution is to overlay the metal plate and screws with a long narrow foam strip. Small pieces of the foam will be applied at various points on the rear of the honeycomb to cumulatively provide a planar support onto which the PCB can rest.

Padding/insulation between honeycomb face and PCB face

Minor repairs to the IBM panel before installation

The IBM panel is a plastic front with honeycomb segments glued to its rear. Two plastic blocks are glued to the sides of the honeycomb outside edges. These are screwed onto vertical metal brackets to hold the light panel in place inside the enclosure. Both of the plastic blocks have broken free from the honeycombs due to deterioration of the glue used for manufacturing at IBM.

Edges of honeycomb where plastic blocks detached due to adhesive failure

 The bracket is attached to the top and bottom of the enclosure and has two screw holes facing sideways into the plastic blocks. However, getting a screwdriver in the enclosure to install or remove those two screws is quite difficult.

Plastic block attached to its bracket

The only effective method is removing the two end switch panels to get access. These metal plates have threaded studs on the rear that fit into an enclosure hole and are tightened with a nut you can reach from the rear. I have to remove the 4 nuts and swing the two plates out of the way, allowing me to put a stubby screwdriver in from the front and access the screw holes for the plastic blocks.

Re-gluing the plastic blocks to the honeycomb sides using epoxy

After removing both plastic blocks, I used epoxy to glue them onto the honeycomb sides. Once this was firmly set, and the standoff insulation applied to the honeycomb rear faces, it was time to reinstall the honeycomb.

Light profile tweaking for IBM 1130 console replacement display

Improving the incandescent simulation

I chose to wire up one of the incandescent lamps from the 1130 and subject it to testing, using both direct visual comparison and a light sensor to record the brightness over time. I picked up a TSL2591 light sensor module from Adafruit, which operates over an I2C link to an Arduino. I configured it to record the intensity of the light as ran the lamp through its paces.

1. Turn the lamp full on from a cold condition, recording the brightness curve
2. Turn the lamp off from a fully on condition, recording the brightness curve
3. Iterate with 1 to 60 half-cycles of power out of each second, at a steady state
4. for each state above, record the brightness
5. For each of the states, adjust the color of a Neopixel until they subjectively match
6. (optional) Test that the incandescent performs the same whether the on half-waves are contiguous or spaced throughout the second; verify that the only factor is number of on half-waves

The incandescent lamps are installed onto long narrow PCBs that host the SCRs used with the IBM lighting circuit. They are all soldered to a common wiring harness, thus I will be powering all 154 lamp positions in this test, but only energizing one of them.

The boards receive common voltages of .ground reference, 7.5VAC and lamp test state. The lamp test state biases the gate of the SCR thru an internal 6.8K resistor in each SCR package. The logic signal that controls the gate is fed through a 6.2K resistor external to the lighting PCB.

This set of resistors forms a voltage divider delivering 52.4% of the signal voltage to the gate of the SCR. It is built that way because when Lamp Test is desired, the voltage on that rail is +3V, thus even with a logic signal that is off (0V), the resulting voltage divider delivers about 48% of the 3V on level.

Thus, with the Lamp Test rail held at ground, all logic signals are either 0V or 1.572V at the gate due to the voltage divider action, but when the Lamp Test rail is pulled up to 3V, all gates are either at 1.44V or 3V depending on the logic signal state. This ensures that all bulbs fire when LT is on.

I only need to connect the 7.5VAC wall-wart transformer to the 7.5V and ground reference terminals of the lamp boards, while tying the LT rail to ground. Then, if I apply a voltage level above about 2V to the input pin of any SCR, it should fire the attached bulb. My Arduino provides the 'logic signal' to control the SCR.

My test circuit to drive IBM incandescent lamp boards

My first runs were with the naked eye (and video of the bulb). These do allow me to figure out the bloom and fade time of the bulbs. Capturing video on my iPhone and trying to time it, the speed of the fade is noticeably slower than the time to bloom on. That makes sense, as the filament has to lose heat primarily by radiation in order to cool back down, while turn-on involves the increase in resistance as the bulb turns on. The surge in current causes relatively rapid heating.

I wanted to hook up the sensor board and record the actual brightness curves to get a more accurate view. I quickly discovered that the Adafruit TSL9251 board is far too slow to capture enough slices during the bloom and fade. It appears to take about 100ms, reducing me to a slice each 1/10th second in a process that may be complete in less than a slice for bloom and just over two for fade. Not a big loss at $7 for the board.

The outcome of this testing was intended to produce a table of the brightness and color for all 31 levels, from 0 to 30 half-wave cycles on per second. Further, I had the brightness curves for a full turnon and a full turnoff to compare against the values of the 31 levels.

With the maximum brightness of the LEDs dialed down, so too the current consumption dropped. The Arduino testing, with all positions lit to full on state, drew under 3A total. This is a side effect, although the power supply is capable of driving full white brightness of all LEDs.

At this point I have some design decisions to make. I can cheat a bit since lamps which have a mix of logic states applied during a second might be matched to the average brightness and color of that average value. Thus, for lights that are flickering, I would get a realistic appearance this way. However, this won't work for rapidly brightening or fading lamps, particularly the edge cases of full on to off or full off to on.

I am toying with changes to the algorithm, such as taking dimming steps of the index value 3.5 times slower than brightening steps. This would adjust for the differences in bloom and fade speed of the filament. If I sample the logic states 38 times per second, then I can step up the index value for brightness 7 levels when the logic level is true and step down 2 when the logic level is false. That gives me a full bloom of about .13 seconds and a full fade of about .42 seconds.

The other change I have to make is in the color of each level. I am going to drive the incandescent to roughly 32 steps of brightness from off to on, then use the Arduino to tweak the LED color and brightness to match by eye. This is going to be a bit more complicated test setup, but I should be able to complete this by the end of this week.