Tuesday, July 28, 2009

AtmoLight Clone

For quite some time i thought about building a Philips Ambilight Clone, but all the current projects were not flexible enough for my taste and used special microcontrollers and boards.
So i thought how can i build one with standard components as a near plug and play solution?

my main points for this project were:
building a ambilight like system using the atmolight protocol
with the possiblity to switch to another protocol without to much work
using small but fine stepped led controlers in a flexible structure (with the option to add n more)

after some research my choices went to the arduino duemillanove and the macetech shiftbars.
the arduino can do pretty much everything and in the combination with the shiftbrite shields and the shiftbars it's really just plug and play.



The AtmoLight system
(some technical information)

How to build your own AtmoLight setup
(this post includes all the sources for the hardware and software)

How to setup videolan (VLC) to use Atmolight

I setup a 3 channel installation behind my computer display as a proof of concept and i must say it looks pretty nice.

AtmoLight

The Atmolight system and protocol
The free atmolight system was designed to drive 4 channels with ether LED strips or coloured cold cathode tubes. They are using a specially designed controller board which has the microcontroller, all the power and the PWM stuff on it.


So all the lights are connected to this one board and one serial or usb connection will go to the pc which will provide the data.
the idea is not so bad and it is actually not too expensive, but you need to get the board, all the other parts, solder everything, program the microcontroller and then you are good to go. (if it works)
too much work for my taste, but will come to this again later ...

The serial Protocol - Now it gets interessting ...

Until now i'm just using the main colour value data, which is streamed over the serial port.

When you are using the AtmoWin App or the atmolight module in videolan, the standard packet layout will by like this.

0
0xFF: Startbyte
1
0x00: Startchannel (low byte)
2
0x00: Startchannel (high byte)
3
0x0F: how much channels (15 = 5 * 3 (R, G, B)) = what if have seen, it's always 0x0F
4 - 6
sum channel R, G, B (Center)
7 - 9
left channel R, G, B (Left)
10 - 12
right channel R, G, B (Right)
13 - 15
top channel R, G, B (Top)
16 - 18
bottom channel R, G, B (Bottom)

for example:
0xff 00 00 0f aa aa 11 aa aa 11 aa aa 11 aa aa 11 aa aa 11 (all channels will have the values R=170,G=170,B=17)

There is a control command to adjust the brightness, contrast, gamma, gamma for each channel and the whitebalance directly within the mikrocontroller code.

Whitebalance adjust command
Byte Beschreibung
0 0xFF: Startbyte
1 0x00: Startchannel (low byte)
2 0x00: Startchannel (high byte)
3 101: Triggerbyte / commandbyte for WB adjust
4 brightness
5 - 7 contrast R, G, B
8 - 10 gamma R, G, B
11 global contrast
12 write command / write to eeprom

note: each colour change will be a full packet ... when you are using the AtmoWin app in fixed color mode, it will send the packet only at startup or a mode change

also note: videolan and atmowin allows to change the order of the channels, just try to remembder it ... i did a hardcoded channel order in my code, to assign the channels to the different led bars. ... needed to do this, because i currently have two led bars for each of the three channels i'm using

Light Value transformation

The atmolight guys using a gamma table to transform the linear rgb light values to values used by the PWM output modules. It just looks so much better with this on.
I can't really explain why, but someone will know. ... :P ... i just implemented what they did

a very good explanation by Garrett from macetech ...
"The gamma table fixes the problem human eyes have correctly determining brightness of pulsed light. Even though PWM from 0 to 100% duty cycle is accurately changing brightness in a linear way, the eye sees almost no difference between 75% and 100% brightness. So the gamma table uses something like a logarithmic translation; the values will change very slowly at low brightness and very quickly at high brightness."


this is the table they are using ... 255 Values over a range of 0 - 2047
0;0;0;0;0;0;0;0;0;0;1;1;1;1;1;2;2;2;3;3;4;4;4;5;6;6;7;7;8;9;10;11;11;12;13;14;15;16;18;19;20;
21;23;24;25;27;28;30;31;33;35;37;38;40;42;44;46;48;51;53;55;57;60;62;65;67;70;72;75;78;
81;84;87;90;93;96;99;103;106;109;113;116;120;124;127;131;135;139;143;147;151;156;160;
164;169;173;178;183;187;192;197;202;207;212;217;223;228;233;239;245;250;256;262;268;
274;280;286;292;298;305;311;317;324;331;338;344;351;358;365;373;380;387;395;402;410;
417;425;433;441;449;457;465;474;482;491;499;508;516;525;534;543;552;562;571;580;590;
599;609;619;628;638;648;658;669;679;689;700;710;721;732;743;754;765;776;787;799;810;
822;833;845;857;869;881;893;905;918;930;943;955;968;981;994;1007;1020;1033;1047;
1060;1074;1088;1101;1115;1129;1143;1157;1172;1186;1201;1215;1230;1245;1260;1275;
1290;1305;1321;1336;1352;1367;1383;1399;1415;1431;1448;1464;1480;1497;1514;1530;
1547;1564;1582;1599;1616;1634;1651;1669;1687;1705;1723;1741;1759;1778;1796;1815;
1833;1852;1871;1890;1909;1929;1948;1968;1987;2007;2027;2047

the newer original firmware generates the table on startup, will look at this later and add it to my arduino code ...