Author Topic: DDP info  (Read 463 times)

Online dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,235
  • Kudos: 68
Re: DDP info
« Reply #15 on: November 09, 2018, 05:35:38 AM »



If you change those "Null" outputs to DDP outputs, it would pretty much look the same.  However, you can "Activate" or "Deactivate"  (right click popup) the various outputs to test them directly from xLights.   That's how all my outputs are now defined.   If I'm trying to test one P5 or something, I can just activate it, turn on the output to lights, and see what it does.     By default I keep all the outputs deactivated and just activate the one I'm testing.



Dan Kulp

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,885
  • Kudos: 109
    • Granbury Christmas Lights
Re: DDP info
« Reply #16 on: November 09, 2018, 06:20:30 AM »
If you change those "Null" outputs to DDP outputs, it would pretty much look the same.  outputs deactivated and just activate the one I'm testing.

Dan, what made me hesitate a bit about doing that is that the "parameters" that xLights asks for are not the same as FPP. The ones in FPP are very simple. The ones in xLights, not quite so much. I will look at it later (out of town for two days)

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,160
  • Kudos: 34
Re: DDP info
« Reply #17 on: November 09, 2018, 07:07:51 AM »
If you change those "Null" outputs to DDP outputs, it would pretty much look the same.  However, you can "Activate" or "Deactivate"  (right click popup) the various outputs to test them directly from xLights.   That's how all my outputs are now defined.   If I'm trying to test one P5 or something, I can just activate it, turn on the output to lights, and see what it does.     By default I keep all the outputs deactivated and just activate the one I'm testing.


That's how I do it too. Works great!  The only question I had about setup is why or when would we want to change the "channels per packet" option?  Isn't Ethernet the only transport available for DDP from xLights?  And if so, wouldn't we always want it to be the maximum Ethernet DDP payload size (1440 according to the spec)?  And in that case, its appears the default value in xLights to 1410.  Is that a typo or is there a reason for it to be 1410 instead of 1440?
xLights and Vixen3 for sequencing / FPP for scheduling and playing / Falcon controllers for pixels / homemade controllers for everything else

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,885
  • Kudos: 109
    • Granbury Christmas Lights
Re: DDP info
« Reply #18 on: November 09, 2018, 08:04:08 AM »
While we "flesh out" some of these DDP questions and setup, I'm curious -

Other than watching for lagging and glitching in the display on Pixels and Panels during a show, how can I tell if I'm over saturating or overloading the bandwidth of the Output device (in my case, a RasPi3b+) or the network in general?

If I watch the Bridge Mode screen of the Beaglebone or Pi receiving DDP data, there is an "Error" column. That number is low and not changing right now except it may increment by 1 when I start and stop things. Will it be my best indicator that I've got a problem?

Haven't looked with Wireshark or similar. Suggestions?

Online dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,235
  • Kudos: 68
Re: DDP info
« Reply #19 on: November 09, 2018, 11:56:15 AM »
Other than watching for lagging and glitching in the display on Pixels and Panels during a show, how can I tell if I'm over saturating or overloading the bandwidth of the Output device (in my case, a RasPi3b+) or the network in general?

If I watch the Bridge Mode screen of the Beaglebone or Pi receiving DDP data, there is an "Error" column. That number is low and not changing right now except it may increment by 1 when I start and stop things. Will it be my best indicator that I've got a problem?


The Error column is the best indicator.   If the DDP listener gets a packet out of order or missing packets, it increments that. For the most part, it's ignorable as next frame we'll just overwrite anyway.   If you are getting a very low number of errors, then you are definitely OK.


Note:  I'm changing the default in xLights to 1440 to match what FPP is using.  The only time its useful to lower the number is if you are trying to send data over some sort of IP tunnel like a PPP/VPN or similar that requires some room in the IP packet.   I'm willing to bet that that doesn't apply to 99.9% or higher of us, for now.  :)     




Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,885
  • Kudos: 109
    • Granbury Christmas Lights
Re: DDP info
« Reply #20 on: November 10, 2018, 03:37:17 PM »
The Error column is the best indicator.   If the DDP listener gets a packet out of order or missing packets, it increments that. For the most part, it's ignorable as next frame we'll just overwrite anyway.   If you are getting a very low number of errors, then you are definitely OK.


Note:  I'm changing the default in xLights to 1440 to match what FPP is using.  The only time its useful to lower the number is if you are trying to send data over some sort of IP tunnel like a PPP/VPN or similar that requires some room in the IP packet.   I'm willing to bet that that doesn't apply to 99.9% or higher of us, for now.  :)   

I just looked at "Troubleshooting Commands" on the RasPi sending my DDP output.
The ifconfig -a command at the top does show how many packets and bytes have been transmitted, plus that TX errors are all Zero. I'll take that as a good sign.

I'll be adding two more P10 panels tomorrow, the two more on Monday, weather permitting. Results to follow.

Update - moving ahead slowly due to weather (rain) for my setup changes involving DDP and P10 Matrices.
But - I did try sending DDP over Wireless instead of CAT5. This was to a pair of 5x4 panels (so 120 universes of DDP data).

It did work and actually looked normal on the panels. Not jerky or flashy. But - using the ifconfig -a command listed above, there were a LOT of Rx errors (dropped bytes)
RX packets 2010185  bytes 409799629 (390.8 MiB)
RX errors 0  dropped 138964  overruns 0  frame 0

