Modeling incandescent panel light turn-on and turn-off optical characteristics for computer consoles

Impetus

The incandescent lamps used in period computer consoles, like all filament based lamps, have a distinct behavior as they turn on from a cold off state and as they fade out when switched off. The filament has some thermal inertia and its cold resistance is about 1/15th of its resistance when fully lit.

These facts combine to produce a bloom to full brightness, with a surge of inrush current at switch-on, heating of the filament to full temperature, and the light emission directly related to the temperature of the filament at every instant.

As a first approximation, the turn-on is an exponential curve to full brightness with a characteristic time constant that is based on the mass of the filament. Thus, smaller bulbs used in consoles light up faster than more massive room illumination style lights.

When power is removed from an illuminated incandescent bulb, the filament begins cooling, with the light emitted shrinking in direct relationship to the temperature. Again, the thermal mass of the bulb controls how rapidly it cools. This too, to a first approximation, is an exponential curve whose time constant is controlled by radiative cooling as well as the thermal mass.

Thus, we might have two time constants, one for switch-on and one for switch-off. The human eye and brain recognizes this pattern as the behavior of incandescent bulbs; when instant-on LEDs are substituted the panel does not look the same, a source of slight dissatisfaction for those building replica computers.

A related issue is the color temperature of the filament at each temperature during switch-on and switch-off. The bulb is more reddish-orange at the start and increases emission at higher frequencies as it blooms to full on; correspondingly, the lamp fades from white down to orange-red as it turns off.

The final reality we have to consider is that when a lamp is cooling down, but it is switched back on, it does not start from the fully cold point on its switch-on curve; a lamp that was turning on but not yet at full brightness will fade differently if immediately switched off than a lamp that was stable at full brightness.

Method

To simulate this behavior, we may build a state machine with enough granularity to fool the eye/brain into perceiving an LED as an incandescent bulb. The state machine starts at one 'end', full off, and advances one step per cycle toward the 'on' end if the lamp is being powered, or one step toward the 'off' end if the lamp is unpowered.

This state machine provide RGB color values for each step that match the target color and brightness of the simulated incandescent bulb. The current values are steadily delivered to an RGB LED, thus causing it to follow our intended behavior.

This presumes a single time constant for both turn-on and turn-off. A more sophisticated dual state machine would model both curves independently and as the power state of the simulated lamp is changed, it could set the state machine for one direction to the current brightness/color state from the state machine that was operating in the other direction; by direction, I mean turning on versus turning off. .

Analytic and experimental testing

My first estimate of the time constant for the bulb was that it reached approximately full illumination in about 0.1 seconds thus has an effective exponential constant of perhaps 0.06. Thus, lamp moves through its state machine in about 10 possible steps if I assume I can check lamp state about 100 times per second.

I set up an Arduino to try with step size of 10, actually 11 total between full off and full on, roughly estimating the color shift but with a better approximation of exponential brightness change.

The results were decent for the first try. The turn-on seemed realistic but to my eye, the fade-out seemed quicker than real incandescent filaments. That argues for separate time constants. Intellectually, I can understand that radiating heat away through a vacuum is an entirely different mechanism that has no impact on the bloom during switch-on.

Measuring the optical curve

To determine the characteristics of the lamp we are modeling, I may build a test jig to measure the actual behavior of a sample bulb. It would use a computer controlled switch to provide power to the bulb for various durations, and three photocells with red, green and blue filters, to record the brightness of the red, green and blue light being emitted.

The device would need to sample very rapidly to capture the turn-on and turn-off curves with sufficient granularity. The recorded data would then be analyzed to extract the step size needed and the RGB values for each step. I could hold out hope that the turn-on and turn-off are close enough together to allow for a single state machine to model both.

Programming a state machine

Having the number of steps for the state machine and the desired RGB values to produce allows me to produce VHDL for modeling one lamp. This will be replicated enough times to model all the lamps in the console. I have to be clever in the design to minimize resource consumption. As I don't want to latch 24 bits of RGB for each of 154 lamps as that would take up about 4K flipflops just for storage.

If done with an Arduino or similar processor, an index value equal to the state machine can be incremented or decremented based on the signal state each pass through the main loop. That index selects the pre-computed RGB value to send to the LED. I can apply a similar strategy on an FPGA

Use with individually addressible RGB LEDs

Wiring up a large console with individual RGB chips, hooked up to driver chips, ties up a lot of traces on a PCB and consumes the space needed for the driver chips as well. Having a controller chip built into each LED means that a simple serial line is threaded through a chain of LEDs and can address each one individually.

These exist using a number of different controller chips, such as WS2811, APA106, WS2812, and APA102. Some use a single serial line through all LEDs, while others have separate clock and data lines running through the chain. They come in a variety of brand names, such as NeoPixel and DotStar, as well as generic produces.

These are often manufactured on flexible strips for ease of implementation but the separation between LEDs on the strip rarely matches the computer console lamp spacing desired. Another rarer option is through-hole LEDs with the driver chips built in, but these allow mounting in 5mm or 8mm holes at the exact spacing you may need for a given computer project.

Real world example - IBM 1130 console light replacement with LEDs

The real world implementation of this is a quick project to replace 154 incandescent bulbs inside the console of my IBM 1130 computer. These lights are built into a pedestal that sits above the console printer, approximately 24" wide and 5" high, with the lights arranged in a matrix.

Display panel with 154 incandescent lights

