logo elektroda
logo elektroda
X
logo elektroda

DDP protocol - a way to create real-time LED animations via WiFi - OBK, xLights, configuration

p.kaczmarek2 3399 26
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
  • Colorful LED bulb emitting pink light.
    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++
    Log in, to see the code

    IN OpenBeken it works similarly, but there, pixel groups for LED strips are also supported:
    Code: C / C++
    Log in, to see the code

    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 : :
    Screenshot of xLights software displaying the configuration of an Ethernet controller using DDP protocol.
    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:
    Screenshot of BK7231N LED control interface with settings for brightness and color.
    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:
    Configuration interface of the BK7231N device with DDP setting.
    Then, on the xLights side, we open the Test options from Tools:
    User interface of a lighting test program using DDP technology.
    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:
    xLights software interface with LED lights testing options.
    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.

    Cool? Ranking DIY
    Helpful post? Buy me a coffee.
    About Author
    p.kaczmarek2
    Moderator Smart Home
    Offline 
    p.kaczmarek2 wrote 11967 posts with rating 9997, helped 572 times. Been with us since 2014 year.
  • ADVERTISEMENT
  • #2 21333908
    tech1977
    Level 8  
    Hi 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 WLED bulbs after a few seconds they return to the previous state;

    - is it possible to implement RGBW DDP?

    now I continue with the tests .... ;)
    many thanks to all for the development
  • #3 21333916
    p.kaczmarek2
    Moderator Smart Home
    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 state"? So, if I, for example, set OBK LED to 100% green, and then do one minute of DDP animation, and then stop animation, it should return to 100% green?
    Helpful post? Buy me a coffee.
  • #4 21333950
    tech1977
    Level 8  
    p.kaczmarek2 wrote:
    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?


    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;

    p.kaczmarek2 wrote:
    What do you mean by "return to previous state"? So, if I, for example, set OBK LED to 100% green, and then do one minute of DDP animation, and then stop animation, it should return to 100% green?


    yes, when the DDP animation stops the light bulb remains black even if it was on any color or white
  • ADVERTISEMENT
  • #5 21333957
    p.kaczmarek2
    Moderator Smart Home
    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 out how W structure looks like.

    Or maybe even better... can you get OBK binary from here:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1457
    This is modified DDP driver to dump hex packet data to Web App Log.
    So, I would need you to:
    1. download binary ffrom this PR, flash it to obk via OTA
    2. enable DDP driver
    3. send single RGB packet, give me hex dump from console
    4. send single RGBW packet, give me hex dump from console
    That way I can check exactly what kind of format parsing will suit your needs.
    Helpful post? Buy me a coffee.
  • #6 21334223
    tech1977
    Level 8  
    >>21333957
    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:

    Screenshot of dropdown menu in LED output settings in software.

    but WLED with Xlights the channel 4 (white) does not work, work with E1.31 protocol
    https://github.com/Aircoookie/WLED/issues/4141
    https://github.com/xLightsSequencer/xLights/issues/4882

    Added after 2 [hours] 55 [minutes]:

    >>21333957

    This is the test packet log sent by Xligths setting up the 4 channel GY gu10 RGBWW bulb
    CHANNEL 1 RED is ok
    Info:DDP:Packet: 41080001000000000004FF000000, Length: 14

    CHANNEL 2 GREEN is ok
    Info:DDP:Packet: 410B000100000000000400FF0000, Length: 14

    CHANNEL 3 BLU is ok
    Info:DDP:Packet: 410D00010000000000040000FF00, Length: 14

    CHANNEL 4 WHITE the light bulb remains black
    Info:DDP:Packet: 410F0001000000000004000000FF, Length: 14


    Screenshot of a lighting test software interface showing channel configuration.
  • ADVERTISEMENT
  • #7 21334496
    p.kaczmarek2
    Moderator Smart Home
    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 to be able to determine whether packet is RGB or RGBW in code. I guess.
    Helpful post? Buy me a coffee.
  • #8 21335096
    tech1977
    Level 8  
    >>21334496
    I configured the bulb in Xlights with only 3 channels RGB here is the log:

    Info:DDP:Packet: 41030001000000000003FFFFFF, Length: 13
  • #9 21335220
    p.kaczmarek2
    Moderator Smart Home
    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 that fourth component to go into Cool White or Warm White channel?
    Helpful post? Buy me a coffee.
  • #10 21335246
    tech1977
    Level 8  
    >>21335220

    I would like it to go white around 4000k so half between WW and CW
  • #11 21335275
    p.kaczmarek2
    Moderator Smart Home
    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:

    tech1977 wrote:
    >>21334496
    I configured the bulb in Xlights with only 3 channels RGB here is the log:

    Info:DDP:Packet: 41030001000000000003FFFFFF, Length: 13

    ... then should OBK be still 50% brightness, or 100%?

    To phrase differently - should DDP override brightness setting?

    Added after 15 [minutes]:

    Added groundwork, more changes soon:
    https://github.com/openshwprojects/OpenBK7231...mmit/ecad0835a30949fe1445ce7e0a35d21851be5829

    Added after 9 [minutes]:

    tech1977 wrote:

    I would like it to go white around 4000k so half between WW and CW

    Hmm:
    Screenshot of source code for the LED_SetFinalRGBW function with a highlighted section calculating values for Cool White and Warm White channels.
    Helpful post? Buy me a coffee.
  • #12 21335708
    tech1977
    Level 8  
    p.kaczmarek2 wrote:
    Ahhh, so the fourth byte should set BOTH Cool White and Warm White channels? Is this some kind of standard, or should it configurable?


    It should be a standard where there are cold white LEDs and warm white LEDs

    p.kaczmarek2 wrote:
    ... then should OBK be still 50% brightness, or 100%?
    To phrase differently - should DDP override brightness setting?


    DDP should set the brightness based on the configuration inside Xlights, so it overrides the brightness setting
  • #13 21336347
    p.kaczmarek2
    Moderator Smart Home
    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 it on physical device yet.
    Helpful post? Buy me a coffee.
  • #14 21337805
    p.kaczmarek2
    Moderator Smart Home
    @tech1977 any news on testing?
    Helpful post? Buy me a coffee.
  • #15 21340395
    tech1977
    Level 8  
    Hi,
    sorry for the delay, as soon as I can I'll test it and let you know
  • #16 21343303
    tech1977
    Level 8  
    [postid]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 RGB cycle A-B-C when it should display only red A lights up red together with white;
    even with the cycle A-B-C-All on A lights up red together with white, the other colors are correct;
    I am not an expert in Xlights (I am a beginner) but I do not think this is normal behavior, can someone help us with Xlights?

    Screenshot of Xlights software showing channel test for DDP driver.
  • #17 21343344
    p.kaczmarek2
    Moderator Smart Home
    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 be very easy for us to check whether XLights really sends the W component on (in 4 colors packets - R G B W), or is it a problem on OBK side.
    Helpful post? Buy me a coffee.
  • #18 21343491
    tech1977
    Level 8  
    >>21343344
    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:

    Screenshot showing DDP packet data information with a length of 14 and a hexadecimal data set.

    always from RGB cycle if I select R-G-B-W no bytes passes:

    Screenshot showing DDP packet data with highlighted segment 00000000.

    so only with the standard single channel test I can turn on channel 4 white, maybe it is correct and will work with animations?
    now I have to learn how to create a simple animation with some GU10 bulbs.

    Xlights was born especially to manage many pixels but in this case a bulb is a single pixel, does anyone know a guide or tutorial for bulbs only?
  • #19 21344435
    p.kaczmarek2
    Moderator Smart Home
    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 packet data, I would rather expect 03 there....
    Helpful post? Buy me a coffee.
  • #20 21344677
    tech1977
    Level 8  
    >>21344435

    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
  • #21 21358026
    mashgsm
    Level 15  
    Hello,
    Does the compilation under LN882H support DDP ??
    I have uploaded and despite adding the driver to the config, after a reboot DDP does not start.

    Is it possible to do something about this?

    Screenshot of the Command Tool showing a message about DDP driver not supported. .

    Greetings
  • ADVERTISEMENT
  • #22 21358037
    p.kaczmarek2
    Moderator Smart Home
    Please type "startDriver DDP" at the command line (not in autoexec.bat, but at runtime) and we will find out.

    If DDP is not enabled, then you need to enable DDP in obk_config.h:
    System online builds OpenBeken - firmware compilation for all platforms on Github .
    Helpful post? Buy me a coffee.
  • #23 21358129
    mashgsm
    Level 15  
    When I type in the logs I get something like this:

    View of system logs with a list of available drivers and connection status. .
  • #24 21358147
    p.kaczmarek2
    Moderator Smart Home
    Well there is no this driver in the build. Eventually I can include the build with DDP for you....
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1475
    Do you know what to do next?

    You can probably also use:
    https://github.com/openshwprojects/OBKotaTool

    BTW - what device do you have on the LN882H?
    Helpful post? Buy me a coffee.
  • Helpful post
    #25 21358155
    mashgsm
    Level 15  
    After uploading the compilation you prepared, everything works as expected.
    This is a regular 5W Smart 500lm GU10 LED bulb, which always had a BK7231 sitting in it. Having recently purchased 5pc to further expand my home lighting, this new chip came along and I had no experience with it before. The board also has no name, the pins I figured out how to connect by analogy to other boards with this chip. I checked and the date on the housing on the new ones where this chip sits is; 12/23, and where BK was 09/23.

    A circuit board with a chip against a finger, showing board markings and a PET capacitor. Interior of a 5W Smart LED bulb 500lm GU10 showing the circuit board and chip. Close-up of an LED circuit board with a chip and capacitor. Close-up of a Smart LED 5W GU10 bulb with technical markings. Close-up of a circuit board with a chip labeled as Lighting LN862HK1. .
  • #26 21358419
    p.kaczmarek2
    Moderator Smart Home
    Does this device already have a template on our list?
    https://openbekeniot.github.io/webapp/devicesList.html
    Helpful post? Buy me a coffee.

Topic summary

DDP (Distributed Display Protocol) is a connectionless LED control protocol utilizing UDP, primarily designed for real-time applications such as LED animations. It supports various color formats, predominantly 24-bit RGB and 32-bit RGBW, allowing for the control of LED strips like WS2812. The protocol's connectionless nature enables fast and responsive animations, although it lacks packet retransmission, which is generally acceptable in animation contexts due to continuous data transmission. The discussion references Tasmota's implementation of DDP, which processes RGB data from specific offsets in packets. For comprehensive documentation, users are directed to the 3waylabs website.
Summary generated by the language model.
ADVERTISEMENT