This is very possible it’s something unrelated because it’s running through BiblioPixel and the AllPixel but I’ve noticed that on some, not all, APA102 strips I have to configure it for 1 more pixel than it actual should be otherwise the last pixel is always a frame behind for some reason. At first I thought it was an incorrectly configured SPI speed but now I still see it from time to time. Anyone ever see the APA do somthing like this?
What version of the library are you using? I think this may be a bug in the APA102 code that I fixed on the FastLED3.1 branch.
(short version - the APA102 requires that you clock out more data (8 bits for every 16 led pixels that you have) to strobe the clock line enough to make sure that data propagates all the way down the line - I wasn’t doing that originally)
#define FASTLED_VERSION 3000002
crap… I tested this on APA102 a bunch and never saw this until recently. Is there any way I can fix it with the data I send? (as in without changing the firmware)
Not that im aware of, this wasn’t something I realized apa102 required until recently. Otherwise, for apa102 just silently tell it that you have a couple extra pixels.
umm… problematic. As you might imagine, this is on the AllPixel firmware. Which is currently in production at the moment. And I did notice that adding an extra pixel did do the trick. Think I’m gonna have to fake that in BiblioPixel for the APA102 only. I actually saw this last week but thought it was SPI speed related and fixed that… or so I thought. It worked at the time 
Do you have any mechanism for revving the firmware in allpixel?
The firmware can be updated with an ISP programmer (or arduino acting as one). Changing it on the production boards would be a bit harder at the moment. Though next run certainly would have a fix. I think I can patch it to work in BiblioPixel itself for now, espcially now that I know it needs an extra byte per 16 pixels.
Let me double check the math that I’m using but I am pretty sure that was it.
So for every 64 leds FastLED3.1 writes out 4 bytes of data (basically a black led - keeps from flashing if you tell the library to use fewer than leds than your physical strip has).
ok… allpixel expects full pixels (3 bytes), so I’m going to have to round up to the nearest pixel so I’ll just call it 6 bytes (2 pixels) for every 64 LEDs, or 1 for every 32. Should be easy enough. I’ll deprecate the hack later once most AllPixels have newer firmware… if I can’t get the current run updated that is. I just want a backup.
Just send a full pixel for every 64 leds you have (minimum of 1). That will write out four bytes of data from the library.
Oh… Even FastLED 3.0 sends out 4 bytes per pixel?
Just not the extra ones at the end…
The apa102 protocol is four bytes per led.
Gotcha… I’ll do that then.
You’re the man 
That fixed it. I’ll of course fix it in firmware as well, but a backup is always nice And this is pretty much a minor change to bibliopixel.
Anything I need to watch out for upgrading to 3.1?
Just realized that FastLED 3.1 is not an officially released version as of yet… would it be safe to pull into the AllPixel firmware or do you think I should wait for an official, stable release?