Houston, we have a problem with the 2.1 branch. It doesn’t know how to count, but only on the blue channel. The 2.0 branch does not exhibit this issue. And in trying to explain it I realize I’m too dang tired … I didn’t understand my own writing. So instead here’s a video. Basically look at the blue chase as it reaches the end of the 48 pixel strip. I purposely slowed it down when it hit pixel > 42 so it’s visible. It only happens on the blue channel and only on 2.1 …
Oh right … need to wait for it to finish processing … sigh
By the way, when I was testing half-strips, so only 24 pixels, it worked fine. It wasn’t till I put two together for the full 48 pixel length that this happened.
Yeah - I used to have code that wold send one pixels worth of data extra and turned that off. It looks like I need one last clock strobe to get the data locked in. I’ll toss that in tomorrow.
Why would it only do it on one channel and not all three though? Wouldn’t the code to send the data be the same across all of them, just the channel value is changing …
Probably because that last led is getting 8 bits of red data (8th bit registered, latched in), 8 bits of green data (8th bit registered, latched in), but only 7 bits of blue data (because the 8th bit hasn’t reigstered/latched - hence the “strobe the clock line one more time on the way out”.
You can “sneak” around this until I do a fix by telling the library you have one more led than you actually do.
btw, i’m assuming you’re using the bitbang’d spi output, right?
Or - if you can pull the latest 2.1 and try that? I’ve added an extra clock toggle in there.
(I should pay more attention to where in the clock shifting cycle these chipsets read bits, I suspect i’m being a little sloppy here…)
Actually, for that test it was on the SPI port. I did grab the latest last night just prior to taking that video. If you’ve made changes, I’ll grab it again when I get home.
Ah, only made a change for bit bang. Hmm, for hardware SPI I wonder if I’ve got the clock settings wrong? Away from code for a couple of hours but I can poke it again when I get home (then I’m off for the weekend. There’s also a “still too fast for ws2801” bug I need to chase down.
–Dg (on mobile phone, pardon terseness and typos)
Oh that’s fine, I have my daughter graduating HS this weekend anyway, so I won’t have a whole lot of time to work on anything.
Ok - try now - added the end of data clock toggle in to all the spi implementations now.
Nope, still does the same thing. I grabbed the latest 2.1. I have dithering disabled, using the SPI port, and it’s doing the same thing, only on the blue channel.
Ah! I think I found it - the LPD8806 has a set of zeros that get sent out to latch data - the current code does one 0 per lpd8806 rgb pixel, but it looks like it needs to be one 0 per byte of data that was sent out. It also looks like the lpd8806 will latch a byte’s worth of data after passing through a byte’s worth of data. The reason why that last blue doesn’t come up is because it never latches.
I just pushed code that sends a number of 0’s based on the number of bytes being written, vs. the number of pixels - let me know if that helps (I’m visiting family, and have access to code to tweak, but not leds to test).
Actually, it’s slightly different compared to yesterday’s video above. See new video here: >> https://www.youtube.com/watch?v=a2Y5ot4hUWo <<
Is that video the code with the extra clock (which I pushed earlier) or the code with the fixed latch bytes sending (which I pushed about 5 minutes ago 
The video is from earlier. Testing what you just pushed a few minutes ago now.
Ok, the last push fixed it.