DDP protocol - a way to create real-time LED animations via WiFi - OBK, xLights, configuration
DDP is a connectionless LED light control protocol based on UDP. DDP supports various color formats, but usually 24-bit RGB or 32-bit RGBW is used. One packet can contain multiple colors, so DDP can also be used to control LED strips such as WS2812. By using connectionless UDP (as opposed to TCP), DDP is suitable for real-time applications and allows you to create fast and responsive animations. The disadvantage of this solution is the lack of retransmission of the packet if it does not reach its destination, but when this protocol is used for animation, it should not be noticeable because new data is constantly being sent and nothing will happen if one packet is lost.
Detailed DDP documentation can be found on the 3waylabs website:
http://www.3waylabs.com/ddp/
But its popular implementations are much more stripped down.
For example Tasmota only loads RGB data from a given offset in the package:
Code: C / C++
IN OpenBeken it works similarly, but there, pixel groups for LED strips are also supported:
Code: C / C++
This is really enough to animate any groups of our LEDs and "smart" strips via the WiFi network.
How to send DDP data?
There are many tools that support DDP, and it`s just as easy to send DDP packets from your own program, but one of the more popular ways to create and manage animations is xLights : :
xLights allows you to combine independent LEDs into groups, create advanced effects, arrange them freely in 2D and 3D space and configure them on the timeline.
To send data to a device, you only need to know it IP address . In this case, it is worth using a fixed IP or IP reservation, otherwise after restarting the router our LEDs may get mixed up...
As for the device itself, I will use an LED lamp from OpenBeken:
On the side OBK turn on the driver DDP : :
startDriver DDP
It is best to enter this in the startup command so that the controller starts every time you reboot. After that, we restart the device:
Then, on the xLights side, we open the Test options from Tools:
We mark the channels of our lamp and make sure on the OBK side whether the lamp is turned on.
As a result, the LED plays a test animation:
The LED strip can be operated similarly .
On the OBK side, the LED strip driver must also be turned on. You also need to specify how many pixels we have on the strip itself. As in this topic:
OpenBeken WS2812B driver (compatible with SM16703P etc.) - short script presentation
// start DDP
startDriver DDP
// start WS2812 etc driver
startDriver SM16703P
// init
SM16703P_Init 50
On the xLights side we also change the number of channels:
Result:
In case of color incompatibilities, we can also set the GRB standard:
// init
SM16703P_Init 50 GRB
Of course, the video only shows a test animation, we can send any combinations we want from xLights, but more about that in the xLights topic.
Summary
DDP is an extremely easy-to-use and useful protocol for creating LED animations. It allows you to control both individual lamps and LED strips. Combined with systems such as xLights, it allows you to create complex LED animations for an entire room or even a house, which I will try to discuss in the next part.
DDP is so simple that we can basically send such packets from our own program or receive them in our own program, which I will present soon.
Basically, the only downside to DDP that I see is what also makes it very light and fast - its connectionlessness. DDP is based on UDP, which does not offer retransmission in the event of a lost packet, so if our target use of DDP assumes that we will send one packet that will set the color and forget about the light, we may be quite surprised if this packet does not arrive.
The solution in such a case is to use MQTT or at least HTTP, both of these protocols operate on TCP, which ensures greater transmission reliability than TCP.
The entire organization of DDP-based effects is so cool that we don`t have to worry about cables and can freely change the configuration many times in the software itself. On the hardware side, all you need is that the lamp/LED has power and access to WiFi, and you can control it.
Has anyone reading created LED effects based on DDP?
The possibilities are really great. Feel free to comment.
p.kaczmarek2 wrote 11795 posts with
rating 9917 , helped 563 times.
Been with us since 2014 year.
Comments
Add a commentHi guys, I'm testing DDP protocol on RGBCCT GU10 bulbs with OpenBK firmware: - when it finishes receiving DDP packets the bulb stays off (black) and does not return to the previous state, while in... [Read more]
Sure, I can implement RGBW DDP for you. Can you specify how do you send RGBW DDP packets and how OBK should respond to them? What is your current device config? What do you mean by "return to previous... [Read more]
I would like to send DDP packets from Xlight or WLED controller, I don't know what OBK should answer, I'm not an expert in programming; yes, when the DDP animation stops the light bulb remains black... [Read more]
Can you tell me how to send RGBW packets from XLights, so I can recreate the problem on my side? Currently I can clearly see, that both Tasmota and OBK parses only RGB values, no W, so I need to find... [Read more]
ok, as soon as I can I'll flash via OTA; Athom WLED bulb already works with DDP RGBW and WLED DDP controller for example ESP32: https://obrazki.elektroda.pl/9723086500_1733410444_thumb.jpg but... [Read more]
I see, that can be very useful indeed. For the clarity, can you also attach dump of RGB only packets? Just make 100% sure to use RGB only mode, and not RGB color in RGBW mode... This is because I need... [Read more]
I configured the bulb in Xlights with only 3 channels RGB here is the log: Info:DDP:Packet: 41030001000000000003FFFFFF, Length: 13 [Read more]
Now we can do comparison. So, there is one more byte and length is one more higher. 410F0001000000000004000000FF 41030001000000000003FFFFFF So, what is your OBK JSON template currently? Do you want... [Read more]
I would like it to go white around 4000k so half between WW and CW [Read more]
Ahhh, so the fourth byte should set BOTH Cool White and Warm White channels? Is this some kind of standard, or should it configurable? Another question. If I set OBK brightness to 50%, and then send: ...... [Read more]
It should be a standard where there are cold white LEDs and warm white LEDs DDP should set the brightness based on the configuration inside Xlights, so it overrides the brightness setting [Read more]
I see, I've added experimental parsing, either RGB if len is 3 or RGBW when len is 4 (then Cool is 50% and Warm is 50%), can you update to 1.17.795 and check how it behaves? I wasn't been able to test... [Read more]
@tech1977 any news on testing? [Read more]
Hi, sorry for the delay, as soon as I can I'll test it and let you know [Read more]
21337805[/pHiostid] Hi, I tried version 1.17.795 with Xlights and enable DDP driver, now channel 4 (W) works !!! on the standard test of the individual channels of Xlights, but if I do the test... [Read more]
It should be very easy to check this. Flash the "DDP dump again: https://github.com/openshwprojects/OpenBK7231T_App/pull/1457 And then do A-B-C-ALL cycle and copy packets data to forum. Then it will... [Read more]
when I do the RGB Cycle test by selecting A-B-C-ALL A (Red) is activated together with channel 4 which is White, so maybe this test is only for 3 RGB channels: https://obrazki.elektroda.pl/4625245700_1733923884_thumb.jpg... [Read more]
Well, if that's the content of sent packets, then there is no suprise that OBK behaves in such a way. I would rather expect the RGB test to send packet with 3, not 4 colors. You can see 04 (hex 4) in the... [Read more]
yes, I still have to study Xlights, now I just have to figure out which GU10 with DDP is best for me to buy, I would prefer something with a fairly narrow light beam [Read more]