I have an application for which I need to control 8 of the 16-pixel Rings for a total of 128 pixels. I'm using a Due to get the processing power needed for doing a lot of DSP on an audio signal. Just as a test, I hooked up 1 NeoPixel Ring and simply "ramped up" all pixels with single colors (let's say red) from 0 through 255, e.g.:
Code: Select all
#define NUM_NEO_PIXELS 16
#define PIN 53
Adafruit_NeoPixel strip = Adafruit_NeoPixel(NUM_NEO_PIXELS, PIN, NEO_GRB + NEO_KHZ800);
int m,n;
uint8_t rr, gg, bb;
void setup() {
strip.begin();
strip.show();
]
void loop() {
for (m=0; m<256; m++) {
rr = m; gg = 0; bb = 0;
for(n=0; n<NUM_NEO_PIXELS; n++)
{
strip.setPixelColor(n, rr, gg, bb);
}
strip.show();
delay(50);
}
}
and all looks fine. When I added a second ring, changed the definition of NUM_NEO_PIXELS to 32, and try the same simple code, all looks fine until the LED intensity reaches a particular level for which an 'arc' of contiguous pixels begins to form on the second (upper) Ring that are wildly deviating from red. The 'arc' increases in scope as the intensity increases toward maximum (i.e. m->255 in the above code). By adding a third ring, and defining NUM_NEO_PIXELS to be 48, the severity of the problem increases, beginning as a small 'arc' of 'deviant' pixels on Ring #3, passing through a point whereby all 16 pixels on Ring #3 are 'deviant', and enentually ending with a small 'arc' of 'deviant' pixels propagating into Ring #2 as well, as m->255.
I took at pin 53 with a logic analyzer and the traffic appears to be all there, although there appears to be a +/- 5% variation in frequency from the expected 800KHz. Should I be digging harder for a timing issue, or could this perhaps be a +5V supply problem to the Rings?
Jim