Only blue getting garbled?

[1pet2_9]

Has anyone ever had only the blue garble your data line before? One channel on my megatree is doing that. I see no evidence of power injection causing it. I run the test patterns on that channel, and red and green are perfect. Blue goes disco on me. So does the pulsating white pattern, and faint white still seems to do it (not just 100% brightness). Plugging in the data input at pixel 100 seems to sidestep the problem. Running real sequences at 30% brightness still exhibits the problem, on blue.

What could cause only the blue to cause problems? Should I be chasing down a bad pixel, or bad power injection? Is there a way on the WS2811 IC for the blue line [on a bad pixel] to short with only ground?

[Kensington]

I think the clue is what happens when you bypass the first 100 pixels. It sounds like you have bad data transmission prior to pixel 100. If the problem happens from pixel 1 onward, I’d guess the first pixel is the problem. What happens if you test the first 100 pixels with nothing downstream from them?

[1pet2_9]

When it's only 100 pixels, the second half of the string goes disco on the blues, but there is no one pixel that starts the irregularity. It's intermittent. I guess at least I could rule out power injection when it's only 100 pixels, but nothing is easy debugging a megatree. It's just so weird that it's only the blue. And if there's a power/ground short, increasing the power injection is probably a bad idea even for a short time.


I just found this:

https://www.tme.eu/Document/26d574b4...145/WS2811.pdf

Interesting...the OUTB pin is indeed right next to the GND pin. I think I have a bad pixel. Looks like going into test mode and lighting up the pixels blue one-by-one backwards from 100 is the way to isolate it. What a bear. Hoping someone who's seen this problem before can stop me before I go to the trouble.

[1pet2_9]

Problem found and fixed! Documenting this, for posterity:

PROBLEM SEEN: a significant portion of the data line flickers in random colors intermittently, but only when the pixels are supposed to glow blue.

ROOT CAUSE: the OUTB and GND pins are shorted inside the pixel. Solution is to replace the pixel. However, finding which pixel to replace proves to be problematic. I'll go over my debug process later.

SECOND ROOT CAUSE: the incoming data line was connected to an unallocated port on the controller--but adjacent to the right one. It was one off. The incredibly strange thing is, that data line was actually playing real sequences this entire time, despite being on an empty port! The crosstalk alone from the immediate neighboring port on the Kulp32 controller was not only sufficient to drive the data line, but to drive the data over a 5-meter cable to the first pixel. Apparently, this crosstalk is occurring prior to the output driver, and the output driver is amplifying/buffering the crosstalk.


How I arrived at this by debug:

First, I went into Test mode in Xlights and highlighted the megatree in Red (I used Red because I knew there was no short on Red. No harm done testing in Red). Then, I isolated exactly the problematic channel on the megatree by turning channels off. Here's the odd thing I found: the problematic channel was not responding to on/off in Test mode. Yet it's been playing sequences!! When I moved the phoenix terminal over to the correct channel on the controller, it then responded to Test mode. BUT...that did not fully fix the problem....

Second, to identify which pixel had a bad blue LED, i switched the color to a very dim Blue on that entire channel. As I amped up the Blue intensity to 33 (out of 255), it started flickering. Then I just had to start turning off nodes one-by-one, with the Blue intensity increased to 45. Pixel 162 clearly caused the flickering. Turning it off stopped it. Turning it on started it. Replaced pixel 162 and the entire data channel worked again.

As hard as it was to identify the bad pixel just by looking at it, the Test mode in Xlights actually made finding it very straightforward. Incidentally, similar behavior only on the Red or Green colors is highly unlikely to happen. The Red and Green pins are not adjacent to GND on the WS2811 chip. Blue is. Thus Blue can easily short to GND pin, but Red and Green would almost never short to GND without also shorting to something else as well (such as Blue). Mileage may vary on other flavors of RGB IC chips, depending on their pinout.