LED Burnout

I have a WS2811 pixels installed on my house. I have a standalone peak that is tough to get to so I have a long string of pixels then I ran wire from the end of that string back to the peak ~30ft of wire. What I find is that the first pixel after that long run burns out every year. Wondering why and what I should do?? Of course it is at the very peak of my house and extremely difficult to get to especially once there is snow on the roof.

What does your wiring diagram look like?

One potential issue is a long data line that acts like an antenna over the year, picking up random noise and spikes, that could kill and LED.

Hard to say more without more info on how you’ve wired this up.


Not sure if this is enough. I have 14AWG wire running from the end of the first string to the start of the second string.

Is your data connection using the same 14AWG wire?
For a 30’ run I would strongly consider changing the data connection to a TxRx differential pair (see: LongData lines in the KB)

While those are often used to deal with flicker and loss of data over long runs, they also add a layer of immunity to noise/voltage spikes picked up over the data run. Many of the TxRx boards have spike protection builtin.

They’re pretty easy to use and pretty cheap as well.
You don’t need anything spectacular for cabling, 22/4 AWG is small and works well. Others use Cat5e.

That looks like a great link. Do you happen to know if there are any TxRx boards that have voltage stepdown built in. My WS2811 are 12V so would be nice if I didn’t have to add a separate stepdown.

There are some listed as 30+V compatible, but I’ve had varying success with those.
Most of them just put a LM1117 chip on the board to regulate the voltage down for the MAX485 chip.

That works OK in some cases, but my personal experience has been way too many board failures where the regulator just dies. I’d include a small (1A or less) 12V->5V buck converter to deal with the power supply issue. Those tend to be more reliable and the power requirements for the TxRx pair is very small (<100mA).

Sounds good. I will give this a try. Thanks for all the help.

No probs, let us all know how it goes over time.

Real world knowledge benefits everyone :sunglasses:

For consideration - could you not reverse the data direction of the upper eave and run a line to the near end? then just list that string as a segment with reverse direction?

Next - I’d be curious how the pixel is ‘burning out’ - does it seem to be the actual LEDs? (maybe the nodes after still work but the colors are burned out on this one?) That might suggest some sort of overvoltage. Pretty easy to check with a volt meter if you suspect this. A large value capacitor at the connection might help smooth any voltage ripple.

Or does it seem to be something with the data transmit/receive (This node dies and all others after it, too)? With a long data line like that, you could get some voltage spikes if the impedance match is not close.

Are you running anything for an impedance match resistor? If not, you might try something. If you are, you might try more. For example - the last image in this article shows an underdamped impedance - you can see the voltage spike at the beginning / end of each pulse. Imagine with no resistor that spike would be even bigger and could damage the Rx/Tx part of the chip.

Sadly, the only way to know for sure is to put an oscilloscope on the line. The best ‘approximation’ would be to put larger and larger resistors in the data line until the string stops working correctly, then back down a few notches on resistor value so it is working correctly again and you’d be overdamped if anything - but at least no voltage spikes!

Mostly good ideas.
One note - the TxRx pairs have termination resistors builtin to specifically handle the reflected/mismatched signals.

That’s part of why differential signals work so well for longer distances, they try and match the impedance of their transmission lines. They also have circuitry and protection specifically for noise, spikes, and other nastiness (look up “Common mode rejection”).

The last (IMHO) benefit is that you do away with the need for data resistors completely as the Tx board is placed very close to the data source (ESP or previous LED) and the Rx board is placed very close to the LED strip.

Quindor offers a dif’ Rx/Tx pair that says it does 5v/12v and is likely of good quality:

Info: Diff-Solo - quinled.info
QuinLED Diff-Solo specifications - quinled.info
QuinLED Diff-Solo Buying Page - quinled.info

