next topic »

[on:]

This is the second mood lamp, I've created. The technical part is very similar to the first one (Lacam Lamp 2.0). But this time I used 48 RGB-LEDs in one strip cutted into 6 pieces. So I have a 6 columns by 8 rows matrix to play with.
In fact that I used a diffuse plastic orb from a garden lamp, I had to change some things for the effects running on the lamp. The problem is, that the distance from the LEDs to the inner side of the orb is not the same for all LEDs (depending on the number of the LED's row). Additionally the distance is to big to create single spots on the orb. The colors are mixing, so I have to use "blocks" of LEDs with the same of similar colors.

The most interresting mode is the "color cloud", having some color shapes moving around on the sourface of the orb. At the moment the movement is a little bit static and the code needs some optimiziation, cause calculating HVS to RGB data for every LED on every frame takes too much time (cause it uses a lot of float operations). Maybe I find a better way dealing directly with the RGB data in the LED-Strip datastructure.

Using 48 instead of only 20 LEDs makes the whole thing much brighter, so I added a third knob to control brightness in most of the modes.

At the moment the lamp is driven by a 5V / 2A powersupply that runs in problems if I turn all 48 LEDs to 100% white, but 90% is OK. So I assume that the lamp takes a little bit more than the 2A. In the next days my new 5V / 3A powersupply should arrive and this problem should be solved. So we talk about 12 or 13 watt for 100% white light, which is bright enough to enlight our living room with 4m by 5m. In other modes then "white bulb" the lamp takes less then 10 watt.

[Reply #1 on:]

Hi mkl0815,

nice work man, try it with the plasma @Skorn showed here: http://arduino.cc/forum/index.php/topic,151306.0.html   (very easy to adapt, but you have to slow it down...)

Please, do the next video in a dark environment, than we can enjoy more of the colors.

Cheers.

[Reply #2 on:]

calculating HVS to RGB data for every LED on every frame takes too much time (cause it uses a lot of float operations). Maybe I find a better way dealing directly with the RGB data in the LED-Strip datastructure.

You can do it with integers and look-up tables. Google "integer hsv to rgb".

[Reply #3 on:]

nice work man, try it with the plasma @Skorn showed here: http://arduino.cc/forum/index.php/topic,151306.0.html   (very easy to adapt, but you have to slow it down...)

Please, do the next video in a dark environment, than we can enjoy more of the colors.

Thanks Helmuth, for the flowers 
I already tried some plasma effects and the fire simulation from this thread. But the distance from the LEDs to the surface of the orb is to big to have a smooth and valid animation. I also tried with one of the acrylic glass cylinders from my first lamp, but even for this the distance was to big.
For the next project I will use a bigger tube inside the cylinder and also use 8 instead of 4 or 6 columns. This will end up in a at least 8 by 8 or 8 by 10 matrix. The LEDs will be more compact on the surface of the tube they are mounted on, so I hope this will be better for such cool animations with plasma, fire etc.

@fungus: Thanks for the tip. I will give it a try on my next project. The fastest solution would be a 255 values precalculated hue table with the according RGB data, causing 765 bytes in progmem.

[Reply #4 on:]

Hi guys,

nobody could explain me yet, what´s the advantage of dealing with the HSV model except for scrolling rainbows... So I ask here again: why?

@mkl0815: If you care about too much data in the RAM you could think about a gamma correction / logarithmic correction table which comes with reducing the resolution. The upper part of the 8 Bit is practically useless...so why not correct it logarithical and have it adjusted to the real sensivity of the human eye, reduce it to 7 Bit and save the half of the RAM, if you seriously want to precalculate it...(i see no valid reason for that when using complete integer math)

[Reply #5 on:]

The HSV model is easy to use if you want to address colors of the HSV-color wheel, like rainbow effects. You can simplify the conversation by setting value and saturation to fixed value (normally 1). The bad thing in doing this is, that you reduce the possible 16,7 mio colors to 256 colors, what is still good enough for the most effects. The good thing is, that you only have to deal with one value : "hue" to represent all needed colors.
To address colors directly I agree that it's better to use the RGB model.

For the next project I will give the integer calculations a try. But for now I can live with the solution I have, cause the orb is a birthday present and time is not my "friend" at the moment  , cause there are still some mechanical problems to solve to make it a "good" present.

[Reply #6 on:]

Great !

[Reply #7 on:]

The bad thing in doing this is, that you reduce the possible 16,7 mio colors to 256 colors, what is still good enough for the most effects.

Not necessarily. I did a mood lamp where the hue went from 0x000 to 0x5ff.

This range maps nicely to the hue 'wheel' (each segment of the wheel has exactly 256 values) and conversion to RGB is fast on an 8-bit CPU.

[Reply #8 on:]

That sounds great. Would you share the code for that? It would really improve the rainibow-effects for the several light projects I'm working on.
Mario.

[Reply #9 on:]

I continue to love this project ....