Random color corruption of WS2815 using 3B+

[JeffJassky]

Board: Raspberry Pi 3b+ LEDs: WS2815 (12v) Pin: GPIO12 / BCM18 / PWM0 dmaNum: 10 Number of pixels: 236

Works as expected 80% of the time.

intermittently, random blocks of pixels (sometimes a single pixel, usually larger blocks of pixels) become a seemingly random color and no longer respond. The surrounding pixels on the rest of the strip continue to respond properly, but the corrupt blocks stay stuck on the random color.

reset(), reinitializing with init(numPixels, { dmaNum: 10 }); and re-rendering with an entirely new array of pixel data does not uncorrupt the blocks. The entire strip has to be power cycled in order to regain proper rendering of the corrupt blocks.

I've tried several raspberry pis and get the same result.

I also have /etc/modprobe.d/blacklist.conf configured with

blacklist snd_bcm2835
blacklist snd_pcm
blacklist snd_timer
blacklist snd_pcsp
blacklist snd

Is there something I'm missing about how the GPIO configuration? Is it possible this pin is still being used by something else at the same time? Am I missing a module from my blacklist? Is there a way to confirm my blacklist is working properly?

Thanks!

[usefulthink]

hmm, these problems are always a bit hard to debug without knowing a lot more about the exact setup. The fact that re-initializing the library is not resetting the state of the LEDs hints at this being some sort of hardware- or signal-issue. I suspect you don't have access to an oscilloscope?

• How did you wire up the backup-data line (BIN) of the LEDs?
• what voltages are you using for data and VCC? How is the circuit between the PI and the LEDs built?
• is there a probability for electrical noise in the circuit, especially the data-line (long unshielded wires, nearby electrical fields etc)?
• anything special about where the corrupted segments start/end?

[JeffJassky]

@usefulthink thanks for responding!

I'm using a mosfet-based logic shifter to 12v (for WS2815). Circuit shown here is for two separate, identical data lines in a terminal block. I'm only using one right now. Circuit reference here: https://www.nxp.com/docs/en/application-note/AN10441.pdf

BIN is not wired up at all. I wasn't really sure what that line was about. Should I try putting the BIN in my unused data line terminal?

The data line is very short. EMF/cross-talk/noise not likely.

Nothing seemingly special about the corrupt segment positions. Random every time.

I do have access to an oscope. I don't know how to use it well but my buddy probably knows what to do.

Any suggestions before I call my buddy over to oscope it?

[usefulthink]

I don't fully understand the weird english translation of the datasheet (http://www.normandled.com/upload/201808/WS2815%20LED%20Datasheet.pdf), but I think I ÷would try to wire the BIN together with DIN.

[usefulthink]

It's very confusing. Some diagrams I see in the image-search show the BIN floating, some have them grounded. According to this, it also doesn't really help explaining what you're seeing:

So, it seems the backup-data line is forwarded from the data-in of the previous LED, so it wouldn't explain multiple LEDs getting stuck