Adalight - flickering LED's (Colorswirl, Prismatik & Ambibox

[Idefix]

Hello,

I'm currently trying to setup my 100 LED Adalight with the following components and would need some advice:

1x Arduino Nano (ATmega328)
2x Strands of 50x WS2801 RGB LED Pixels
1x 5V 33A Powersupply

The Arduino is hooked up to the first strand - input side - via pins GND = GND, PIN 11 = MOSI, PIN 13 = CLK.
The power supply is connected to the end of the first and the end of the 2nd strand.

LEDstream.pde uploaded to the Nano board.
R-G-B sequence shows up nicely on all LED's when the board starts up.

Initial test (CLKDIV at default value 16) shows the following problems:
- Colorswirl is flickering heavily
- Prismatik colors are completely off and random (e.g. set mood light to fix color blue shows yellow, switch to red shows green, switch back to blue shows purple)
- Prismatik and Ambibox both flicker heavily in screen capture mode and colors of individual pixels change even if screen remains the same

In order to get colorswirl to work nicely I had to increase the CLKDIV to 64.
This unfortunately did not fix the Prismatik or Ambibox issues. Less flicker but the jump between colors still happens.

At CLKDIV 128 Prismatik started to work somewhat. The flickering is gone in screen capture mode and the color are accurate as long as I leave the Primatik configuration open. Fixed mood lights show the correct color when selected and screen capture colors represent the background as intend.
Ambibox still flickers at 128 CLKDIV.

Prismatik Issue at CLKDIV128: as soon as the Prismatik config/setting window is minimized, the LED colors change slightly and do not match the capture properly.
Same when watching a movie, the LEDs light up at the correct places but colors are off/random again.

As the R-G-B pattern has notably slowed down during startup I'm wondering whether CLKDIV128 would work in the first place during actual screen capture and whether an even higher setting would make sense.

Also as most here use the Uno board I was wondering if it could be a Nano issue - aside from a fault LED strand?

Any help/tips what else I could try are highly appreciated.

Thanks !

P.S. attaching a picture of the frame I made to fix the 100 pixels behind my 55'' LED TV.

[pburgess]

Lots of things can lead to flickering. I'd suggest the following (in order) for tracking down gremlins...

1. Instead of trying to run the whole LEDstream+Prismatik combo, download the Adafruit_WS2801 library for Arduino and run just the basic strandtest sketch (changing it for 100 LEDs and hardware SPI). This eliminates one variable in the chain.
2. If that seems OK, instead of Prismatik/Ambibox/etc, try the 'official' Adalight code in Processing. Any change?
3. Could be voltage drop along the strands. When in doubt, connect power at additional points...though the guide kind of discourages it, there's really no harm in connecting power at both ends of both strands.
4. Could be dirty power from the supply. Add bigass capacitors (like 1000 uF) across + and - at each of the points where power is connected (i.e. four of them).
5. Are you using a genuine Arduino®©™ Nano™©®, or a "compatible" board? Sometimes clone boards use sub-par components that'll work fine for simple "blink LED" sketches, but exhibit strangeness when high-speed signaling is involved. If it is a clone...and if you have access to a "brand-name" board, at least to borrow (can be an Uno or whatever), try switching it out and see if there's a change.

[Idefix]

Thanks a lot for the reply.
Although I have not yet managed to test all of the 5 suggested points, here is the outcome of the ones I did:

1. Instead of trying to run the whole LEDstream+Prismatik combo, download the Adafruit_WS2801 library for Arduino and run just the basic strandtest sketch (changing it for 100 LEDs and hardware SPI). This eliminates one variable in the chain.
Done: the basic strandtest sketch works as advertised. No flicker. colors change smoothly

2. If that seems OK, instead of Prismatik/Ambibox/etc, try the 'official' Adalight code in Processing. Any change?
Done: Same issue as with Prismatik/Ambibox. Movint the CLKDIV all the way to 128 did not help much to reduce the flicker either unfortunately.

