5 meter Neopixel string strandtest problem

Hi everyone,

I’ve have two 5 meter (300 pixel) WS2812B strips purchased on eBay. I plugged each into a Mega 2560 one at a time, with a 5v, 10a power supply running the LEDs. I ran the RainbowCycle portion of the NeoPixel_Library strandtest.

For some reason, between the 255th to 256th pixels, the colors don’t merge as fluidly as on the rest of the strip. There is a clearly visible distinction in color. This happens on both strips.
Running the same sketch on other shorter strips (1m) and various rings (varying the number of pixels in the sketch of course) has been fine.

I was hoping that someone might be able to tell me why.
I’ve read about the possibility of data ‘reflecting’ back on a particularly long line. It was mentioned as being solved by adding a pull-down resistor to the data-out line back to ground. I’m not sure if that is what I’m encountering. If that sounds likely, then what value of resistor is appropriate?

Thanks!

Below is the code I’m running:

#include <Adafruit_NeoPixel.h>
#include <avr/power.h>

#define PIN 6

// Parameter 1 = number of pixels in strip
// Parameter 2 = Arduino pin number (most are valid)
// Parameter 3 = pixel type flags, add together as needed:
//   NEO_KHZ800  800 KHz bitstream (most NeoPixel products w/WS2812 LEDs)
//   NEO_KHZ400  400 KHz (classic 'v1' (not v2) FLORA pixels, WS2811 drivers)
//   NEO_GRB     Pixels are wired for GRB bitstream (most NeoPixel products)
//   NEO_RGB     Pixels are wired for RGB bitstream (v1 FLORA pixels, not v2)
Adafruit_NeoPixel strip = Adafruit_NeoPixel(300, PIN, NEO_GRB + NEO_KHZ800);

// IMPORTANT: To reduce NeoPixel burnout risk, add 1000 uF capacitor across
// pixel power leads, add 300 - 500 Ohm resistor on first pixel's data input
// and minimize distance between Arduino and first pixel.  Avoid connecting
// on a live circuit...if you must, connect GND first.

void setup() {



  strip.begin();
  strip.show(); // Initialize all pixels to 'off'
}

void loop() {
  // Some example procedures showing how to display to the pixels:
//  colorWipe(strip.Color(255, 0, 0), 50); // Red
//  colorWipe(strip.Color(0, 255, 0), 50); // Green
//  colorWipe(strip.Color(0, 0, 255), 50); // Blue
  // Send a theater pixel chase in...
//  theaterChase(strip.Color(127, 127, 127), 50); // White
//  theaterChase(strip.Color(127,   0,   0), 50); // Red
//  theaterChase(strip.Color(  0,   0, 127), 50); // Blue

 // rainbow(20);
  rainbowCycle(20);
//  theaterChaseRainbow(50);
}

// Fill the dots one after the other with a color
//void colorWipe(uint32_t c, uint8_t wait) {
//  for(uint16_t i=0; i<strip.numPixels(); i++) {
//      strip.setPixelColor(i, c);
 //     strip.show();
//      delay(wait);
//  }
//}

//void rainbow(uint8_t wait) {
//  uint16_t i, j;

//  for(j=0; j<256; j++) {
//    for(i=0; i<strip.numPixels(); i++) {
//      strip.setPixelColor(i, Wheel((i+j) & 255));
//    }
//    strip.show();
//    delay(wait);
//  }
//}

// Slightly different, this makes the rainbow equally distributed throughout
void rainbowCycle(uint8_t wait) {
  uint16_t i, j;

  for(j=0; j<256*5; j++) { // 5 cycles of all colors on wheel
    for(i=0; i< strip.numPixels(); i++) {
      strip.setPixelColor(i, Wheel(((i * 256 / strip.numPixels()) + j) & 255));
    }
   strip.show();
   delay(wait);
  }
}

//Theatre-style crawling lights.
//void theaterChase(uint32_t c, uint8_t wait) {
//  for (int j=0; j<10; j++) {  //do 10 cycles of chasing
//    for (int q=0; q < 3; q++) {
//      for (int i=0; i < strip.numPixels(); i=i+3) {
//        strip.setPixelColor(i+q, c);    //turn every third pixel on
//      }
//      strip.show();
//     
//      delay(wait);
     
//      for (int i=0; i < strip.numPixels(); i=i+3) {
//        strip.setPixelColor(i+q, 0);        //turn every third pixel off
//      }
//    }
//  }
//}

//Theatre-style crawling lights with rainbow effect
// void theaterChaseRainbow(uint8_t wait) {
//  for (int j=0; j < 256; j++) {     // cycle all 256 colors in the wheel
//    for (int q=0; q < 3; q++) {
 //       for (int i=0; i < strip.numPixels(); i=i+3) {
 //         strip.setPixelColor(i+q, Wheel( (i+j) % 255));    //turn every third pixel on
 //       }
 //       strip.show();
       
 //       delay(wait);
       
 //       for (int i=0; i < strip.numPixels(); i=i+3) {
 //         strip.setPixelColor(i+q, 0);        //turn every third pixel off
 //       }
//    }
//  }
//}

// Input a value 0 to 255 to get a color value.
// The colours are a transition r - g - b - back to r.
uint32_t Wheel(byte WheelPos) {
  WheelPos = 255 - WheelPos;
  if(WheelPos < 85) {
   return strip.Color(255 - WheelPos * 3, 0, WheelPos * 3);
  } else if(WheelPos < 170) {
    WheelPos -= 85;
   return strip.Color(0, WheelPos * 3, 255 - WheelPos * 3);
  } else {
   WheelPos -= 170;
   return strip.Color(WheelPos * 3, 255 - WheelPos * 3, 0);
  }
}

It looks just like you are running into the limit of the resoloution on the colour defination. A number like 255 to 256 screams this.

Also look at the Wheel function as written it falls over after 255, make it wrap round by some input filtering.

Hi, what happens if you change

uint16_t i, j;

to

uint32_t i, j;

(I'm worried that this calc is overflowing:

i * 256

)

Paul

When I identified the point of the problem, I counted backwards from the end, then did the math to label them the 255/256th. I totally spaced on the obvious there. Thanks Mike!

I took Paul's advice because I don't know how to code well enough to create my own input filter (it did lead to an interesting lesson via Google though). Changing the uint16 to uint32 seems to have fixed the problem. I can no longer identify any flaw in the color cycle.

I greatly appreciate your help, guys! Thanks!