Monday, January 31, 2011

Project 8 - RGB Mood Lamp

Project 8 was fairly straightforward... three LEDs will have their brightness and color mixed randomly to create other colors. I wired it up on the mini-breadboard that I stuck to the MakerShield... in a few of the photos you may see the GND wire (orange) moving from place to place as I test additional solder joints to make sure the various GND posts are working.

I didn't post a screen capture of the code here - I used the author's code with no modifications required.

I didn't get quite the results that the author achieved... either my LEDs are too bright (or not bright enough in some instances) or the incremental changes are just too difficult to see. Using a white piece of paper to diffuse the colors worked occasionally, but most of the time it was difficult to see any difference.

Still, I understand the code and how it works... this would be one crazy expensive mood lamp, however, if I chose to use an Arduino and 3 LEDs to make something like this!

8 comments:

I was wondering if you were going to see the same behavior I saw. Sounds like you did.

I used a single RGB LED and found that the light would stay the same color for a LONG time, then rapidly cycle through shades of red, green and blue. I let it run for a few days out in the shop and checked on it a few times a day while I was doing other things.

I added some Serial.print commands to send a log of the red, green and blue PWM values to a serial monitor window.

Then I put a trio of DMMs (you can never have too many meters) on each of the anode leads so I could compare the mean voltage to the PWM values.

From observing the changes on the DMMs, and just watching the light, I thought that the board was locking up somehow, but then looking through the serial monitor log, I could see that the program was running because the length of the string of PWM values sent to the terminal monitor window kept growing even when the value was not changing.

I have not figured out WHY the values would repeatedly stay the same, but I think it is related to the constrain statement in the last function which I believe forces the lamp to favor primary and secondary colors over pastel shades.

Good to know that my eyes weren't deceiving me... it really didn't look like much of a mood lamp! I tried different LED types, too, but that didn't change the fact that the shifting of colors was almost unnoticeable.

Makes me wonder of the pseudo random generation may be partly to blame...

I remained bothered by what you observed, "...that the shifting of the colors was almost unnoticeable."

Understanding flashed on me at about 1:00 A.M. last night and since I had today off, I was free to indulge in working through it.

The code sets a range for the PWM values for each lamp color, bounded by RGB1[x] and RGB2[x]. RBG1[x] starts at 0. RGB2[x] begins as a random value between 0 and 255.

The code then divides the range of the values by 256 {INC[x] = (RGB1[x]-RGB2[x]) / 256; }

It then subtracts the INC[x] value from the the RGB1[x] value and casts the result into an int which is the PWM state sent to the relevant output pin. It repeats this iterative process 256 times, at the end of which the RGB1[x] values are very nearly the same as the RGB2[x] values.

It then resets the RGB2 value to something new, recalculates the value of INC, and again subtracts it from RGB1 in 256 steps until the values are again the same.

Here's the part that causes the colors to appear to freeze.

There is a 53% chance

RGB2[x] =random(556)-300; RGB2[x] =constrain(RBG2[x], 0, 255);

that RGB2[x] is going to come up 0 for each of the three channels, and while I can't, offhand perform the probability calculation, I can see that the chances are good that RGB[1] will end up being zero (because it chased RGB2[x] to zero in the last pass through the loop), and ends up again chasing RGB2[x] from zero to zero in steps of INC[x], which would also be zero.

In other words there is a substantial likelihood that 2 of the LEDs are off while the third passes through a very narrow range of values, say from 240.73 to 250.64, in 256 steps. Since there are only ten integer steps from 240 to 250, the PWM value will sit at each of those integer values for 25 steps through the loop and the color change will be nearly imperceptible.

I was frustrated with this one, but now that I've worked it out, I think, pedagogically, it is a masterpiece.

Sorry to clutter up your blog with this, but I couldn't think of a better place to expose it to public ridicule.