OK so the WS2813 and WS2815 LED strips have backup data lines, but does the backup data line have to be used? can you connect it up to a WS2812B (with correct voltage appropriate for the strip type) controller with one data line and expect it work? Will it work but just be dimmer because of the difference in operating frequencies?
OK so the WS2813 and WS2815 LED strips have backup data lines, but does the backup data line have to be used? can you connect it up to a WS2812B (with correct voltage appropriate for the strip type) controller with one data line and expect it work? Will it work but just be dimmer because of the difference in operating frequencies?
Initial assessment You’re comparing WS2812B vs WS2813/WS2815 strips and asking: - Do WS2813/WS2815 require the backup data line (BI)? - Can you drive them from a “WS2812B” one-wire controller? - Will they be dimmer due to different operating frequencies?
Direct answer - No, the backup line is not required. You can leave BI unconnected. - Yes, you can drive WS2813 and WS2815 from a single-data-line WS2812B-style controller, provided voltages and timings are correct. - No, they won’t be dimmer because of protocol/data frequency. Brightness is set by current and PWM duty, not by whether BI is used or by the 800 kHz data rate.
Detailed technical analysis - Protocol compatibility - WS2812B, WS2813 and WS2815 all accept the same 1‑wire NRZ protocol at ~800 kbit/s. Libraries/drivers that work for WS2812B typically work unchanged for WS2813/WS2815. - One caveat: WS2813/WS2815 specify a longer reset (latch) time after a frame (≈280–300 µs) than WS2812B (≈50 µs). Most modern drivers already use a long-enough reset; if yours hard-codes 50 µs you may see occasional glitches on WS2813/15.
- Backup line (BI) function - BI is a redundancy path (“break‑continue”) so downstream pixels can keep receiving data if a single LED’s main DI/DO path fails. - Leaving BI floating at the strip input is fine; the strip will operate normally via DI. - If you want first‑pixel redundancy, you may feed the controller’s data to both DI and BI at the strip input (often just tie them together near the connector, optionally via 100–330 Ω). That way, if pixel 1 dies, pixel 2 can still receive data on its BI line.
- Brightness vs “frequency” - Data rate (800 kHz) only determines how fast you can refresh the pixels; it does not change per‑pixel brightness. - Perceived brightness is determined by each IC’s constant current and PWM duty for R/G/B. Different families may have slightly different per‑channel current and gamma, so absolute max brightness can vary a bit between WS2812B vs WS2815, but that difference is not caused by data frequency and not by using or ignoring BI.
- Voltage and signal‑level points - WS2813: 5 V strip. Data input is 5 V‑logic compatible; many runs work with 3.3 V data over short distances, but a 5 V level shifter is safer. - WS2815: 12 V strip (three LEDs in series per color). Data input is 5 V‑logic compatible. 3.3 V data sometimes works but is marginal; prefer a 5 V data level (use a 74AHCT125/74HCT14 or a MOSFET level shifter) especially with longer leads. - Always share ground between controller and strip. Add a 220–470 Ω series resistor in the data line at the strip end and a bulk capacitor (e.g., 470–1000 µF) across V+ and GND at the strip input.
Current information and practical notes (OBK context) - In OpenBeken, the “SM16703P/WS2812” backend drives WS281x‑type strips. Typical steps: - startDriver SM16703P - SM16703P_Init <pixelCount> [colorOrder] (color order often GRB) - Optional: Anim/AnimSpeed for built‑in effects. - If you switch between WS2812B (5 V) and WS2815 (12 V) hardware, only power wiring changes; data/control commands are the same. Ensure your power supply and injection plan match the strip voltage and length.
Practical guidelines - Short runs, hobby setups: connect DI only; leave BI unconnected; it will work like WS2812B. - Reliability-sensitive installs: tie controller data to both DI and BI at the head of the strip to gain “first‑pixel” redundancy. - Long cables or 3.3 V MCUs: use a 5 V level shifter; keep signal ground solid; add the series data resistor and bulk cap; consider data re‑buffering every few meters.
Possible disclaimers - Vendor “WS2815/WS2815B” variants and clones can differ slightly in timing and max current. If you see odd behavior, increase reset time and verify color order and timing in your driver.
Summary - Backup line: optional. - WS2813/WS2815 work from a WS2812B‑style one‑wire controller. - No dimming due to data frequency; any brightness differences come from LED/driver current characteristics and power distribution, not from using/ignoring BI.
Questions for you - What MCU/controller and data voltage (3.3 V or 5 V) are you using? - Approximate strip length and cable length from controller to strip? - Do you want first‑pixel redundancy, or is basic operation sufficient?
You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
Considering how long are those AI-generated replies, maybe it is easier to just check datasheet:
It seems that BIN (Backup In) is just an optional shortcut around the previous LED, which is used when previous LED is broken, so the signal can continue. A very clever solution, I must admit...
Added after 2 [minutes]:
So, let's consider two scenarios:
1. L2 on my schematic is working - then it gets signal from DI and uses one pixel and forwards rest of the data on DO - ok, everything works. Then Ln on my picture receives that signal and continues
2. L2 on my schematic is broken - then signal on DI gets ignored and output on DO is dead - the strip would usually break at this point, but Ln (next LED) has BI connected to DI (the input) of L2, and Ln detects that L2 didn't send anything on DO, so it switches to DI, and gets signal from before L2. So, one pixel is skipped (L2 is dead), but strip works
Added after 9 [minutes]:
My conclusion: when connecting two strips together, connect DO to DI and BO to BI.
When connecting strip to OBK/WLED/ESP/any controller, connect both DI and BI to signal output.
Otherwise , if you don't connect BI to signal output, and first LED breaks, then you won't get any other LEDs to work (backup lane not connected)
We can try that as well with GPT, altough I would say it does not "create new ones" anyway, it just generates code that statistically fit the patterns from learning data. Still, maybe it would be better to guide it better, as you said.
Good question, I don't have a final idea for that. The main question is whether we put single RGB+CW animations in PixelAnim or separate them? Maybe it would be better to separate them.
I never really give much tought to single LED RGB animations, I feel like there is lesser demand for them. I am rather thinking about "DDP send" backend for PixelAnim or something. I would need to think of code organization for that, but basically, try to design a pluggable system where we can set:
- first 50 LEDs are WS2812
- next 5 LEDs are single DDP packets (specified IP) - RGB bulbs
However I haven't tried it yet, and I don't know much reasonable would that be, how many UDP (DDP runs on single UDP frame) packets can we reasonably send at which framerate
yes, I would like 'new', more, animations. I wonder what that would look like on the main GUI. A drop-down of ones to choose from? A long list of buttons like existing pixelanim?
Could some small code provide a crude sample animation for each on a page full of tiles from which the user can select? hmm
OpenBeken firmware, designed for Chinese WiFi modules with BK7231T, BK7231N, and similar chipsets, introduces a new WS2812 LED driver with an integrated animation system supporting WS2812B and compatible LED strips such as SM16703 and SM15155. The PixelAnim driver, enabled from release 1.17.600, allows per-pixel color control without scripting, and supports RGB IC plus dual PWM channels for Cool White (CW) and Warm White (WW) integration, useful for devices like Action and LSC lights. Users confirmed stable long-duration animation runs and correct color rendering, including GRB strip configurations. The firmware now officially supports SM15155 LEDs, making OpenBeken the first open-source project with this capability. Discussions include hardware considerations for adding CW/WW channels via transistors and resistors, and the possibility of swapping red and green channels for certain strips. Integration with Home Assistant (HA) is under development; currently, manual MQTT button creation is required to control animations, with documentation available for command usage. Future plans include exploring DDP protocol support and expanding animation options, with ongoing testing of RGBCW LED strips (1m, IP65, white PCB) ordered from China. Summary generated by the language model.
