Got it. Issue resolved. Thank you for your great help!
I want to put something into either the library itself or at least delay to make sure you don’t go over the 400hz rate w/ws2811’s.
Ah glad this turns out to be a ‘known issue’.
Check my math here, but I think that anything less than about 85 WS2811’s is potentially at risk for this, and the fewer there are, the higher the chance that it’ll happen. More than about 85 WS2811’s on one string can’t be updated more than 400 times per second.
So one diagnostic we can have is this: set NUM_LEDS to 100, and if the problem substantially disappears, it was probably due to trying to refresh > 400Hz.
Alternatively, we could do what Dan said and have the library make sure this can’t happen.
Ah…the problems that arise when your code runs too fast… such a terrible fate…
Using the NUM_LEDS 100 won’t work for the 8x8 matrix sold by Adafruit. I would be in favor of the library making sure we don’t spam our little LED’s
I have a preference for library guard rails, too.
But, just so you know, nothing bad happens if you send more data than there are LEDs. In fact, you can’t even see anything. If you have 64 pixels and transmit 100 pixels worth of data, the first 64 pixels worth of data will show on the first 64 pixels, and the remaining 36pixels worth of data just evaporate into the air.
So, memory constraints notwithstanding, you can always safely increase NUM_LEDS without particularly affecting your actual output. It just changes the timing. (Unless you have code that does something specific with NUM_LEDS, in which case it will, you just won’t be able to see the excess data anywhere.)
Thanks for the info. How would I address this issue, with a matrix?
Well, if you’re having this particular variety of somewhat random flickering, and you think it might be that you’re updating the LEDs “too fast” (more than 400X per second), the quick diagnostic tests are:
- increase NUM_LEDS to 100, or
- add “delay(3)” to the end of your “loop” function
If you do one of these, and the random flickering substantially goes away, you might have been updating the LEDs ‘too fast’ (!).
If you want a quick way to keep that from happening, add a “delay(3)” to the end of your “loop” function and leave it there.
Note: in this one special case, don’t use “FastLED.delay(…)”, just the regular built-in Arduino “delay(…)” function.
If my matrix only has 64 led’s, and NUM_LEDS = 100, my code still only writes data for the 64 led’s despite there being 100 in the leds[] array. Even if I am not writing data to the leds[], how can I benefit from changing NUM_LEDS > 100? I’m a tad confused still…
Because when you call show, it will write 100 LEDs worth of data, every time you call show. It takes 30us to write 1 LED worth of data so if you tell the library you have 100 LEDs of data to write out it will take 3ms to write all the led data out.
Remember, everyte me you call show, the data for all the LEDs gets written out, whether or not you’ve set any values for them.
Got it, that makes perfect sense now. Thanks!