Adalight support in Boblight via Atmolight

[misake]

I have been working to get WS2801 pixel string Adalight project working with Boblight by implementing the AtmoLight protocol.

Other people seemed interested in getting Adalight working on a lower spec machine so this might help.

I started by taking ArdiunoAtmo for Atmolight support with an Ardiuno and added support for the WS2801 pixel string using FastSPI which makes it easy to support various other RGB pixel strings and strips and is easier to work with than directly with the Arduino SPI.

The aim is to get smooth colour transitions and video playback on my HTPC, which is currently running Win7 on a lowly AMD x64 3800+ (Admittedly DXVA is being used to accelerate the video decode.).

This is still a work in progress but with a 50 LED string the reaction time is acceptable while playing full HD content.

The new versions of Boblight do not run on Windows, but Boblight 1.3-beta 1 works a treat and can be found here. The attached configuration file should also work for the newer Linux version.

To compile the arduino sketch you will need to install the FastSPI library. (If you are using an Atmega168 you will need to modify the lib slightly, see this issue)

fastatmo.pde.txt

Rename fastmo.pde to use

(2.82 KiB) Downloaded 498 times

The Boblight configuration is for a string of 50 LEDs going counter clockwise round the TV starting at the bottom right hand corner, 9 LEDs on each side and 16 on top and bottom. This layout is done in the configuration file and the layout mapping code has been removed from the Arduino sketch.

boblight.conf.txt

Rename boblight.conf to use

(7.33 KiB) Downloaded 819 times

Again this is a work in progress, so any help getting this perfect would be much appreciated.
Known issues :
FIXED - Last pixel in string does not display correct colours, this is probably a sketch bug.
- Red is too prominent, this is adjustable via the Boblight config.
- Colours in general are too vivid compared to the on screen colours, again Boblight config.
- Occasional flickering, this seems related to the use of FastSPI as I've had the issue with other sketches.

Other objectives:
- Remove FastSPI dependency, this will involve me learning about the Arduino SPI and the protocol used by the WS2801 string so help would be appreciated.
- Change the sketch to loop and buffer in a similar manner to the original Adalight sketch.
- Add some neighbouring pixel colour averaging similar to what seems to be implemented in the Macetech version of the code.

[pburgess]

Cooool! It's been neat to see folks taking this new places. Choice is good.

Regarding the flickering: the WS2801 LED driver chip is somewhat unique...whereas most such depend on a specific code in the datastream to 'latch' the data, this one instead latches automatically when the serial clock is idle for 500 microseconds. This has some benefits -- 100% of the data bandwidth is conveying LED data, no parity overhead -- and some drawbacks -- the possibility of unintentional latching if the datastream should stall for too long...and hey, guess what, USB packets can have a latency of up to 1 millisecond. If you remember the bad old days of "burning coasters" before buffer underrun prevention became standard fare on CD recorders, this is exactly the same sort of problem that the LEDstream code is handling; taking data in fits and starts and issuing it at a more measured rate. It's a non-issue on most other LED drivers where the latch isn't timing-based.

Instead of messing around with code on both the Arduino and host PC, I think it'd save a lot of trouble just to keep the stock LEDstream code on the microcontroller (since it's handling a solved problem), and adapt Boblight alone to handle the appropriate serial protocol. It's pretty straightforward, and the 'colorswirl' C code included with Adalight shows how to load up a buffer with the required header and issue it to the Arduino.

[illiac4]

Hi!

Nice work.
I has also ordered WS2801 stripes to try this out.
I'm thinking to try with adalight https://github.com/adafruit/Adalight/bl ... am.pde#L42 .pde.
I'm going to get them work with boblight for linux. The old one does not support prefix.

In the end i'd like to offer the working .pde for Arduino board based on LEDstream.pde and a config.conf file.
The .pde should be designed so that the users will be able to modified it to the custom numbers of leds.

I think also bob1on1 is interested in this and as he already said will add the support in boblight.
http://forum.xbmc.org/showpost.php?p=90 ... stcount=25

[jeffre]

If you are willing to compile the newest boblight you can get it working right with the adalight.pde out of the box by using the prefix feature (prefix 41 64 61 00 18 4D)

Here's my full boblight.conf which works for my 25-led strand.
http://pastebin.com/W2N3PMAk

I wish someone could make the newest version of boblight into a windows executable.