The implementation of the incandescent lights in this console makes replacement of burned out bulbs a very tedious procedure. Rows of up to 16 bulbs are drive by long narrow PCBs which have SCRs installed to drive each light. Pins from the board and SCR are inserted in a nylon socket that has a wire lead incandescent bulb inside.

These 16 sockets must be pressed into a honeycomb structure, but the leads are not right so the sockets are quite difficult to maneuver into the holes at the same time. Six rows of these bulbs are stacked, 3/4" apart vertically, yielding almost no clearance to reach sockets for insertion due to the presence of the adjacent boards/sockets. Getting all 96 bulbs pushed into the honeycomb for this side of the console is enormously hard.

The other side has the remaining 58 bulbs, still stacked six boards vertically but with a bit more room on the side, due to some empty light positions in this part of the console. A bit easier but still tedious.

The rear of those long narrow PCBs have wires with pushpins inserted to deliver the logic state, 3V or ground, to control each of the bulbs. Thus there are 154 wires with pushpins that have to be inserted once the PCBs and sockets are in place.

Original IBM boards and wiring

The way the lamps are illuminated determines the number of illumination states and the behavior as well as defining the sampling rate for the logic gate value. Each logic gate was connected to an SCR which fed 7.5VAC to the lamp. The result was 7.5V DC fed on positive going cycles of the supply. If the logic gate was one when the positive cycle began, the SCR would conduct, otherwise it was off.

This means that 30 times per second, the logic state is sampled and for each time it is on, power is delivered to the lamp. The lamp can have anywhere from 0 to 30 half cycles per second applied. When the processor was running full tilt with bits continually changing but averaging being on half the time, the lamp would be lit at a reduced and more orange level than when the bit was steadily on.

The replacement for this uses a single 17.5" by 4.5" PCB, having 154 RGB LEDs installed in the correct patterns to match the holes in the honeycomb. These LEDs are thru-hole types, 5mm diameter to match the honeycomb hole, but contain an APA106 controller chip embedded in each LED.

Thus, a string of these LEDs are individually addressable on a serial chain using a very simple pattern to deliver 8 bit R, G and B brightness values. A string of 40 LEDs can be refreshed up to 780 times per second, with four parallel strings being used to implement all 154 lamps. I think I only need to refresh them about 120 times a second to avoid flicker.

I looked at two methods of implementing this - a Digilent Cmod S7 which has a Spartan 7 FPGA onboard, or an Arduino Uno microcontroller board. These have pros and cons. The FPGA can handle all the I2C and LED traffic in parallel, as well as all the state machines, but takes more skill to set up. The Arduino is more straightforward to program but limited in memory.

The Arduino solution may need some assembler coding to be space efficient, since 154 lights would chew up almost half the RAM available on the AVR chip just to store the RGB values and state machine indexes if using the provided Neopixel libraries.  I believe I will build this around the Spartan 7 FPGA.

I could model the state machine with 30 steps, controlling the color and brightness exactly, which would take 5 bits to form an index for each of the 154 lamps - that is, use 770 flipflops to hold the index value. Since the FPGA I intend to use has almost 30,000 flipflops available, this is a reasonable approach if the eye can tell the difference between 30 steps and an alternative with fewer.

I completed the schematic after having to build the symbols and pad layout for all the parts. It is simple enough even if a lot of replication was needed. The reasons:

• The APA106 LED includes the controller chip and the load resistor, eliminating the need to place these on the PCB
• The CMOD S7 has all the components for the FPGA, USB programming link and other features such as RAM, all on the board so that I only need to place the 36 pins of the board
• The PCA9505 expander chip does a huge amount on chip
• The layer of connection between the FPGA board and the PCB does the level shifting to 3.3V and implements the 1.6K pullup resistors for the I2C chains. 

That means I only need to place 154 of the APA-106 and arrange them in four serial chains. I place 155 pins on the board and connect them to the four PCA9505 chips. I wire up the LED serial lines and a few control lines from the PCA9505 chips, hooking them to 16 I/O pins on the FPGA. A couple of filter capacitors and two solder pads for power will complete the job. Really quite straightforward.

Routing is sort of easy because the FPGA is thru-hole so I can run lines on the front just to the head LED of the four serial chains, LED to LED short segments link them together, and a single line hooks one line of LED to the next  I organized all the LEDs to match the physical 1130 console. 

On the rear of the PCB I place the 155 pins which hook to the 154 logic signals and the lamp test line. The pins are aligned to the sides of the LEDs (but on the back side).

The 1130 logic gates have a pull up to +3V for the logical 1 state, with the transistor conducting to pull the output down to ground for the logical 0 state. I only have to hook this output to the PCA9505 input pin which will either see nearly 3V or see almost 0V This is well within the specs of the chip to reliably recognize the 1 or 0 state.

I arranged the connections of pins to the PCA9505 chips to allow straight signal runs without many vias. I may even be able to make this with no vias other than the ones that connect leads to +5V and ground.

Competing the routing did require some vias to allow signals to cross, in addition to the power connections, but it all worked out with 6mil width and 6 mil spacing rules. I shipped the board design off the have it fabricated. I should have the board back by the end of the month.

Meanwhile I have been amassing the expander chips, fpga, I/O pins and LEDs which will all be on hand before the board itself arrives. Soldering the 56 pin expander chips down, which fit in about a 1" x 3/8" space, will be a challenge.

I removed the honeycomb from the 1130 and will use it as a jig to align all the LEDs as I solder them down to board.  The resulting assembled PCB and its related power supply module will fit very neatly inside the display enclosure.

3D rendering of board