Early Projects

Programmable Color Beam Theory of Operation User Controls White Balance By Software By Hardware Dynamic Response Correction (equalization) Experimentation Lighting an LED with PWM Notes and findings Multiplexed Keyboard and Display Considerations Serial Interface to the outside World References RGB Color fading algorithm Final Implementation

Content

These are small, mostly test projects, completed during my newbie phase with Arduino.

A light beam produced by three LEDs (Red, Green, Blue) is manipulated by the user with the aide of a few knobs and buttons, to obtain any possible color. Results can be stored in memory banks for instant retrieval .

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.

Because I am new to Arduino, I wanted to go slowly, step by step, one challenge at the time. This section contains unit tests made prior the application per se.


/*  Fading LED in a loop, speed set with a potentiometer.
*  This test involves A/D conversion and PWM
*/

int ledPin = 6;     // LED connected to D6 (pin #9)
int analogPin = 1;  // Potentiometer connected to A1 (pin #20)
int pot;            // Value read from potentiometer

void setup() {
  pinMode(ledPin, OUTPUT);      // sets the pin as output
  pot = analogRead(analogPin);  // read the analog input pin on startup.
}

void loop() {  
    
  /**
   *   Fading LED back and forth continuously
   */
  int i=0, maxval = 255;

  /** Scale **/
  int wait = pot / 4;

  /** Fade Up **/
  for(i=0;i < maxval; i++){
     delay(wait);
     analogWrite(ledPin, i);
  }

  /** Fade down **/
  for(i=maxval ; i>0; i--){
    delay(wait);
    analogWrite(ledPin, i);
  }
}


First argument in functions analogRead() and analogWrite() is the number in the pin name , not the chip pin number. For example, for pin D6 (chip pin #9) we must use:

    analogWrite(6, value); // 6 for D6, not 9 for pin#9...

The function analogWrite() will accept values greater than 255 but the result will not be as expected. So always make sure second argument will not exceed 255.

This application requires about 8 buttons and 8 LEDs plus 3 PWM outputs for a total of 19 digital pins. This count is greater than the 10 pins available in the board. Consequently, multiplexing is imperative.

Some ideas to be considered (or discarded).

Values R,G,B are hidden to the user. What if we overwrite by mistake a memory bank containing a lovely color? How can be recover from that "disaster"?

We could implement some kind of Console interface via Serial Port to read and set R,G,B values by the mean of a an external PC running a terminal emulation program.

We could even provide Remote Control capabilities via Serial Port. Say for instance that we have several panels (not just canons) illuminating different walls and we want to "paint" the walls differently according to a schedule. The "scheduler" can run at an Automation PC connected to different "systems" via serial ports.

This program in javascript demonstrates an algorithm for nicely fading an RGB color. The last two or three lines call jQuery functions that are irrelevant to my purposes.

Reference:

This section describes the device actually built.

[ ... pending ... ]