Table of Content  Branch Up  

Theory of Operation

A light canon is made to produce a colored beam with three LEDs of primary colors red, green and blue (RGB) in close proximity. The LEDs are fed separately with PWM square waves which duty cycle governs the light intensity.

Values for light intensity is manipulated by software by maintaining three 8-bits variables R, G and B.

We want to provide as fewer controls as possible without scarifying convenience. The idea (for now) is to have 8 buttons each of them having its own indicator LED on top, and two knobs.

Buttons are the following:

R, G, B: Pressing any of these causes the beam to illuminate at saturated Red, Green, Blue respectively, or any combination of the three. In particular, having all three activated causes the beam to illuminate white.

CTL: Pressing this button causes the device to enter "control mode" where the knobs become active. Otherwise, moving the knobs have no effect.

1, 2, 3, 4: These are memory banks to store (and retrieve) user colors.

Knobs are the following:

HUE: Moving this knob while the device is in "control mode" varies the color of the beam by varying the duty cycle of the pulses feeding the LEDs according to a certain algorithm (see "RGB Color fading algorithm" in section "References").

LUM: Moving this know while the device is in "control mode" varies the brightness within the current color. This is done by varying all three R, G, B duty cycles in equal amount.

Operations such as storing and retrieving colors must be accommodated into this small set of controls.

In theory, having the three LEDs at full intensity must produce a perfect white beam. In practice that is not true in most cases due to physical factors.

To overcome this problem, we need to perform a "white balance" adjustment. This consists of making corrections to the maximum brightness of each LED so they produce a real white (or closed to it) when set to their saturated values.

White balance adjustment can be done either by Software or by Hardware.

For small systems (a single light canon as we have been discussing so far), software white balance adjustment could prove more convenient because it simplifies the circuitry.

It is done by establishing upper limits for variables R, G, and B (that is less than 255) in software. Once these limits have been set, the program will never attempt to set values beyond those so saturated R, G and B will result in an acceptable white beam.

White balance adjustment must be done using the controls available to the user. The exact procedure has not been designed yet.

For large systems, an analog approach may prove better. Imagine a scenario in which a single "control module" is sending three PWM signals (R,G,B) to various (possibly large) LED modules in a daisy chain fashion.

In this case, white balance is done separately in each module by varying the current supplied to each triad when receiving signals of maximum value (maximum duty cycle). Possibly three pots per module are employed to make the adjustment, one per color (RGB).

NOTE:
-----
Actually, "maximun duty cycle" means DC. So white balance can be done in LED modules individually whithout having to be connected to the "controller board". Maybe, by actuating switch labeled "White" inputs get fed with DC so the adjustment can be done in this conditions.

Not sure about this yet, but I suspect that, when feeding an LED with PWM, the relation between duty cycle and luminosity is not linear. It must be a way to measure that relation and make the appropriate corrections in code... this will be interesting.