I don't see any errors like that on the panels already connected with CAT5/Ethernet
RX packets 4294026  bytes 3584562686 (3.3 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
« Last Edit: November 12, 2018, 04:46:47 AM by JonB256 »

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,885
  • Kudos: 109
    • Granbury Christmas Lights
Re: DDP info
« Reply #21 on: November 13, 2018, 01:12:31 PM »
Setup and testing of DDP continues

I got two more panels (18 P10 panels each) connected via CAT5 instead of being Wireless Remotes.
Now all 5 panels are connected.
Two are BBB/Octo with 20 panels each
Two are BBB/Octo with 18 panels each
One is RasPi3B with 9 panels (wlan0 disabled by not providing an SSID)
All are CAT5 connections to a Gigabit switch in the garage.
They are driven by a RasPi3b+ connected to that same garage switch.
Also sending 9 universes of E1.31 to an F16v3 driving a normal pixel matrix (40x30)

The RasPi3b+ is running as a Remote and the Sync data is coming from a Master next to my xLights computer via a pair of Zyxel PowerLine adapters

So, the total output from that RasPi3b+ is 130,560 channels via DDP and 3600 channels via E1.31 (262 Universes)

No panels show any dropped packets or overruns or errors on their Bridge status page or ifconfig -a

This has eliminated 5 wifi connected Remotes, meaning 5 fewer Remotes to keep updated with FSEQ changes.
Of course, it does mean I'm back to having more wires running, though not across the yard.

So far, it appears to be better synchronized across all items.
« Last Edit: November 13, 2018, 02:20:09 PM by JonB256 »

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,885
  • Kudos: 109
    • Granbury Christmas Lights
Re: DDP info
« Reply #22 on: November 14, 2018, 06:00:13 PM »
Dan, I keep loading more channels onto the RasPi3B+ driving all my DDP outputs.
So now I have the 5 P10 panels  (255 Universes)
and also outputting to an F16v3 and F16v2 (about 22 Universes of E1.31)

There are Zero errors on the Bridge Mode status screen and playback of video and patterns on the P10 panels is as smooth as I've ever seen it.

So, I'm at approximately 277 universes of data with no glitches. How high do you think I can go?  That RasPi3B+ is connected to a 16port switch and I've got 8 ports still free!

Online dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,235
  • Kudos: 68
Re: DDP info
« Reply #23 on: November 14, 2018, 07:20:21 PM »



That's awesome..... Just need Dave to get DDP added to the Falcon controllers.....


Gut feeling is around 500 universes or so.  I've pushed 200 out from a Beaglebone, but that's only 100M.   The Gigabit should help a lot.


Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,885
  • Kudos: 109
    • Granbury Christmas Lights
Re: DDP info
« Reply #24 on: November 24, 2018, 06:55:50 PM »
Interesting problem cropped up today.

I am adding several new "mid sized" trees. There was a fairly large gap in my Channels so I started putting the Tree and Star (240 and 40 pixels) in the gap. But there was not quite enough room. So I put the remaining Tree and two Stars in the next open spot, 13 Universes down the list.

On the RasPi3b+ workhorse I'm using to send out my DDP, I made two DPP Raw line entries for their specific Start Channel and channel count.
As soon as I started play a sequence, the Error Count was HUGE. For whatever reason, having a dead gap between the two DDP entries is not good.

Instead, I just made a single DDP entry covering the whole range. That worked (error count back down to zero) but it means I'm sending extra data (about 6000 channels) to a BBB that it will not use.

There is a question in there: Is that normal and expected? (two DDP entries to the same IP address causing errors)
If not normal, what could I do differently?

Online dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,235
  • Kudos: 68
Re: DDP info
« Reply #25 on: November 24, 2018, 07:05:09 PM »



Kind of normal I guess.   There is a byte in the packet that is incremented each packet.  If it gets a packet that isn't the next increment, then it registers an error. 


On the sending side, we have to keep a separate byte counter for each DDP output line.  I probably could try and merge together lines that target the same IP address, but that's not there now.

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,885
  • Kudos: 109
    • Granbury Christmas Lights
Re: DDP info
« Reply #26 on: November 24, 2018, 09:19:11 PM »
Kind of normal I guess.   There is a byte in the packet that is incremented each packet.  If it gets a packet that isn't the next increment, then it registers an error. 

On the sending side, we have to keep a separate byte counter for each DDP output line.  I probably could try and merge together lines that target the same IP address, but that's not there now.

It didn't just generate errors on the DDP target IP, but the other targets (P10 panels in Bridge) were seeing errors, too.

For now, I'll either live with that "inefficiency" or I'll move some models to make a bigger contiguous blank spot.
Worry about other things, Dan. Thanks.

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,885
  • Kudos: 109
    • Granbury Christmas Lights
Re: DDP info
« Reply #27 on: December 04, 2018, 08:45:30 AM »
Three full nights of uninterrupted transmission of DDP and E1.31 data from that single RasPi3B+

Nine DDP receiving units (mix of BBB, BBG and Pi3-PiCaps)
Three F16s (two V2R and one V3) getting E1.31 Unicast

Cables must be good. :)

RX packets 32535434  bytes 3035998923 (2.8 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 154261994  bytes 1492098272 (1.3 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

Back to top