Adalight project with WS2801 - One led light stays on

Hi there, I recently purchase an Arduino Uno to start on a project with adalight using 2 strands of 50 WS2801.

I began following the guide on Adafruit and uploaded the code to the arudiono board successfully but was instructed that the led should flash red, green than blue which didn't happen. Instead I just saw one led lid up white and stayed like that. I repeated the wiring process with Blue = GND Green = PIN13 Yellow = PIN11 and to no luck after uploading the code do I get the flashing colors. I also switch the Data(yellow) and Clock(green) wires around while leaving the Ground(blue) to pin 13 and still end up with the same result.

I'm not sure if its my power supply doing this or if I received fault led strip but the power supply labels* an output of 5V. I attach both strips without the arudino to them straight to the 5v power supply using a "Y Adapter" and both strands has the first led on the output end lit up white.

I have search the forums and spot another user with a similiar problem but it seem like he came to the conclusion that the led were faulty so he shipped them back. I have attach pictures bellow demonstrating the single led lighting up and the wiring of my arudino board incase anyone here notice some wiring mistake I would have likely done.(I will quickly attempt to fix the images if they're too big)

Thanks in advance for any help you can provide as this is my first led/arudino project.

The pictures do not show the wiring … only that you have good connectors. For the wiring seeing the diagram would be more helpful. Also including a direct link to the WS2801 you purchased saves some of us first to search for it in order to answer your question. Likewise include/link the sample code.

All this swapping you write makes me think you’re not really following the instructions (or the instructions are too vauge). Unless you made one error early on, blew the circuits, and now it is stuck in white.

Hi Msquare,
Sorry about no providing links I was afraid linking to other website wouldn’t be permitted on this forum like others.

The wiring diagram:


This is the code that was uploaded into the Arduino:

#include <SPI.h>

// LED pin for Adafruit 32u4 Breakout Board:
//#define LED_DDR  DDRE
//#define LED_PORT PORTE
//#define LED_PIN  _BV(PORTE6)
// LED pin for Teensy:
//#define LED_DDR  DDRD
//#define LED_PORT PORTD
//#define LED_PIN  _BV(PORTD6)
// LED pin for Arduino:
#define LED_DDR  DDRB
#define LED_PIN  _BV(PORTB5)

// 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 MODE_HEADER 0
#define MODE_HOLD   1
#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 = 15000; // 15 seconds

void setup()
  // 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.
    indexIn       = 0,
    indexOut      = 0,
    mode          = MODE_HEADER,
    hi, lo, chk, i, spiFlag;
    bytesBuffered = 0,
    hold          = 0,
  unsigned long

  LED_DDR  |=  LED_PIN; // Enable output for LED
  LED_PORT &= ~LED_PIN; // LED off

  Serial.begin(115200); // Teensy/32u4 disregards baud rate; is OK!

  SPI.setClockDivider(SPI_CLOCK_DIV16); // 1 MHz max, else flicker

  // Issue test pattern to LEDs on startup.  This helps verify that
  // wiring between the Arduino and LEDs is correct.  Not knowing the
  // actual number of LEDs connected, this sets all of them (well, up
  // to the first 25,000, so as not to be TOO time consuming) to red,
  // green, blue, then off.  Once you're confident everything is working
  // end-to-end, it's OK to comment this out and reprogram the Arduino.
  uint8_t testcolor[] = { 0, 0, 0, 255, 0, 0 };
  for(char n=3; n>=0; n--) {
    for(c=0; c<25000; c++) {
      for(i=0; i<3; i++) {
        for(SPDR = testcolor[n + i]; !(SPSR & _BV(SPIF)); );
    delay(1); // One millisecond pause = latch

  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 = >= 0)) {
      buffer[indexIn++] = c;
      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) {
        for(c=0; c<32767; c++) {
          for(SPDR=0; !(SPSR & _BV(SPIF)); );
        delay(1); // One millisecond pause = latch
        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;
            spiFlag        = 0;         // No data out yet
            mode           = MODE_HOLD; // 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;

     case MODE_HOLD:

      // Ostensibly "waiting for the latch from the prior frame
      // to complete" mode, but may also revert to this mode when
      // underrun prevention necessitates a delay.

      if((micros() - startTime) < hold) break; // Still holding; keep buffering

      // Latch/delay complete.  Advance to data-issuing mode...
      LED_PORT &= ~LED_PIN;  // LED off
      mode      = MODE_DATA; // ...and fall through (no break):

     case MODE_DATA:

      while(spiFlag && !(SPSR & _BV(SPIF))); // Wait for prior byte
      if(bytesRemaining > 0) {
        if(bytesBuffered > 0) {
          SPDR = buffer[indexOut++];   // Issue next byte
          spiFlag = 1;
        // If serial buffer is threatening to underrun, start
        // introducing progressively longer pauses to allow more
        // data to arrive (up to a point).
        if((bytesBuffered < 32) && (bytesRemaining > bytesBuffered)) {
          startTime = micros();
          hold      = 100 + (32 - bytesBuffered) * 10;
          mode      = MODE_HOLD;
      } else {
        // End of data -- issue latch:
        startTime  = micros();
        hold       = 1000;        // Latch duration = 1000 uS
        LED_PORT  |= LED_PIN;     // LED on
        mode       = MODE_HEADER; // Begin next header search
    } // end switch
  } // end for(;;)

void loop()
  // Not used.  See note in setup() function.

And thanks Msquare for replying to my thread.

Your second picture shows that the light that is on, is at the opposite end from which you have connected the Arduino.

This tells me that you have connected the Arduino to the wrong end!

Hey Paul,
I’m not home right now but will double check again when I do get home. I’m pretty sure I wire the correct end to the ardunio board because according to the wiring diagram it should be the end where I’m able to attach a mating connector be the end I plug into the arduino board correct?

un4seendeathz: according to the wiring diagram it should be the end where I'm able to attach a mating connector be the end I plug into the Arduino board correct?

It might be correct if all these looms were constructed - and sold - the same. All that I have purchased (only three actually), have come with the mating connector on each end which would be a convenience if you need to chain two which come with different connectors (some are 3-pin, some are 4).

In any case, one way or another you need to connect the Arduino to the input end. Since the WS2801 are CMOS devices, if the inputs are left floating, they pick up random (static?) interference which (especially when you handle the cable) is interpreted by that chip as a command and often turns the LED on as white or blue. Because such random "commands" are not properly formatted, it is unlikely they will ripple to subsequent LEDs, so only the LED at the input end responds. This is effectively a test for which end is the input. Also on inspection, the input generally is wired to the side of the PCB in the encapsulation on which the chip itself is mounted.

So Paul I wold need something like this now ?

Since I am now testing the other end in case it was actually the input and not a output end that I thought it was?

Well you might to make a neat job of it, but to test it out, just push jumper wires into the back of the connectors!

Tell me how that goes!

Paul... Thank you so much you were right! I ordered a soldering kit and jumper wires two days ago and today I quickly tested the opposite end and to my surprise all led now lights up! Thank you so much Paul I would have likely return these led if it wasn't for your suggestion.

un4seendeathz: I quickly tested the opposite end and to my surprise all led now lights up! ... I would have likely return these led if it wasn't for your suggestion.

Glad to hear it.

If they supplied you with only the connector for the wrong end, that was a bit rude however, and you could reasonably argue that it was "faulty" in a sense! You only really need the connector for the correct end since in the vast majority of situations, you are only gong to use one string, or strings of the same type which simply chain together.

Hello, i know i dig up an old topic but i have the same problem i'm using bullet shape RGB WS2801 50 leds (bought from aliexpress) wiith arduino

firstly i was connecting leds wrong way like someone i switched that and now there is still one led that goes blue after i connect it to power.

the wiring is fine, i added a code from this site

what else could it be? i'm stuck