WLED icon indicating copy to clipboard operation
WLED copied to clipboard

Published 20 hours ago • verified publisher icon Aircoookie

DDP receiving strip white channel not working

Open blark opened this issue 3 years ago • 5 comments

What happened?

SK6812 White channel is not updating on the virtual strip (DDP network)

To Reproduce Bug

Set up two strips with 60 pixels, one connected directly and controlled via GPIO16 on ESP32. The other is a virtual strip over DDP, (also using ESP32 GPIO16 on the receiving WLED).

  1. Set effect to solid, color to default.
  2. Adjust white channel brightness slider

Observe that only the hardware controlled strip changes brightness of the white channel.

  1. Adjust the colour temperature (add warm) and the white LEDS do light up on the virtual strip
  2. Adjust the colour temperature to the far left (warm) and the white LEDs turn off on the virtual strip but not the hardware controlled strip.

Expected Behavior

DDP network virtual strip should match the hardware controlled strip

Install Method

Binary from WLED.me

What version of WLED?

WLED 0.13.0 b5

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

No response

Anything else?

No response

Code of Conduct

  • [X] I agree to follow this project's Code of Conduct

blark avatar Dec 03 '21 16:12 blark

DDP protocol (currently) does not specify RGBW support. We requested an update of the specification to support RGBW (and RGBW+CCT) from the authors.

blazoncek avatar Dec 03 '21 17:12 blazoncek

Ahh, thanks! Sorry for the false bug report then!

blark avatar Dec 03 '21 17:12 blark

I just got word from the author of the DDP spec! Basically the current data type byte is just in an idea/concept state and not formally defined. xLights, sending 8 bit RGB data, should have a data type of 0x0A based on the ideas given in the spec, but instead it uses 0x01 (and additionally seems to support some sync/discovery feature on 0x80). WLED too currently ignores the value of the type field assuming 8-bit RGB, and network DDP just sends out 0.

Just replied to the mail encouraging the author to formalize the data types. If he prefers to keep it the current way though, there is still the "custom" range 128-255 which we could use to "privately" discern RGBW and RGBCCT types (e.g. 0xD3 = RGB, 0xD4 = RGBW, 0xD5 = RGBCCT) and treat all other values as if they were RGB.

Aircoookie avatar Dec 06 '21 22:12 Aircoookie

@Aircoookie Any updates on this? Was surprised to find that it doesn't support RGBW. Is there a way we can contribute to this?

Karshilistic avatar May 26 '22 11:05 Karshilistic

@Aircoookie Any updates on this? Was surprised to find that it doesn't support RGBW. Is there a way we can contribute to this?

No. Protocol still doesn't define RGBW. It does allow it but in a non-standard/not defined way. DDP

blazoncek avatar May 26 '22 18:05 blazoncek

Happy to report that the RGBW is going to be added as an official type to DDP spec! I have just implemented this in 0_14 branch :)

Aircoookie avatar Sep 02 '22 01:09 Aircoookie