3. Could be voltage drop along the strands. When in doubt, connect power at additional points...though the guide kind of discourages it, there's really no harm in connecting power at both ends of both strands.
Open: I disconnected one of the 50 LED strands to see if it makes a difference during operation. The flickering remains :-(
I would need to take the TV off the wall and connect both ends. I tried a different PSU however without any improvement.
I'm powering the LEDs from a PC Powersupply with 5V and 33Amp so if there is a power drop I guess it must be due to some fault inside the LED strand?

4. Could be dirty power from the supply. Add bigass capacitors (like 1000 uF) across + and - at each of the points where power is connected (i.e. four of them).
Open: Not yet tried due to the TV off the wall issue. I tried a different PSU however without any improvement.
Both are PC Power supplies so I would assume they are clean.....or maybe not??

5. Are you using a genuine Arduino®©™ Nano™©®, or a "compatible" board? Sometimes clone boards use sub-par components that'll work fine for simple "blink LED" sketches, but exhibit strangeness when high-speed signaling is involved. If it is a clone...and if you have access to a "brand-name" board, at least to borrow (can be an Uno or whatever), try switching it out and see if there's a change.
Done: Yes the Nano is probably a "compatible" board © (© for China) and I though that this might be the reason. So installed a brand new Arduino®©™ Uno™©® board to test it out (came in the original packaging incl. mini Italy stamp.). Unfortunately no change at all :-( Colorswirl still needs the CLK DIV at 64 in order to work. Original processing script, Ambibox and Prismatik show the same issues all the way to 128 CLKDIV :-(

Could there be an issue with the data supply? E.g. interference on the USB link or faulty drivers?
Or an issue with the RGB strip given that it works at lower refresh speed (strandtest works out of the box, color swirl at 64 CLKDIV.....)?

Thanks once again for the support !

[pburgess]

The fact that the strandtest works suggests the problem isn't between the board and LEDs (the library sets SPI_CLOCK_DIV16, assuming you're using hardware SPI), and that the power supply and routing is probably sufficient.

If the problem were only on the 'clone' Nano, I'd blame it on a knock-off FTDI chip, but the fact that it's also happening on a Genuine Uno™®© suggests that's not the case.

This is Truly Weird, and I've not seen it before.

Does this computer have USB3 ports? If so, and if you have a USB2 hub, can you try 'filtering' it through that?

[Idefix]

Thanks once again for the reply.
I have tested both USB3 and USB 2.0 ports but with no success. :-(

Breaking news !!!

It works...... :-)

I changed the Arduino script from the SPI.h library to the latest FastLED library.
Colorswirl & Prismatik (5.9.1) work now as advertised out of the box.
I'm not sure what difference in the 2 libraries fixed it but I'm glad it is working now - Love the effect of 100 LED's at work !

This is the FastLED script I use for the WS2801.
It was adapted from a neopixel/WS2811/WS2812 adalight script I found. All credits go to the original author.

Code: Select all

// Slightly modified Adalight protocol implementation that uses FastLED
// library (http://fastled.io) for driving WS2811/WS2812 led stripe
// Was tested only with Prismatik software from Lightpack project (version 5.9.1, 5.9.6 and 5.11.1 so far - 5.11.1 has some issues on startup in windows so I'm not using it)
 
#include "FastLED.h"
 
#define NUM_LEDS 100 // Max LED count
#define LED_PIN 11 // arduino output pin - probably not required for WS2801
#define GROUND_PIN 10 // probably not required for WS2801
#define BRIGHTNESS 96 // maximum brightness
#define SPEED 115200 // virtual serial port speed, must be the same in boblight_config
 
CRGB leds[NUM_LEDS];
uint8_t * ledsRaw = (uint8_t *)leds;
 
// A 'magic word' (along with LED count & checksum) precedes each block
// of LED data; this assists the microcontroller in syncing up with the
// host-side software and properly issuing the latch (host I/O is
// likely buffered, making usleep() unreliable for latch).  You may see
// an initial glitchy frame or two until the two come into alignment.
// The magic word can be whatever sequence you like, but each character
// should be unique, and frequent pixel values like 0 and 255 are
// avoided -- fewer false positives.  The host software will need to
// generate a compatible header: immediately following the magic word
// are three bytes: a 16-bit count of the number of LEDs (high byte
// first) followed by a simple checksum value (high byte XOR low byte
// XOR 0x55).  LED data follows, 3 bytes per LED, in order R, G, B,
// where 0 = off and 255 = max brightness.
 
static const uint8_t magic[] = {'A','d','a'};
#define MAGICSIZE  sizeof(magic)
#define HEADERSIZE (MAGICSIZE + 3)
 
#define MODE_HEADER 0
#define MODE_DATA   2
 
// If no serial data is received for a while, the LEDs are shut off
// automatically.  This avoids the annoying "stuck pixel" look when
// quitting LED display programs on the host computer.
static const unsigned long serialTimeout = 150000; // 150 seconds
 
void setup()
{
  // pinMode(GROUND_PIN, OUTPUT);
  // digitalWrite(GROUND_PIN, LOW);
  // FastLED.addLeds<WS2811, LED_PIN, BRG>(leds, NUM_LEDS);
  FastLED.addLeds<WS2801, RGB>(leds, NUM_LEDS);
 
  // Dirty trick: the circular buffer for serial data is 256 bytes,
  // and the "in" and "out" indices are unsigned 8-bit types -- this
  // much simplifies the cases where in/out need to "wrap around" the
  // beginning/end of the buffer.  Otherwise there'd be a ton of bit-
  // masking and/or conditional code every time one of these indices
  // needs to change, slowing things down tremendously.
  uint8_t
    buffer[256],
    indexIn       = 0,
    indexOut      = 0,
    mode          = MODE_HEADER,
    hi, lo, chk, i, spiFlag;
  int16_t
    bytesBuffered = 0,
    hold          = 0,
    c;
  int32_t
    bytesRemaining;
  unsigned long
    startTime,
    lastByteTime,
    lastAckTime,
    t;
  int32_t outPos = 0;
 
  Serial.begin(SPEED); // Teensy/32u4 disregards baud rate; is OK!
 
  Serial.print("Ada\n"); // Send ACK string to host
 
  startTime    = micros();
  lastByteTime = lastAckTime = millis();
 
  // loop() is avoided as even that small bit of function overhead
  // has a measurable impact on this code's overall throughput.
 
  for(;;) {
 
    // Implementation is a simple finite-state machine.
    // Regardless of mode, check for serial input each time:
    t = millis();
    if((bytesBuffered < 256) && ((c = Serial.read()) >= 0)) {
      buffer[indexIn++] = c;
      bytesBuffered++;
      lastByteTime = lastAckTime = t; // Reset timeout counters
    } else {
      // No data received.  If this persists, send an ACK packet
      // to host once every second to alert it to our presence.
      if((t - lastAckTime) > 1000) {
        Serial.print("Ada\n"); // Send ACK string to host
        lastAckTime = t; // Reset counter
      }
      // If no data received for an extended time, turn off all LEDs.
      if((t - lastByteTime) > serialTimeout) {
        memset(leds, 0,  NUM_LEDS * sizeof(struct CRGB)); //filling Led array by zeroes
        FastLED.show();
        lastByteTime = t; // Reset counter
      }
    }
 
    switch(mode) {
 
     case MODE_HEADER:
 
      // In header-seeking mode.  Is there enough data to check?
      if(bytesBuffered >= HEADERSIZE) {
        // Indeed.  Check for a 'magic word' match.
        for(i=0; (i<MAGICSIZE) && (buffer[indexOut++] == magic[i++]););
        if(i == MAGICSIZE) {
          // Magic word matches.  Now how about the checksum?
          hi  = buffer[indexOut++];
          lo  = buffer[indexOut++];
          chk = buffer[indexOut++];
          if(chk == (hi ^ lo ^ 0x55)) {
            // Checksum looks valid.  Get 16-bit LED count, add 1
            // (# LEDs is always > 0) and multiply by 3 for R,G,B.
            bytesRemaining = 3L * (256L * (long)hi + (long)lo + 1L);
            bytesBuffered -= 3;
            outPos = 0;
            memset(leds, 0,  NUM_LEDS * sizeof(struct CRGB));
            mode           = MODE_DATA; // Proceed to latch wait mode
          } else {
            // Checksum didn't match; search resumes after magic word.
            indexOut  -= 3; // Rewind
          }
        } // else no header match.  Resume at first mismatched byte.
        bytesBuffered -= i;
      }
      break;
 
     case MODE_DATA:
 
      if(bytesRemaining > 0) {
        if(bytesBuffered > 0) {
          if (outPos < sizeof(leds))
            ledsRaw[outPos++] = buffer[indexOut++];   // Issue next byte
          bytesBuffered--;
          bytesRemaining--;
        }
        // If serial buffer is threatening to underrun, start
        // introducing progressively longer pauses to allow more
        // data to arrive (up to a point).
      } else {
        // End of data -- issue latch:
        startTime  = micros();
        mode       = MODE_HEADER; // Begin next header search
        FastLED.show();
      }
    } // end switch
  } // end for(;;)
}
 
void loop()
{
  // Not used.  See note in setup() function.
}

link to the FastLED library/webpage: http://fastled.io/
link to Prismatik 5.9.6: https://code.google.com/p/light-pack/do ... _5.9.6.exe
link to LED calculator and Prismatik config file generator (is you use this to calculate the LED spacing for your setup, make sure to check the LED count before you start fixing the LED's up as the calculation has some issues considering the LED's in the corners - I had to subtract 4 LED's from the total to make it work): http://tvgloria.hu/index.php

[alexat]

Thx, the fastled-script AND using a power cap (parallel to +5v and ground) solved the problem also for me! (Now working with Arduino Uno Replica, WS2801 50, Fastled-Script, Ambibox and Kodi Plugin)

[Keelouna]

Bless You. I have been stuck working with my Arduino and WS2801 LED's for days using Prismatik, colorswirl and ambibox with little help. Your break through is my savior. Thanks for sharing... like.. 2 years ago..

[yoyoyoyoyoyoyo]

Thanks for posting this!!!!!! Using original adalight pack with flickering issue, and this solved it!

[Vincent101]

Thank you for your FastLED script! I know that I am late to the party, but I thought I could never get things to work!

For anyone else who is following in my footsteps, here's my setup:

Arduino Uno,
WS2818 NeoPixels (I've got 60 LEDs running right now)
Prismatik v5.11.3

I used Idefix's script above, with a few minor adjustments:
My Neopixels are on Pin #6, so I needed to change LED_PIN to 6 and NUM_LEDS to 60.

These following lines:
// FastLED.addLeds<WS2811, LED_PIN, BRG>(leds, NUM_LEDS);
FastLED.addLeds<WS2801, RGB>(leds, NUM_LEDS);

Need to be replaced with:
FastLED.addLeds<WS2812, LED_PIN, RGB>(leds, NUM_LEDS);

In Prismatik, run the config wizard, hit next when it doesn't detect any Lightpack, select Adalight. Here you're going to want to know what Serial port your Arduino is running on, so go to device manager and you should see a drop-down selection called Ports (COM & LPT). Click on that and you'll see your Arduino with the COM number beside it. Back in the Prismatik setup use that COM number to select. Leave the Baud rate alone and set the Color format to RGB.

Setting up the screengrab locations can be tricky, but there is a text file there to assist with perfect placement.

Also it seems to just bug out and go crazy on me from time to time. I did get it working for a little while and now it's on the fritz a little bit.

Annnyway, thank you very much Idefix for helping my cause! I can't thank you enough.