What is DDP?

[dkulp]

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.

Synchronization:
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)

DISADVANTAGE of DDP:
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.

[JonB256]

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.

[algerdes]

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.

[pixelpuppy]

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.

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

[jem5136]

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?

[JonB256]

Bridge Mode - when you put an FPP (Pi or Beagle) in Bridge Mode, it behaves like an E1.31 controller. It "listens" for input, generally on ETH0 but will also on WLAN0.  FPP running any v2.0 or higher version will accept E1.31 Unicast, E1.31 Multicast and DDP Unicast.

In my recent setup, I had 8 FPPs running in Bridge Mode, all connected by CAT5 to a 16port Gigabit switch, and all data was being sent from a RasPi 3B+ from its Gigabit ethernet port.

As far as lag goes, there was none. Ever. 154,000 channels (300 universes). I attribute the good performance to using CAT5 instead of Wireless and the use of DDP to all 8 FPPs.  I was also sending E1.31 to three FalconF16 boards (One V3, a V2Red and V2Blue)

[algerdes]

What I am looking for here is the reason someone would even have an FPP out there if all it is going to do is act like a controller.

About the only thing I can think of is that the FPP is acting as a "switch" or "router", parsing out the data that it receives to different controllers downstream from it.  Seems like a waste, having to do the extra processing at the second FPP when the first FPP or xSchedule Player can send directly to the controllers themselves.

[dkulp]

Because in many cases, the FPP instance IS the controller directly driving lights.    The two main uses cases are:


1) P5/10 panels - in this case the Hat/Cape is on the Pi/Beagle and the panels are directly attached.   By accepting DDP, we can get the large number of channels into the FPP instance much more efficiently to display on the panels. The large P5 setups can consume 100's of universes which is a pain to setup/maintain and isn't terribly efficient.


2) Pixels directly attached: the most common is the PiHat (2 strings of 800 pixels), but the BBB has a bunch of different capes that can drive up to 48 strings of 800 pixels each.   In that case, the Pi/BBB *IS* the controller.   Again, bridge mode allows it to get data from xLights to display on the pixels.   


There are a bunch of other outputs that FPP can do (various DMX, Renard, nRF24L01, PixelNet, raw GPIO toggles, etc...) that cannot be done easily directly from xLights/xSchedule. 


You cannot think of FPP as just a player or scheduler.   It is a complete controller as well. 

[JonB256]

What I am looking for here is the reason someone would even have an FPP out there if all it is going to do is act like a controller.

My initial thought was - In the past, they make very good controllers. Now, with DDP, they make GREAT controllers.

The FPPs I had running were "wearing" hats or capes.  Four were BBBs with Octoscrollers. Two were RasPi3 with PiCaps. Two were BBBs with F8B.

The Octoscrollers are a specific use item to drive P10 panels. I just chose to drive them in Bridge rather than as Wireless Remotes like I had in the past. These four ran as Remotes last year. There was a noticeable (to me) millisecond lag that went away in Bridge.

The RasPi3's with PiCaps I actually used because I had them lying around and it was easier and cheaper than buying a new standalone controller. I'm using both WS2811 pixel outputs to control window borders. The Pi/PiCap size fits nicely in a small CG box placed under the two windows they each control. I ran 12vdc to them from a nearby supply that provides power to an F8-B and its pixels.

The BBBs with F8B's were the same way, except I have used them for the same purpose for two years and they were already wired and ready. The only change this year was that they ran in Bridge mode. This eliminated their wireless dongle plus they ran completely from a uSD card. I find uSD cards to be more reliable than USB drives, especially since I started buying "Extreme Condition" rated uSD cards.

I also used to flash the FPP to eMMC on the BBBs because they do boot a little faster. Silly me. Once the show started, I don't reboot anyway. So they all just boot from the uSD card. Also, if you run in Bridge mode, a 4GB uSD card is all you need since you aren't storing ANYTHING extra on it except settings and some log files.

[algerdes]

Very interesting, Dan and Jon.  In the case of the FPP being the controller (hats/capes/etc.) I can definitely see their use in this manner. 


Note that our displays (x3) only use FPPs as feeds to full sized controllers (E682s, F16Vxs, F4Vxs, J1Sys and quite a few others) in either master or remote modes.  The only thing I'm using piCaps for is to provide power to FPP (12v PS) within a stand-a-lone prop and to get a DMX signal to theater style lighting. 

[pixelpuppy]

Note that our displays (x3) only use FPPs as feeds to full sized controllers (E682s, F16Vxs, F4Vxs, J1Sys and quite a few others) in either master or remote modes.

If you're running the show in Master/Remote mode, then DDP doesn't really apply because the channel data is stored on each remote and not sent across the network (except for the initial file copy).   Of course, in this case, you're using e1.31 to send data from FPP to Controller over a dedicated ethernet, but that is because Falcon/SanDevices/J1Sys don't (yet) support DDP.  If they did, you would benefit from using DDP over e1.31 on those connections too. 


Even in a Master/Remote show setup, DDP is still useful for pre-show setup and testing.    I run the show in Master/Remote but still use DDP for pre-show testing and setup.   I still define DDP in xLights (very easy) and when I want to test from xLights all I have to do is flip the FPP from Remote to Bridge (also very easy).

[JonB256]

Using FPP and hats/caps for controllers is now very usable, especially since they have added things like Virtual Strings and Brightness and Gamma controls to the pixel outputs. The Falcon boards have had that for awhile but some of the other boards you list lag behind in those features.

[dkulp]

Note that our displays (x3) only use FPPs as feeds to full sized controllers (E682s, F16Vxs, F4Vxs, J1Sys and quite a few others) in either master or remote modes.  The only thing I'm using piCaps for is to provide power to FPP (12v PS) within a stand-a-lone prop and to get a DMX signal to theater style lighting.

Note that it can also useful for that case.  If the full size controller is "hidden" behind the Pi, you COULD put the Pi in DDP bridge mode for testing, it would accept DDP incoming data, it would map the data onto the e1.31 outputs that are sent to the falcon/j1sys/etc...  No need to deal with complicated routing tables forwarding or any of that.

[algerdes]

Thanks for all that information folks.  I'll keep in mind.

[AAH]

  I came across http://www.3waylabs.com/ddp/ when looking for info on DDP. This topic was a few results below.  There is some great info in that post and most of the info won't matter to us punters. The ability to sync pixel outputs is a potentially good feature but potentially a bit redundant and the table at http://www.3waylabs.com/ddp/#Efficiency is good to see the number of pixels at 45fps with different protocols.  I say that the sync is possibly a bit redundant as assuming you are using WS2811 which are fairly slow then if you have long pixel strings (600-1000) then the delay between 1st and last pixel is probably/potentially worse than the DDP/E1.31 sending delay. If you ran zillions of short strings then you could get the beginning and ends of strings fairly much in sync.