Maximum length data wire LEDs
(2022-12 update!)
This whole article talks about the data wire length from the controller to the first LED, going from LED and LED below does not apply!
From LED to LED the signal is much less powerful then from a (QuinLED-Dig) controller. A different solution should be used for “gap bridging” behind an LED such as the QuinLED-Data-Booster!
A common question that gets asked is how long the data wire to the LEDs can become before data signal integrity issues start becoming an issue, often visible as flickering of the LEDs or other sporadic/corrupt behavior.
TL;DR version….
Generally you should be ok up to 10m/32ft with AWG26 or thicker for your LED data wires!
2022 update
The original tests were all performed using a single separate conductor for the data signal as is most often used with LED strips (you run a 2-wire power cable + a data wire). In other scenarios (such as Christmas lighting) other type of cabling (xConnect, etc.) is more often used which is a 3-wire cable having Positive+Negative+Data all in a single cable. This changes how the data signal behaves in a big way and it requires different cable conditioning of the LED signal, please see here for more information about that. Since the early 2022 update the QuinLED-Dig boards now all have a resistor switcher onboard so you can adapt the data signal to the type of cabling you are using!
Outside interference and noise immunity (new conclusions!)
Although the below information is still valid there are some new findings we have observed since then. In a very noisy environment outside interference can influence LED data signals. In our new findings we’ve noticed that running a separate data-wire vs having a bundled data-wire (data+GND next to each other) changes how data behaves (thus requiring a different resistor) and that having a bundled cable provides better noise immunity for long runs then not having GND close to it.
So although running a separate data-wire is generally still fine in most cases, if you are experiencing outside interference (AC lines, PWM dimmed LEDs, etc.) it can help running a 2-wire (or 3-wire) cable instead. It keeps the data signal more tightly coupled to GND which in turn provides a better noise immunity for it. This does however require the 33R resistor mode as discussed! All current Dig-Boards have the resistor switcher for this included but if it doesn’t you can always use a data-booster to achieve the same result. But do remember, once corruption is introduced into the signal (basically it’s degraded) there is nothing which can fix it again so it’s best to start with the bundled line directly at the controller side.
Do I recommend running data together with GND or not?
That’s a tough one, I’m starting to lean towards running data+GND close together because of the noise immunity it can provide. Coupled with the proper data resistor it can still go great distances (I’ve tested it up to 60m/200ft!) but it doesn’t invalidate running without that at the same time. In the end the longer your data cable becomes, the more important noise immunity becomes. We can kind of also see that in our old conclusions below were increasing the conductor size helped the signal to survive for longer because it was less excitable by outside influences.
So in the end yes, I think a data+GND wire with a 33R resistor is a better solution then running single data-wires with a 249R resistor. In reality it will vary on the setup and the cables involved and even LED type and LED strip vendor and that’s why I built the resistor switcher into all boards now, having 2 values available can generally make any situation work properly.
Old version assuming single data wire not linked together with GND!
But, sadly there is no real good “one size fits all” answer to this. But let’s consider the following while testing:
- A level-shifter is used
- A 249Ω data line resistor is in place
- A separate wire was used for the data signal (no 2-wire or 3-wire cable with GND close to the data signal)
- If you do run 2-wire/3-wire cable with GND next to data, none of this article applies without resistor changes, please see QuinLED-Data-Booster article!
- Stable power including Capacitors, etc.
My LEDs run fine without a level-shifter?!
If you are thinking of running without the above features such as running addressable LEDs without a level-shifter. That can work….most of the time, sometimes. All addressable LEDs (5v or 12v) require a 5v data signal, all ESP8266/ESP32 send a 3.3v data signal. So although outside of the official specifications, yes, often using a 10cm/3inch cable with the 3.3v signal from an ESP into the 5v expecting LED works ok, until it doesn’t, if it works you are very likely right on the edge! So for any length longer then the LEDs right next to the controller, use a proper level-shifting setup.
Test scenario
Let’s take a look at the full testing scenario:
- Using a pre-assembled QuinLED-Dig board (QuinLED-Dig-Uno v3r5) with custom QuinLED-ESP32 and Ethernet
- Has a level-shifter to 5.12v in place
- Has a 249Ω resistor on both LED data output ports
- Has stabilized power delivery on the board (big and small caps)
- Custom DC-DC circuit for power delivery to make sure level-shifters always gets 5.1v
Power supplies:
- 5v 40Amp (generally outputs 5.15v)
- 12v 10Amp (generally outputs 12.125v)
For data line testing wires the following was used:
- 3x 5m/16ft piece of AWG26 wire (verified true copper)
AWG26 wire is actually pretty thin, but I felt this would give a good “worst case” real world scenario. It does have to be said that it can be beneficial the longer the data wire has to become to make it a thicker wire up to say AWG18. This will likely keep the signal intact over longer distances.
3 sets of AWG26 to test different total lengths
(do not leave the coiled up like this while testing!)
Test strips 5v
For 5v the following strip types where tested:
- Generic ws2812b OLD (4 years old)
- BTF-Lighting ws2812b New (6 months old)
- BTF-Lighting ws2812b-ECO (6 months old)
- BTF-Lighting sk6812 RGBW (6 months old)
Test strips 12v
For 12v the following strip types where tested:
- Generic ws2811 60LEDs/m (3 years old)
- BTF-Lighting ws2811 96LEDs/m (bright and non-bright variant) (6 months old)
- BTF-Lighting ws2815 60LEDs/m (1 year old)
- Generic ws2815 60LEDs/m (6 months old)
- BTF-Lighting sk6812 RGBW (2 year old)
Test procedure
For each of the LED strips I tried it with 1x, 2x and 3x 5m/16ftwires in the data path. So:
- 5m/16ft
- 10m/32ft
- 15m/48ft
Each time connected using WAGO clamp blocks to extend it. The data wires were spread out in the room to not cause any interference from “coiling them up”.
Test result conclusions
I could write out all the testing results here, but that would make this even more boring, you just want to know how long this data wire can become already.
In my testing I noticed the following:
5m/16ft is always ok
None of the LED strips mentioned above had any issues running them at 5m/16ft data wire distance even with the relatively thin AWG26 wire.
10m/32ft is mostly ok
All LED strips again worked fine at 10m distance except for the older ws2812b strip which would very sporadically show a glitch.
There have been some revisions to the ws2812b LED package/chip over the years where in the more recent revisions it has become more sensitive to data at lower voltages (hence they now often work with a very short wire and 3.3v, still 5v is highly recommended!).
15m/48ft can be ok….
At 15m/48ft some issues started to occur. The old ws2812b strip I had really started showing issues, lots of flickering and errors visible in the patterns.
The newer ws2812b and ws2812b-eco did better, but also showed some errors.
At this distance also the 12v strips such as the ws2811 started to show issues.
5v sk6812 and 12v ws2815 (both data connections into a single connection block after a single data wire to the block) seemed to do best, it mostly seemed to display everything ok but I felt like it was right on the edge. sk6812 seems to be best in regards to data integrity with a weak data signal in general.
(OLD) End conclusion
So even with a relatively thin wire but combined with a proper level-shifted setup running up to 10m/32ft generally worked fine for all types tested. Going longer then that started to introduce problems but could likely have been solved stepping up to a thicker wire (I have seen better results using 15m/48ft and AWG18 for instance).
–update
Testing with 20m/64ft of AWG18/0.75mm2 wire showed perfect results on all strips as long as the wire wasn’t close to any source of interference.
–2022 update
Please see above for explanation why this is the case!
Do not leave wire spooled up like this when running LEDs, un-spool it!
Another thing to consider though is that this type of signaling really isn’t meant to travel long distance, there are other solutions for that such as differential signaling (might be more about this in the future 😉 ). The main reason is that the current single line signaling picks up more and and more noise/influence from outside the longer it gets. At some point the noise will become too strong for the data signal to survive intact and cause corruption visible on the LED strip.