Other Controllers and Hardware > Protocols - DMX/E1.31/DDP

What is DDP?

(1/8) > >>

What is DDP:
DDP is another protocol designed to transfer pixel channel data to a controller.  It's very similar to e1.31, but is more efficient and in some cases is easier to use.

Network efficiency comparison:
A DDP packet consist of a 10 byte header followed by up to 1440 bytes of channel data.   So less than 1% of the network bandwidth is "wasted" for non-channel data.   e1.31, on the other hand, has a 126 byte header followed by up to 512 bytes of channel data, thus wasting up to about 20%.   For large channel counts, DDP can significantly help reduce network traffic.

Channel configuration:
E1.31 data is always associated with a "universe".  Each universe has up to 512 bytes of data.   Thus, both sequencers and controllers need to handle mapping start channels of props/objects/strings/whatever to appropriate universes and offsets in the universe.  This is both error prone and confusing.   In addition, various controllers have certain restrictions as to whether a port can cross a universe boundary or whether a universe should be 510 channel (divisible by 3) or 512.    DDP eliminates all of that by using absolute channel numbers.  Each DDP packet includes the start channel for the data in that packet.

Listener/Controller configuration:
With e1.31, the controller needs to know if it has to be setup for unicast (only needs to open a single port) or multicast (needs to register on a separate multicast address for each universe).  In addition, the controller needs to know how many channels to expect on each universe and map them accordingly.   Again, this is very complex and generally error prone.  One wrong number entered and everything can appear messed up.  It's also important to note that this HAS to match what the computer is sending.  If they don't match, things won't appear correctly.  DDP just opens a single port and since the data packet has the start channel, it just uses that as it comes in.

DDP can include a flag in the last packet to say "this is all the data, display now".   Thus, the controller doesn't need to guess if it's time to display or not.  e1.31 DOES have the ability to use a separate sync from on a specific universe, but this also requires additional setup on both sender and receiver to implement, and very few controllers support it.   For things like large matrices, this can eliminate "tearing" or other artifacts as the controller knows "I have the full frame, display it" instead of trying to guess (or waiting for a 50ms timeout or similar)

There is one main disadvantage of DDP: it doesn't support Multicast.   For wireless controllers that have unreliable connections, multicast allows those controllers to drop off without impacting the rest of the show.  Also, multiple controllers can be configured to receive the same e1.31 universe via multicast.  Those situations should likely continue using e1.31.

Configuring FPP to accept incoming data (to display on a Matrix panel or hat/cape or similar):
With e1.31, you have to go to the Channel Inputs page and define all the universes you plan to receive.  There could be a lot of them.  Large matrices can have 10's or even 100's of universes.   With DDP, you do nothing.  As soon as you put FPP into Bridge mode, it always has DDP listening for data.   Again, there is NOTHING to configure for FPP.

Configuring xLights to send data:
For e1.31, in xLights, you need to figure out how many universes you need, how many channels per universe, etc... and either create a BUNCH of e1.31 outputs or a single "multi" e1.31 output.   Again, this needs to match what is configured on FPP.  For DDP, add a "DDP" output, specify the number of channels that are needed, enter the hostname/ip address, you're done.

For FPP instances that control a large number of channels of props, DDP can help a lot.  If you "normally" run the FPP instance in remote mode, configuring it as DDP in xLights (instead of a Null output) can allow you to "test" things live from xLights.  All you need to do is flip the remote to "Bridge" mode, and enable that output in xLights.   When it's ready, disable in xLights and put it back in remote.   It doesn't consume any universes or require extra setup or anything.

I have commented to David Pitts about adding support for DDP to Falcon controllers. His answer was positive but no date commitment. He has added ZCPP support to the newest firmware for the F16v3. This actually seems less involved, but I'm not a PIC or FPGA programmer. :(

Can someone please put together the use of "bridge mode" in FPP as it pertains to this function (DDP)?
I can assume a lot of things, but I'd rather get a clear and concise explanation of this from someone who can explain why this state in FPP.

Thank you.


--- Quote from: algerdes on January 10, 2019, 04:04:20 PM ---Can someone please put together the use of "bridge mode" in FPP as it pertains to this function (DDP)?
I can assume a lot of things, but I'd rather get a clear and concise explanation of this from someone who can explain why this state in FPP.

--- End quote ---

DDP is a more efficient way to send pixel data across a network.   
FPP does not require any configuration to *receive* DDP.  If you put FPP in Bridge Mode it will listen for DDP by default.  (it can still listen for E1.31 universes *if* you have them configured in Channel Inputs)
In xLights Setup, click ADD DDP and set the IP address of your Bridge Mode FPP and the range of channels you want to send to it.

Boom!  Done.  Easy Peasy

DDP seems to me like a game changer! Definitely going to follow this. I do have a question though, with DDP being more efficient, would it help reduce lag during show time? Currently running over 100 universes and whenever the display is running there are times (especially during "heavy" sequencing) where the UI to all my FPP's and Falcon's becomes unavailable, once the show/sequence ends I am able to access the UI again. If I were to switch to DDP, would this help lessen or eliminate that issue?


[0] Message Index

[#] Next page

Go to full version