Can't light up all the leds in the strip


I am using a Teensy 2.0 with WS2801 Leds.
I have uploaded this code to the Teensy 2.0. I took it from Github for Adafruit project.
I am currently using 40 leds with a 5V 8A DC supply.
The Leds are disposed in a rectangle of 16*4 and it is designed to go in my PC Tower.

See the attached pic

As you can see, all the Leds are not lighted up.
If i do understand the following code, it supposed to light up the first 25000 LEDs -.-
But what is weird to me it that for example, LED 30 is lighted up LED 31 is not, LED 32 is not but LED 33 is. Doesn’t make any sense to me why it is “jumping” some LEDs.

I tried to modify the code, but it seems not to change a thing since i am a real newbie to this. So with all the kindness i can offer, i am asking for your help.

Thank you mates.

#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_PIN  _BV(PORTD6)
// LED pin for Arduino:
//#define LED_DDR  DDRB
//#define LED_PORT PORTB
//#define LED_PIN  _BV(PORTB5)

static const uint8_t magic[] = {'A','d','a'};
#define MAGICSIZE  sizeof(magic)

#define MODE_HEADER 0
#define MODE_HOLD   1
#define MODE_DATA   2

static const unsigned long serialTimeout = 15000; // 15 seconds

void setup()
    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

  uint8_t testcolor[] = { 8, 16, 32, 64, 128, 255 };
  for(char n=3; n>=0; n--) {
    for(c=0; c<20; 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();

  for(;;) {

    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:

      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((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.

I use the FastLED library for LED strips.


Well i was trying this library the meanwhile.
This is what i build from the wiki.

Stil, the same LEDs doesnt light up.
May i consider they r fried ?
I thought a fried LED would stop the signal to keep going from LED to LED. Can someone confirm ?

#include "FastLED.h"
#define NUM_LEDS 40

// Data pin that led data will be written out over
#define DATA_PIN 2
// Clock pin only needed for SPI based chipsets when not using hardware SPI
#define CLOCK_PIN 1


void setup() {
    FastLED.addLeds<WS2801, RGB>(leds, NUM_LEDS);

void loop() {
   int i=0;
   for (i=0 ; i<NUM_LEDS ; i++)
        leds[i].r = 64; 
        leds[i].g = 128; 
        leds[i].b = 255;

I noticed too that asking blue in the code give green and asking green in the code give blue.

Did i fry the strip one way or another ?

Lights can be wired different ways. One of the library initialisation parameters is the order of the colors.

Ok, so i might not worry about that. I tried to "manually" address the LED. When i choose to adress the 24th LED only of the strip, it does light up thel 28th LED instead of the 24th.

What should i understand ? The 25,26,27th LEDs are fried ?

Have u tried writing some code where you press a button and it progresses from one led to the next. Can also do with a set delay between LEDs. This would allow you to verify whether a LED lights up in a systematic way.

LEDs can be fried or not properly attached to the strip, depends on the type of strip.

Yes i did, does the same, just jump from the 23th to the 28th LED.

Can you cut the strip around the problem and rejoin? Strips usually come in separable sections.

Yes indeed, i should do that but it will cut the esthetic. So i am gonna buy another meter to replace the strip which is not working properly.

I tried with another waterproof white strip WS2801 and it worked perfectly after welding the wires.

Im gonna unweld the strip and test it alone i think. Since im a terribler welder maybe i fked up.


Its working very well with the other strip that i set up behind my screens.

The other is probably damaged.

Thanks for you help

Just a FYI - we do not "weld" electronic connections (with exception in chip manufacture itself) - we use a material called "Solder" in a process called "soldering".

This is a problem in translation from (many, it seems) other languages which have not acquired the necessary distinguishing words for certain technical processes.

Oh thank you for the feed back. its always interresting, now i'll speak a less poor english :p So to solder and not weld when it comes about electronic connections =)