Anybody know what the latency is with WLED and xlights? Or any way to reduce it.
Can you clarify what you are trying to do?
In general network latency is the only latency. I run wled with xlights and see no visible delay.
5ms up to several seconds.
It depends on a few factors, like the protocol, the number of LEDs you are trying to drive and the signal strength of the ESP used.
For the lowest possible latency, I highly recommend using the DDP protocol (instead of E1.31) and using a board with wired Ethernet instead of WiFi. (e.g. QuinLED Dig boards with ethernet, or an Olimex ESP32-POE). If the installation requires using WiFi, choosing a board with an external antenna also helps immensely.
1 Like
I’ve never heard of DDP, I’m an events system tech so always DMX, Artnet or Scan so will have a read on DDP.
At the moment I’m Using a D1 mini pro with an external antenna.
Is the WT32-ETH01 any good? Just getting into xlight - on a budget. And i can get a WT32_Eth01 and a level shifter for $15 compared to $100 NZD for the other boards.
Kev
The DDP protocol is defined here DDP PROTOCOL it is a lot simpler that E131 or ArtNet. In our dev branch we DDP implemented and it works well, but not great. There are things that need to be worked out. Does brightness get set on the sender or receiver? Power On set on the sender or receiver? Gamma, etc What happens when the UDP signal stops. Over the weekend I started on E131, but my first attempt did not work. Since I may be using xlights/fpp too and want to use E131, I would like to get it to work so I dont have to switch the WLED recievers between DDP and E131.
1 Like
Regarding brightness: WLED already has brightness override checkmark which, if checked, will ignore brightness set on receiver so only sender will control it.
This leaves the choice to user if he/she wants double brightness adjustments.
It may not be obvious at first glance though.
Regarding power: Sender will always override power if above checkmark is set since it will define target brightness which is effectively a WLED power state.
Gamma is a more tricky topic. I would remove gamma correction from sender and only apply it on receiver. The same would go to colour correction.
When UDP signal stops WLED now reverts to a state it was before realtime UDP data. I would assume this to be expected behaviour.
It’s fine for prototyping inexpensively. It’s not particularly stable, occasionally locks up. I am now trying Twilight Lord’s ESP32 boards and shields, and they are much more stable.
As for brightness: There are many thoughts on this, and here I disagree with blazoncek.
It really depends how you are managing your props, year-over-year. I prefer to offload as much processing as possible, so I would recommend disabling any “smarts” from the controller (including gamma and brightness), allowing the sender to adjust colors as needed. This way, you always know what the pixels are seeing. [edit – e.g., xLights software provides the ability to configure these settings for a given string of pixels]
But, this is an area where people disagree. There are benefits to both models. The important thing is that you (1) document your choices, and (2) review the docs when your forget. 
If you do not check “Force max brightness” in Sync settings on the display device it will use its brightness setting. And if you set controller’s brightness to 255 that will effectively enable you to use each of display’s brightness to affect the net brightness alone and have brightness adjusted individually.