*EDIT*
I am sure my prefix is off, after I found that the magic frame A,d,a doesn't need to be right in Processing I started playing around with it a lot to find out why.. never did resolve that but I will try to straighten the prefix out for boblight.

*EDIT*
Prefix is fixed and the pastebin has been updated.

[illiac4]

Cool this is really helpful.
When i get the lights i will compile the boblight from the source and will report back.
To modify the numbers of leds i have to modify this part of .pde?
Did you contacted bob1on1 if he is going to make it for windows too?

Code: Select all

static final int coord[][] = new int[][] {
  {3,5}, {2,5}, {1,5}, {0,5}, // Bottom edge, left half
  {0,4}, {0,3}, {0,2}, {0,1}, // Left edge
  {0,0}, {1,0}, {2,0}, {3,0}, {4,0}, {5,0}, {6,0}, {7,0}, {8,0}, // Top edge
  {8,1}, {8,2}, {8,3}, {8,4}, // Right edge
  {8,5}, {7,5}, {6,5}, {5,5} // Bottom edge, right half
};

static final int arrayWidth = 9, // Width of Adalight array, in LED pixels
                 arrayHeight = 6, // Height of Adalight array, in LED pixels
                 imgScale = 20, // Size of displayed preview
                 samples = 20, // Samples (per axis) when down-scaling
                 s2 = samples * samples;

TNX once again.

[jeffre]

your pde should look like this for 50 LEDs

Code: Select all

static final int coord[][] = new int[][] {
{8,8}, {7,8}, {6,8}, {5,8}, {4,8}, {3,8}, {2,8}, {1,8}, {0,8}, // Bottom edge, left half
{0,7}, {0,6}, {0,5}, {0,4}, {0,3}, {0,2}, {0,1}, // Left edge
{0,0}, {1,0}, {2,0}, {3,0}, {4,0}, {5,0}, {6,0}, {7,0}, {8,0}, {9,0}, {10,0}, {11,0}, {12,0}, {13,0}, {14,0}, {15,0}, {16,0}, {17,0}, // Top edge
{17,1}, {17,2}, {17,3}, {17,4}, {17,5}, {17,6}, {17,7}, // Right edge
{17,8}, {16,8}, {15,8}, {14,8}, {13,8}, {12,8}, {11,8}, {10,8}, {9,8} // Bottom edge, right half
};

static final int arrayWidth = 18, // Width of Adalight array, in LED pixels
arrayHeight = 9, // Height of Adalight array, in LED pixels
imgScale = 20, // Size of displayed preview
samples = 20, // Samples (per axis) when down-scaling
s2 = samples * samples;

Your boblight.conf will need a prefix to go along with this (41 64 61 00 32 ??)
If you need me to get that checksum bit for you let me know and I'll get back on my linux box later today.

[misake]

If you are willing to compile the newest boblight you can get it working right with the adalight.pde out of the box by using the prefix feature (prefix 41 64 61 00 18 4D)

Thanks jeffre, looks like Boblight will work unmodified with the LEDStream Arduino sketch.
Before seeing your post I was looking through the Boblight source to determine the format needed for the prefix, I knocked up this quick Processing sketch:

Code: Select all

int N_LEDS = 25; // Max of 65536

void setup()
{
  byte[] buffer = new byte[6];
 
  noLoop();

  // A special header / magic word is expected by the corresponding LED
  // streaming code running on the Arduino.  This only needs to be initialized
  // once because the number of LEDs remains constant:
  buffer[0] = 'A';                                // Magic word
  buffer[1] = 'd';
  buffer[2] = 'a';
  buffer[3] = byte((N_LEDS - 1) >> 8);            // LED count high byte
  buffer[4] = byte((N_LEDS - 1) & 0xff);          // LED count low byte
  buffer[5] = byte(buffer[3] ^ buffer[4] ^ 0x55); // Checksum

 
print("Prefix for "+N_LEDS+" LEDS: ");
for(byte b : buffer)
   print(" "+hex(b));

exit();
}

Prefix for 25 LEDS: 41 64 61 00 18 4D
Prefix for 50 LEDS: 41 64 61 00 31 64
Prefix for 100 LEDS: 41 64 61 00 63 36

[misake]

Regarding the flickering: the WS2801 LED driver chip is somewhat unique...

Thanks Phil,
I have now taken a quick look at the datasheet and see that I will need to investigate it properly and play around a bit more.
http://www.adafruit.com/datasheets/WS2801.pdf for anyone else missing it.

