Ambi/Atmo-Light implementation using ATmega328 micro-controller and WS2812b LED strips
Go to file
King Kévin a4b9f30196 improve description 2015-07-28 14:07:19 +02:00
firmware improve output generation 2015-07-23 10:45:15 +02:00
test-patterns add videos test patterns (generated from pictures using ffmpeg) 2015-07-14 15:51:04 +02:00
README improve description 2015-07-28 14:07:19 +02:00
boblight.conf.rb use usb port in boblight configuration file (more common) 2015-07-23 00:06:25 +02:00
dual_boblight.conf new bobllight configuration files (with right LED order) for single and dual screen 2015-07-23 00:04:43 +02:00
full_boblight.conf use USB UART port rather than RPi GPIO 2015-07-28 14:06:47 +02:00
test.rb replace with fading with nice looking pattern 2015-07-23 00:07:57 +02:00
vlc-amtolight-dump.txt cleaning dump 2015-07-17 12:48:14 +02:00



The CuVoodoo ScreenLight mimics the Philips ambient lighting.
The idea is to have LEDs on the back of the screen, lighting on the sides the same color as the border on the screen, creating an ambient light.


To implement this I used:
- boblight to output over serial the colors to be shown on the LEDs
- an Atmel ATmega328P microcontroller at 16 MHz (i.e. Arduino Nano 3.0) to control the LEDs and show the values received over serial
- A strips of WS2812B chained LEDs (i.e. BlinkyTape), individually controlled using a data line

The BlinkyTape LED strip offers 60 WS2812B LEDs.
To match the 16/9=1.78 aspect ratio of my screen I divided the LED strip in 19 LEDs for top and bottom, and 11 LEDs for the sides, for a close aspect ratio of 19/11=1.73.



This is the microcontroller (e.g. Arduino Nano 3.0) code.
Use `make` to compile and flash it.

`lib/uart.c` allows to talk over serial.
boblight will send the color values over UART (e.g. USB).

`lib/ws2812b` allow to control WS2812B LED strips.
The data transmission is done implemented in assembly since it is time critical
The LED strips are connected in parallel as follows:
- 11 LEDs on pin D2 (PD2) for the top first LED strip
- 08 LEDs on pin D3 (PD3) for the top second LED strip
- 11 LEDs on pin D4 (PD4) for the left LED strip
- 11 LEDs on pin D5 (PD5) for the bottom first LED strip
- 08 LEDs on pin D6 (PD7) for the bottom second LED strip
- 11 LEDs on pin D7 (PD8) for the right LED strip

`main.c` will parse the UART input data for AtmoLight messages and set the LED colors.


To set LED colors send AtmoLight messages for the 60 RGB LEDs (aka. channels), at a baudrate of 115200 bps 8N1.

AtmoLight messages have the following format:
- fixed atmolight header: ff 00 00
- number of bytes: one byte (3 RGB * 60 LEDs)
- LED 0 color: 3 bytes (RGB)
- LED n color
- ...


`test.rb` will connect to the microcontroller and run standard tests to see if all is working.

`boblight.conf.rb` will generate the boblight configuration file for my LED installation:
- LEDs: 60 LEDs
- channels: 180 (60*3)
- protocol: AtmoLight
- port: /dev/ttyUSB0
- speed: 115200 bps
- LED arrangement (with LED numbers and number of LEDs):     
  18---11 00----10
29   9       11   59
|     screen       |
| 11            11 |
|     (front)      |
19   11       9   49
  30----40 49---41


Two other implementations are available in branches.


AtmoLight offers a simple solution, but only has 4 channels: top, bottom, left, right.
Each channel correspond to an LED strip, but all LED on the strip will show the same color.
This is a waste of the individually controllable WS2812B LEDs, but it works fine.

This implementation also uses the AtmoLight protocol, with a serial baudrate 38400 8N1.
The standard AtmoLight message offers 5 channels: summary, left, right, top, bottom


VLC supports other device type in the AtmoLight video filter, such as fnordlicht.
The device type fnordlicht allows to control up to 254 channels (RGB LEDs).
This fits better the WS2812B capabilities.
Sadly VLC only supports up to 16 channels per zone (top,left,bottom,right).
Thus this used 50 from the 60 LEDs (16+9+16+9).
And because of the slow baudrate (19200 bps) and expensive messages (15 bytes per LED) this only allows a refresh rate of 2 fps.


The firmware might miss the first packet of the communication while booting.
But this will automatically be corrected after some short time though since the firmware synchronizes on the AtmoLight message header.

In the current WS2812B implementation setting an LED color requires 36 us.
Outputting the data to the WS2812B strips requires 48 us for a single LED on all pins/strips in parallel.
For 11 LEDs per strip it requires 348 us.

I use AtmoLight protocol with a baud rate of 115200 bps 8N1.
Thus receiving one byte requires 1.0s/(115200bps/(8+1)bits) = 78 us.
This leaves enough time to set the colors of an LED.
But this does not leaves enough time to output the WS2812B data, particularly since this code is not interruptible.
Thus you should wait ~ 0.4 ms before sending a new AtmoLight message.
Else transmitted bytes will be lost, and the code will sync to the next message.

The maximum refresh rate is 115200bps / (8+1)bits/byte / (4 header bytes + 3 bytes/LED * 60 LEDs) = 69 fps.
To avoid dropping AtmoLight messages prefer a refresh rate <= 60 fps.

AtmoLight protocol:
WS2812B LEDs: