RGBW via DDP from XLights

[Fonzi03]

**Is your feature request related to a problem?
Yes

Normally in XLights I can save a sequence with the "String Type" as RGBW, and "RGBW Color Handling" to either one of the RGBW settings (I typically advanced or R=G=B->W) or RGB Only depending on what sequence I am running.

For accent lighting I like to use the Warm White channel, but for musical sequences I like to use RGB only.

Right now the way I have it working I have to set XLights to
String Type: RGB Nodes
RGBW Color Handling: RGB Only

Then in WLED I have:
Auto-calculate white channel from RGB: Accurate

This works, kind of. It lets XLights/DDP data send accurate colors with the expectation that White will always light the 4th channel instead of mixed RGB.

When I try to use WLED though it always lights the White and RGB pixels simultaneously when trying white.

**Describe the solution you'd like

It would be best if WLED could handle XLights/DDP data sending RGB and RGBW allowing the use of different sequences to have different effects.

At the same time it would be nice for WLED effects to work properly when not receiving DDP data. IE being able to add/remove/exclusively use the white channel.

[blazoncek]

Most of the effects do not take separate W channel into account. So there is no way, unless those are rewritten, to have them use W channel except in Auto Calculate White mode.

As for RGB vs. RGBW DDP support, those exclude each other.
The data structures are different.

Dynamically switching between RGB & RGBW as far as LED types go, is impossible but manipulating RGB to be displayed on RGBW strip is possible, the other way around may produce unwanted output.

We will welcome a PR that does that if you wish to tackle it.

[Fonzi03]

I have a falcon board that handles it just fine.

My assumption is it stills sends the 4th channel but sends it 0 while R G B are all 255 the controller doesn't interpret that as white and light the white channel since it's expecting the 4th channel to be the data for white.

The sequences are saved and rendered this way and no changes are done to the controller dynamically.

Because WLED is interpreting the full RGB as white I lose the ability to have a bright white and warm white.

I unfortunately do not have the skill to help write the code.

[Fonzi03]

Tested again today and have some more feedback.

This would be fixed if WLED simply handled 4 channel DDP data. It seems as if WLED is only able to handle 3 channel DDP data. When I set XLights to 3 channel (even though theyre 4 channel nodes) I have to manually go into WLED and set the total pixels since I can no longer use the Upload Outputs from XLights as by going from 4 channel to 3 channel I lower the total "pixel" count.

IE 100 pixels of 4 channel is 100 pixels.
Changing that same pixel to identify as 3 channel makes it appear as 75 pixels.
This causes an obvious issue that channels dont line up with their corresponding pixel.

If this one change was made that when a 4 channel pixel is selected the DDP input is expected to handle 4 channels. Then Auto Calculate white channel wouldn't be needed. It would simply assign the 4th channel to the white led only.

This would allow users to do as I mentioned above, change their sequences to support the white channel when desired and not use it when not desired. Because when XLights is set to 4 channel but RGB only, it sends all 4 channels but doesnt send any values down the 4th channel just RGB.

[netmindz]

I am a little confused as while there is a comment at the top handleDDPPacket saying "handles RGB data only"

There is also code that calls setRealtimePixel passing the white value from the DDP data.

What happens when you configure XLights to send RGBW data @Fonzi03 ?

[blazoncek]

@netmindz RGBW has been implemented in DDP not so long ago. It is handled correctly AFAIK.
The issue, as I see it, is to have WLED configured as RGB and send it RGBW via xLights (or the other way around).
This is doable but needs correct handling in the code.

[Fonzi03]

If you could tell me which settings to use in WLED to accept 4 channel RGBW DDP I will try that.

The way I see it up is because it was messing up the channels if I had the auto calculate to white my channels were off.

I can try again today and take some pictures/screen shots.

My preference would be for 4 channel DDP to work as expected and let XLights handle choosing if the 4th channel goes high or if just the RGB channels do.

If it works that way I get to use the warm white channel when I want and use theoxed RGB (without warm white) at other times which is exactly what I'm looking for.

[netmindz]

There isn't a config option as such, the code just looks at the data and calls setRealtimePixel with the data you sent.

So if you can try sending RGBW and see if that works as expected.

If not then we can look into if/why the white value is being recalculated deeper in the code

[Fonzi03]

@netmindz
With XLights set to the following:

And WLED set to:

I set color bars to:all White, then Red, then Green, then Blue
XLights preview

Actual output on LEDs (board is in the attic so this is just a small test strip hooked up:

As you can see I am not getting solid color bars and the white channel seems to always be off.

[blazoncek]

FYI I have checked the code and WLED will correctly display either RGB or RGBW DDP packets received. Regardless if that particular WLED device has RGB or RGBW LEDs attached. They have to be configured correctly though.

The information of channels is part of the DDP packet and if your receiving WLED is correctly configured (correct LED type attached) it will either disregard W channel or display it as it was sent from sender if sender is configured as RGBW. If sender is configured as RGB the W channel on receiver will always be 0 (unless you configured auto white calculation in which case W will be calculated from RGB information).

[netmindz]

There is clearly something going wrong with more than just white @Fonzi03 given you are getting RGB LEDs lighting up got anything other than their own colour.

I am assuming that if you use WLEDs own effects you see exactly what you expect? E.g setting solid red then you see only red lighting up etc?

I'm not familiar with xlights so I can't confirm your settings listed are appropriate for RGBW DDP, so I would advise you double check these with that community

[Fonzi03]

@netmindz yes I believe effects from WLED are accurate.

It's only incoming DDP data that's incorrect. When I use these exact same settings on a Falcon F16v4 the white channel lights as expected. It's just in WLED that it's doing as above images show. I know the XLights side very well and when the settings are set to what they should be in XLights it doesn't work properly.

I posted my WLED settings above, if something is wrong please let me know and I'll correct it. Otherwise I understand your saying WLED should handle the white properly so long as the pixel type is accurate and the data coming in is good but it doesn't seem to be doing that subjectively.

These are my current setting in WLED for the non test port. In XLights I have to set the pixel type to RGB to get this to work instead of RGBW.

What I assume is happening is that when auto calculate white is selected, if R=G=B --> W. At least that's the behavior I'm seeing, regardless of my XLights setting I cannot get it to light the white channel properly.

[blazoncek]

Auto white calculation means disregard incoming W channel completely.

[Fonzi03]

Auto white calculation means disregard incoming W channel completely.

And light the white channel if R=G=B

The problem is without that selected XLights DDP data shows the images I sent above, the first image is sending all white, second red, third green, fourth blue. In each frame you see all 3 RGB and a blank 4th pixel, incrementing in order 1x pixel per color change.

[Fonzi03]

Could someone please either confirm this is a bug or tell me whatever other details you need to confirm whats happening here. I can provide wireshark logs if necessary.

[netmindz]

As already mentioned, the fact that for pure R G and B on their own is lighting up more than just the related pixel makes me think that this isn't related to the value of the W channel at all.

Either what is being sent is wrong or the parsing of the data is wrong.

I don't know if wireshark can decode DDP, but it would certainly be useful for you to capture when output is pure red, pure green and pure blue so we can confirm that is as we expect to see

[Fonzi03]

As already mentioned, the fact that for pure R G and B on their own is lighting up more than just the related pixel makes me think that this isn't related to the value of the W channel at all.

Either what is being sent is wrong or the parsing of the data is wrong.

I don't know if wireshark can decode DDP, but it would certainly be useful for you to capture when output is pure red, pure green and pure blue so we can confirm that is as we expect to see

In the above post I sent pure white, red, green, blue.
The images that followed were what is presented when those are sent and the settings are set how I believe they should be.

When I do the exact same test with an F16v4 it works perfectly, therefore the data being sent is accurate and WLED parsing must be the problem.
*edit: as does FPP with a pi.

The other bit which would be helpful is if someone could confirm which WLED settings are correct.

Per what was described above I believe the expected settings should be:
SK6812
Auto-Calculate White: none

The only way I can get it to work properly is with these settings:

XLights must be set to the following:
Protocol: SK6812
String Type: RGB (this means it will only send 3 channel data)

WLED must be set to:
SK6812
Auto-Calculate White: Accurate
I didnt take a picture since its showing properly
String Type RGB.zip

With these settings it is off by one channel and never lights the 4th channel (white)

XLights settings (which is what they should be set to)
Protocol: SK6812
String Type: RGBW (this means it will send 4 channel data)

WLED must be set to:
SK6812
Auto-Calculate White: None

String Type RGBW.zip
Pictures only of White and then Red, since there is zero change between the two. Except if you look closely you can see the colors shifted by one pixel. Again this is indicative of the channels not being correct, but once again on my falcon board it works as expected. Whats a little hard to see in these pictures is that each 4th pixel is black.

[blazoncek]

Dear @Fonzi03, as you are (currently) the only one with this issue, you will need to debug and find the problem on your own.
Once you find it, you are welcome to provide a PR with a fix. Unfortunately we do not own such set-up to diagnose on our own and even then, as having RGBW LEDs in xLights display ATM is a rarity, this issue is low on priority.

[netmindz]

Just to be certain this is only an issue with DDP?

i.e if you select solid effect in WLED and select red, green blue and white you see correct output? Both with white selected and not within WLED?

[netmindz]

Please also supply the wireshark data as requested

[Fonzi03]

Please also supply the wireshark data as requested

The two zips I provided have all the Wireshark data in them. Each capture is filtered to the IP that is sending the DDP data.

Yes regular effects work as expected it's DDP only thats problematic.

[Fonzi03]

Dear @Fonzi03, as you are (currently) the only one with this issue, you will need to debug and find the problem on your own. Once you find it, you are welcome to provide a PR with a fix. Unfortunately we do not own such set-up to diagnose on our own and even then, as having RGBW LEDs in xLights display ATM is a rarity, this issue is low on priority.

As stated previously I am not capable of that, if I was I would've already fixed the issue and submitted a PR.

I do have all the equipment and skill required to test and debug and am more than willing to do so.

I'm even willing to live diagnose if someone were available.

Otherwise any instruction you can provide I'm open to trying and providing the data.

Everyone using XLights is having this issue. If you go to the XLights groups or the zoom room they will tell you to set it up as an RGB pixel and use Accurate for the auto calculate.

So therefore this issue affects 100% of users with at the very least sk6812 but I presume all RGBW users.

[netmindz]

Sorry, it wasn't clear the zips contained the wireshark captures

I just had a very quick look and there is no filter to allow automatic decode, but just looking at the raw data both blue and green seem very similar and almost entirely 00 as hex. I was expecting to see a repeating pattern of that equates to 0 for the channels not active and non-zero for the one that is.

How many pixels were you sending data for In that capture?

[Fonzi03]

Sorry, it wasn't clear the zips contained the wireshark captures

I just had a very quick look and there is no filter to allow automatic decode, but just looking at the raw data both blue and green seem very similar and almost entirely 00 as hex. I was expecting to see a repeating pattern of that equates to 0 for the channels not active and non-zero for the one that is.

How many pixels were you sending data for In that capture?

Sorry about that, should have been more clear in my post.

I know the basics of Wireshark, if you know how to filter for exactly what you're looking for I can do that tonight.

There are somewhere close to ~700 or so pixels across 7 physical outputs. I can get an exact count if needed.

All of the lights are working as you can see so the data is making it through. When in RGB mode there are no skipped pixels like in RGBW mode.

[netmindz]

I have tested with WLED sending RGB and RGBW from WLED to WLED and that works exactly as expected, including the white channel

I have no idea where to start with trying to setup xLights and do not have the time to test, however looking at the code I see two possible issues.

1. The way the code handles DDP packets that also feature timecode looks a little funky (but might be ok). Try disabling timecode in the xLights DDP output

2. There is reference in the code to how 4 channel data is identified being "data type 0x1B (formerly 0x1A)" - I have no context for when/why this change was made, but it might be xLights is sending 0x1A still? The traffic you are looking for is on port 4048 see http://www.3waylabs.com/ddp/#Packet%20Format for the format, which says RGBW is 011, which is what the WLED code is looking for

[djericharding]

Just thought I'd chime in here to add that I too have experienced this exact issue. I run my roofline LEDs (SK6812) using WLED on a DIG Quad. My Xlights sequences run fine when using E1.31 but not DDP. This is true if outputting directly from Xlights or from FPP on a raspberry pi. My testing produces the same results as described by @Fonzi03.

[Fonzi03]

Just thought I'd chime in here to add that I too have experienced this exact issue. I run my roofline LEDs (SK6812) using WLED on a DIG Quad. My Xlights sequences run fine when using E1.31 but not DDP. This is true if outputting directly from Xlights or from FPP on a raspberry pi. My testing produces the same results as described by @Fonzi03.

It was just suggested by one of the xlights devs to try e131 as they believe that works, but DDP is handled differently in wled than others.

Also, I wanted to make the comment that testing as a ddp output of wled to a DDP input of wlet isn't truly a good test because if wled has DDP data not proper, one would assume that it would be the same for the output as it is for the input. What I'm getting at is you should use somebody else's DDP output, not wled If you are trying to test. I have so far tried an x-lights test output, or" output, two lights" and I have also tried fpp using an xlights generated sequence. I could try testing DDP data directly out of fpp because that is not the same as xlights just as another test point if that would be helpful.

[netmindz]

I've asked the creator of the DDP if they have any tools to parse the output or other form of test harness and they do not, which is pretty rubbish.

You just end up with situations like this where two different implementations of the protocol have issue and no idea which is wrong and in what way

[Fonzi03]

I've asked the creator of the DDP if they have any tools to parse the output or other form of test harness and they do not, which is pretty rubbish.

You just end up with situations like this where two different implementations of the protocol have issue and no idea which is wrong and in what way

I understand and totally agree about the testing.

What I can say is whatever XLights is doing seems to be the standard right wrong or otherwise as there are many boards which integrate with them, all of which work properly.

It's seemingly (so far at least) just WLED which is not working as expected.

I should be able to try e131 within a week but would much rather keep everything in DDP.

Is it worth connecting with one of the XLights devs? So you guys can confirm the differences between the two and see who is best to update their end? One of them was active in my thread related to this on their repo.

[netmindz]

Yeah it would be good to connect with them and also please share two xlights project files, one with RGB and one with RGBW

[Fonzi03]

Yeah it would be good to connect with them and also please share two xlights project files, one with RGB and one with RGBW

I'll try to upload both projects tonight. Been working on a 10A/port power distribution/data boost board that I'm finally wrapping up.

Edit: I also dropped a message for @computergeek1507 as he was replying in the XLights repo

xLightsSequencer/xLights#4882

[computergeek1507]

I think you need to implement a "DDP RGB input type" similar to what is implement for E131 or use the E131 setting that already exists