Fortunately the Boblight solution will work with your LEDStream Arduino sketch for anyone willing to compile it in Linux. Unfortunately the old Windows version only supports a 1 byte prefix. I will ensure my next HTPC gets a graphics card with proper Linux drivers.

For now I'm going to see if I can create a quick and slightly dirty solution, until I find time to try porting Boblight to Windows.

[jeffre]

@misake, sounds like we are in the same boat. I am unable to get my wifi working on linux. If you have any luck getting boblight on windows let us hear about it. I will do the same.

[misake]

Did you contacted bob1on1 if he is going to make it for windows too?

I will leave him to continue supporting the Linux version and XMBC...

I wish someone could make the newest version of boblight into a windows executable.

... and will give it a stab myself in the near future, when I have time.

It should be possible to port the Boblight server to Windows using Cygwin (personally I would prefer to strip out the POSIX stuff and use MinGW, but that's more work).
Then a new Windows client or two will need to be made, something like getPixel or a media player filter (I know little about Media Foundation but a custom EVR presenter could be what is needed).

I intend to write something to produce music visualisations for the LED strips anyway so might as well do it using Boblight.

[illiac4]

So basically for Linux users wiling to compile the boblight the solution with https://github.com/adafruit/Adalight/bl ... stream.pde this pde is universal and all it needs is modify the boblight.conf with valid prefix for the number of leds and define the leds positions.

How are you calculating check sum?
I see how to calculate the digist (f.e: 41 64 61 00 18 4D) but how do you calculate the last two (4D)?

P.S.:
The following is important because I think there is maybe bug in boblight, that sometimes occupies audio device even, if it is not defined in boblight.conf file. The result is 'audio device error'. This happens at AppleTV with Ubuntu 8.04 sometimes and i think this is the cause. So one tip for linux when compiling.
In command:
./configure define the flag -without-portaudio to configure boblightd without built portaudio support .

Code: Select all

./configure --without-portaudio

Because of this i thinx also some packages are not needed before compiling with flag --without-portaudio:
sudo apt-get install libx11-dev libgl1-mesa-dev libxrender-dev portaudio19-dev libavcodec-dev libavformat-dev libswscale-dev libxext-dev libavdevice-dev
I assume not needed are: portaudio19-dev libavcodec-dev libavdevice-dev


Flags are also:
--without-ffmpeg (usable on AppleTV with ubuntu 8.04)
--without-opengl

[pburgess]

Regarding the checksum, here's the relevant bit from the Processing sketch:

Code: Select all

  buffer[0] = 'A';                                // Magic word
  buffer[1] = 'd';
  buffer[2] = 'a';
  buffer[3] = byte((coord.length - 1) >> 8);      // LED count high byte
  buffer[4] = byte((coord.length - 1) & 0xff);    // LED count low byte
  buffer[5] = byte(buffer[3] ^ buffer[4] ^ 0x55); // Checksum


Bytes 0-2 are the magic word "Ada". Bytes 3 and 4 are the high byte and low byte of the 16-bit LED count (minus 1...so for 25 LEDs, this will contain the value 24, or 0x0018 hexadecimal). The checksum equals the high byte XOR the low byte XOR 0x55...in the 25 LED case again, this would be 0x4D. For 50 LEDs, it would be 0x64.

[illiac4]

Regarding the checksum, here's the relevant bit from the Processing sketch:

Code: Select all

  buffer[0] = 'A';                                // Magic word
  buffer[1] = 'd';
  buffer[2] = 'a';
  buffer[3] = byte((coord.length - 1) >> 8);      // LED count high byte
  buffer[4] = byte((coord.length - 1) & 0xff);    // LED count low byte
  buffer[5] = byte(buffer[3] ^ buffer[4] ^ 0x55); // Checksum


Bytes 0-2 are the magic word "Ada". Bytes 3 and 4 are the high byte and low byte of the 16-bit LED count (minus 1...so for 25 LEDs, this will contain the value 24, or 0x0018 hexadecimal). The checksum equals the high byte XOR the low byte XOR 0x55...in the 25 LED case again, this would be 0x4D. For 50 LEDs, it would be 0x64.

Ok i understand now. So for example the whole prefix for lets say 42 leds will be:
41 64 61 00 29 7C

TNX

[pburgess]

Exactly, yep!

[rjsachse]

But what about us windows guys?