DDP RGBW Not Working In Version 0.14.1 And Greater

DrAnonymous commented 3 weeks ago

What happened?

DDP RGBW with two controllers does not properly control the W channel on the 2nd controller. It displays black on any part of the strip that should be white.

To Reproduce Bug

Configure two controllers to work properly individually with WS2814 RGBW
On the first controller add a second set of outputs using DDP RGBW and the IP address of the second controller
Select solid colors on the first controller. All of them will work on the first controller and the second except for white on the second one.
My setup was ESP32 and ESP8266 both running 0.14.4. Early testing used 0.14.1 and 0.14.3. Switching who the first controller is did not change the result.

Expected Behavior

The white channel on the second controller should match the first.

Install Method

Binary from WLED.me

What version of WLED?

WLED 0.14.4 (build 2405180)

Which microcontroller/board are you seeing the problem on?

ESP8266, ESP32

Relevant log/trace output

No response

Anything else?

Code of Conduct

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

blazoncek commented 2 weeks ago

Please verify with 0.15 beta and report back. There were many changes already implemented in 0.15.

DrAnonymous commented 2 weeks ago

I loaded 0.15.0-b4 onto both controllers. It has the same behavior and the second controller turns black wherever white is supposed to be displayed.

I turned the Auto Calculate to None on both just for more testing. It does properly change both to white, but you can tell its only using the RGB and none of the white channel, which I think is correct.

blazoncek commented 2 weeks ago

Please post configuration (cfg.json) of both devices.

EDIT: I cannot find any flaw in the source. EDIT2: It would be beneficial if you could also capture (a single) packet using Wireshark.

DrAnonymous commented 2 weeks ago

Here's the 2 config files. I will see what I can do to capture a packet. controller 1 wled_cfg.json controller 2 wled_cfg.json

I was able to capture some data. Its a couple packets, so hopefully it gives some insight. wireshark capture.zip

blazoncek commented 2 weeks ago

You should disable autowhite mode. Wireshark capture does not show DDP traffic. Only broadcasts.

DrAnonymous commented 2 weeks ago

I tried to capture DDP traffic again and don't see any. It should be from 192.168.1.170 (my first controller) to x.x.x.171 (the 2nd one). I tried both of these as filters after capturing:

udp.port==4048 tcp.port==4048

7/8 - Still trying to capture traffic. I think my wifi access point is only sending data between the two, so I'm not seeing it on my network hub.

Do you mean to disable this one?

blazoncek commented 2 weeks ago

DDP uses UDP and is only outputting when LEDs are displaying.

All auto-calculate white management options should be disabled/none.

DrAnonymous commented 2 weeks ago

I went to set things up and test. I'm having an issue on controller 1 where its complaining about the maximim current not being set, but when I do it doesn't actually save. Not sure why. Also the memory free is no longer showing a real value.

blazoncek commented 2 weeks ago

b4 has an issue with ABL. it has no effect on operation and you can disable it for test.

DrAnonymous commented 2 weeks ago

Changed the destination IP to be an address connected via LAN and captured data properly. :)

50 packets of data with 10 virtual LEDs.

new wireshark capture.zip

blazoncek commented 2 weeks ago

DDP packets are ok (with white being 0x34). If there is a problem, it is on the receiving device.

DrAnonymous commented 2 weeks ago

It must be in the receiving code. The problem is the same when I switch controllers to be opposite (sender becomes receiver). I’m using ESP32 and ESP8266, so it doesn’t seem likely to be hardware related. Maybe I can use a debug build and see if anything shows up on receiver output.

blazoncek commented 2 weeks ago

I don't see anything wrong here.

DrAnonymous commented 1 week ago

I was able to figure out the problem. :) Bus::autoWhiteCalc() causes the white value to be stored as 0.

When controller 1 displays white it sends it in DDP as 0x000000FF. On controller 2, this becomes 0xFF000000 after the call to strip.setPixelColor(pix, r, g, b, w); in setRealTimePixel()

If you pick white on controller 2 (local control) its represented as 0x00FFFFFF.

This line in ::autoWhiteCalc() causes white to be set to 0 from the DDP representation, but 0xFF from local.

w = r < g ? (r < b ? r : b) : (g < b ? g : b);

blazoncek commented 1 week ago

I told you to remove/disable auto white management. If you disable it, no white calculations are done. See L85 if (aWM == RGBW_MODE_MANUAL_ONLY) return c;

DrAnonymous commented 6 days ago

I'm confused, That seems like a work around, not a fix. Shouldn't the DDP receiver be able to set how it want's to handle white calculations? The source of the DDP doesn't have to be a WLED controller and setting it to RGBW_MODE_MANUAL_ONLY may not work for other DDP senders.

Couldn't a check be done to see if its a pure white channel and if so, then don't replace the initial white value?

blazoncek commented 6 days ago

If you are doing auto white management, you are doing auto white management. No matter where. If you don't then colors are un-mangled.

Closing as not a bug.

DrAnonymous commented 6 days ago

If a user has both local light effects (via presets) and wants to use a remote DDP controller, doesn't a user now have to manually switch the setting all the time? I use my lights both for general lighting outside my house and for holiday effects and assume this is a common case.

Aircoookie / WLED