@Mark_Kriegsman and @Daniel_Garcia , you guys hit the nail on the head! This is with 2.1-Dither. Using 2.0 this does not happen. Remember the actual length is 48. Count the dots. 
What I don’t understand is, why is that trailing (blue) LED only happening on a portion of the wheel. It goes away once the hue hits green to red then it reappears.
What is your rgb ordering?
RGB … being custom made strips, I made sure they’re wired correctly.
How easily can you try out using the hardware SPI? I’ve been taken down by a migraine (tis the season?) - but i’m suspecting that this is being caused by something with the bitbanging - i’ve had problems in the past with things getting shifted because the last led chip didn’t latch properly (which is why, for a while, the library was sending out one extra pixel’s worth of data for SPI chipsets)
For testing, easy enough. They’re dynamically generated, so I can disconnect the SD card. As long as I’m not left with needing to use SPI for it in the final design - I need it for the SD card. 
I’ll test this evening when I get home. 47, 48, and 49.
No, I just want to verify whether the problem exists across the board w/SPI or if it’s just bitbang’d SPI - you can probably get away with writing out 49 pixels in a pinch w/bitbang’d spi if i can’t get it fixed.
Yep, that’s what I figured. The only catch is that I will need to change everywhere I use a reference to NUM_LEDS to the actual length. For example, reading data from the SD card, a file.read((char*)leds, NUM_LEDS * 3) will no longer work.
nope - keep using NUM_LEDS nearly everywhere - just use NUM_LEDS + 1 when defining your CRGB array and when calling addLeds
If NUM_LEDS is set to 49, and I use that to read data, it will read 49 * 3 bytes. That’s three extra bytes I don’t need, not for that cycle at least. It’s what happened last night when I forgot I set it to 49: everything got distorted and I went, WTH HAPPENED NOW?! The read pointer gets pushed 3 bytes too far every time …
So I can read NUM_LEDS-1 * 3, sure.
Right - so what i’m saying is:
#define NUM_LEDS 48
CRGB ledData[NUM_LEDS+1];
void setup() {
LEDS.addLeds<LPD8806,CLOCK,DATA>(leds, NUM_LEDS+1);
}
et voila, you can continue to use NUM_LEDS everywhere else in the world.
Oooh, you’re talking the other direction. I was thinking the opposite. That makes more sense.
(Don’t get me wrong, I want to actually fix whatever is going on, but I feel like I’ve banged my head against this in the past. The solution may be to go back to having the SPI engines write out an extra pixels worth of data to ensure latching - but I also want you to have something you can work with in the meantime.
Ok, the problem persist when driving through the hardware SPI. Something else also reared its ugly head: it’s WAY slower. I’m using the same exact code and only switched the addLeds command:
From this: LEDS.addLeds<LPD8806, DAT_PIN, CLK_PIN, RGB>(leds, NUM_LEDS).setDither(DISABLE_DITHER);
To this: LEDS.addLeds<LPD8806, RGB>(leds, NUM_LEDS).setDither(DISABLE_DITHER);
The patterns are refreshing much much slower, really odd. I would’ve expected the hardware SPI to be faster. I can actually see the individual pixels change colors. With bit-banging I can’t, it flashes too fast.
What is the hardware that you’re running on, again? Avr bitbang’d tops out at about 2.5mbps, vs 6ish on the teensy, hardware tops out at 8mbps in avr, or, for lpd8806, 20mbps.
Also - put in frame rate counters to be sure - if updates are pushing too fast (possible with a short strip) updates might skip display.
I’ll try to dig out my lpd8806 strips here and poke at them again. (Right now I only use them for testing, since they aren’t giving me a lot of benefit these days)
Hmm, on the SPI side, I wonder if it would be enough for me to strobe the clock line one more time after the data goes out…
If you want to do that and have me grab a test branch, let me know.
It’s running on an AVR 32U4 driving LPD8806. It doesn’t appear to be dropping frames, the patterns aren’t broken in anyway, it’s just refreshing rather slow compared to bit-banging it. If it’s missing clock pulses, it’s very consistent about it.
I should check the 32u4 data sheet and make sure they did change the SPI register settings for timing.