It looks dumb the way I have it but thats because I initially wired it up like the blue. I had issues with LEDs burning out which sucked because then I lost the rest of the strip on the lower level. I changed it to be the red that way, if I have a burnout I just lose the peak and everything else looks good.

Is there a way to reverse direction so I can wire it up like the green?

Wow. Definitely sorry to hear of all the burn-outs! What nodes are these?

To do the green, you’d have to physically reverse the data flow direction of the nodes, then program them as a reversed segment of nodes. But it seems like your blue scheme sort of did that - and you say, still burned out nodes. I suppose the absolute shortest run would be to come from the lower peak, out to the bottom of the upper and back to the peak, like this in magenta:

I definitely wonder if some are more sensitive than others. I’ve had strings of TM1804s on my eaves for the past 10 years (512 nodes total). I would say all the data runs are 30ft or longer by the time they get out of the basement, up to the eave, then fan out to various data points they need to be at. The ‘far end’ is likely 70ft or more. Over the decade, I’ve had two nodes where each had one color fail…they were just random in the string…never had an issue with any of the first nodes.

I don’t know if its anything special, but I used mosfet drivers as my ‘level shifter’ to get a good data signal. Conversely, I don’t have long node-to-node runs, all my length is controller-to-first node. But it seems like two nodes would be best suited for communication between each other.

I don’t suppose you have any strong sources of RFI? Power lines? WiFi modem? Ham radio? Tesla coil?, TIG welder? VFDs?

I guess one other thing to consider - I’ve found that a strong ground is just as important to data transmission as good data. If you don’t have good ground, you loose the ‘zero reference floor’ for the data signal.

I did have some other nodes acting up and found the ground line at the node was actually about 1.1V in reference to the actual controller ground. Tying in an extra power/ground injection point brought it down to more like 0.1V. I don’t know that this specifically burns nodes out, but can cause ‘white lock up’. Where you show white (drawing a lot of power) and the ground line floats up to a volt or two and the nodes can no longer ‘read’ the data to shut the white off.

There is no easy way to get the Data In point at the opposite end without physically reversing the strip (or run along Data In, TxRx, etc.).

If you do end up moving the Data Input side, you could also consider driving the 2nd Strip from a separate GPIO on the ESP32. It will still look like one long strip in WLED.

It sounds like you might be experiencing voltage drop or signal degradation due to the long wire run. This can lead to the first pixel receiving insufficient power or a corrupted data signal, ultimately causing it to fail. To mitigate this, consider using a thicker wire gauge for the run to reduce resistance or adding a power injection point closer to the pixels. You might also explore using a data repeater to boost the signal after the long run.

What am I doing wrong here. I have 2 pixels to test on either side. Here is what I am finding.

  1. The first 2 pixels are working.
  2. The TX light is on solid.
  3. No lights are on, on the RX board.
  4. The 2nd 2 pixels are on just solid white.

Whats even more confusing to me is when I disconnect the 5VDC converter then all the pixels work correctly but not LEDS are on the the TxRx boards.

I’m not familiar with those boards at all, so just a wild a$$ guess here.

But if I had to do it, the nodes on the left, I’d tie that data line to the Rx on the left board, then come out of the Tx on the left board and into Rx on the right board, then out of Tx on the right board into the nodes.

It seems like Rx should “receive” a signal and Tx should “transmit” - though the arrows you draw seem to suggest the opposite and I know some Chinese boards have the function reversed due to some ‘lost in translation’ issue.

Here is a thread with a similar question answered by Divsys and a few others ESP32 long data wire, any issues with this wiring?

Well I was in the process of switching Tx and Rx and noticed I didn’t have a wire stripped properly. With my original wiring I have both the Tx led flashing on the first board and the Rx led flashing on the second. Feels like progress but the pixels are still just on solid white.

I tried switching TxRx and the status leds stop flashing. I also tried bonding all grounds and that didn’t work either.

Tempted to just return these boards. Can someone send me a link to some boards that they have used for this on amazon canada?