Just watched the ZCPP video from Keith

[nmiller0113]

I was curious regarding any similarities it may have to DDP in terms of streaming data.  Does it keep sync like DDP does?  Anything else similar in terms of matching efficiencies?

Also, I know it can't handle things like Null Pixel, Reverse Data, Virtual Strings...etc.  But what if you have a Matrix that exceeds the maximum port pixel count for the controller you're putting it on?  Does it automatically distribute that to multiple ports?  If so then I'd imagine it has the awareness of the limits of the controller you're communicating with?  As an example the F16v3 can handle 1024 pixels per port if operating at 20fps and 680 at 40fps.  Since fps is defined in the sequence, will there be a way to define that when building a model so it doesn't automatically split the port distribution?

I hope my questions made sense.  I'm really interested in learning more here.  Thanks!

[Gilrock]

I don't even know what DDP is and Keith is about to leave for a 2 week vacation so unless he answers today you may not get one soon.

[nmiller0113]

I don't even know what DDP is and Keith is about to leave for a 2 week vacation so unless he answers today you may not get one soon.

Thanks for the quick response Gil.  In short DDP is a much more efficient and simple than E1.31.  You can read more about it here http://www.3waylabs.com/ddp/

[keithsw1111]

I believe the same questions were posted on the falcon forum.

It is 2 bytes less efficient than DDP. It does have the same sync facilities at a per controller but also a per show sync as well which DDP doesnt have.

It assumes each string on a prop is on a new port and that port is sequential to the prior string ... much like the existing controller upload functionality.

The protocol doesnt enforce the controller rules ... the controller does ... but it can perform some of the checks by running check sequence.

[nmiller0113]

I believe the same questions were posted on the falcon forum.

It is 2 bytes less efficient than DDP. It does have the same sync facilities at a per controller but also a per show sync as well which DDP doesnt have.

It assumes each string on a prop is on a new port and that port is sequential to the prior string ... much like the existing controller upload functionality.

The protocol doesnt enforce the controller rules ... the controller does ... but it can perform some of the checks by running check sequence.

Thanks Keith, yes I asked some similar questions in the falcon forum but figured I'd also post at least that question again here since this is where it would be most relevant at the moment.

I had never used the existing controller upload functionality, only started to read up on it, so that's good to know and makes sense.  I also understand the controller enforces the rules of going between 40fps and 20fps based on per port pixel counts...that makes sense.

When you mention checks it would do in running check sequence, what would some of those checks you're referring to be?  Are you saying it would mention something about exceeding a port pixel count?  If that's what you're saying, how would it know if you were exceeding that number as it would vary depending on the situation.  Thanks!

[keithsw1111]

Xlights check sequence does some checks and these will likely be enhanced over time. Right now they are not quite as comprehensive as the upload checks.


Sent from my iPhone using Tapatalk

[dkulp]

It is 2 bytes less efficient than DDP. It does have the same sync facilities at a per controller but also a per show sync as well which DDP doesnt have.

Currently, the zcpp (at least according to the preliminary xLights code) uses broadcast, not multicast.  That basically means that  its not usable on WIFI (would only be sent to the destinations every 100ms, and at 6Mb/s speed on 802.11n) and would likely bring the entire wifi networks to something of a stand still.   Obviously the protocol and code still needs a little tweaking.   

As I alluded to on facebook, the config requirement also pretty much precludes the use of the advanced features of the Falcon.  In general, I consider the Falcons to be the Mercedes/BMW's of the controllers, full of all kinds of features that the user may not need, but are sure nice to have if you do.   This protocol pretty much turns them into souped up Honda Civic rice rockets.   A nice "single button push makes it go real fast", but that's about all you get.      (no offense intended to owners of Civics, BMW's, or Mercedes)

[keithsw1111]

Only the discovery packet is broadcast.


Sent from my iPhone using Tapatalk

[dkulp]

Only the discovery packet is broadcast.

Not really:

Code: [Select]

        wxString ipaddrWithUniv = "255.255.255.255";
        syncremoteAddr.Hostname(ipaddrWithUniv);
        syncremoteAddr.Service(ZCPP_PORT);

That's sending to the broadcast address.   It's not a valid multicast address.  Thus, clients cannot set a valid IGMP subscription for it to have the wifi access points do the right thing and not have it buffered into the access point memory and send out on the beacon intervals.

[keithsw1111]

Ok the sync packet is currently implemented as broadcast as well. With artnet or sacn does it that way and I think I copied it. Not a big thing to change at this point.


Sent from my iPhone using Tapatalk

[nmiller0113]

It is 2 bytes less efficient than DDP. It does have the same sync facilities at a per controller but also a per show sync as well which DDP doesnt have.

Currently, the zcpp (at least according to the preliminary xLights code) uses broadcast, not multicast.  That basically means that  its not usable on WIFI (would only be sent to the destinations every 100ms, and at 6Mb/s speed on 802.11n) and would likely bring the entire wifi networks to something of a stand still.   Obviously the protocol and code still needs a little tweaking.   

As I alluded to on facebook, the config requirement also pretty much precludes the use of the advanced features of the Falcon.  In general, I consider the Falcons to be the Mercedes/BMW's of the controllers, full of all kinds of features that the user may not need, but are sure nice to have if you do.   This protocol pretty much turns them into souped up Honda Civic rice rockets.   A nice "single button push makes it go real fast", but that's about all you get.      (no offense intended to owners of Civics, BMW's, or Mercedes)

Love the analogies Dan!  Honestly, I wish that the Falcon Controllers supported DDP too.  I'm more looking for the protocol efficiency value over E1.31.  I'd like to run DDP from the FPP to the Falcon Controllers.  Though, overall, since I haven't had an opportunity to test it, I'm not entirely sure how all the configurations work.  If I'm running DDP, as an example, I know I'd need to run that on the FPP to the Falcon Controller, but I'm assuming that since the channel setup is different I'd need to also configure DDP in xLights so that the binary files (fseq) are built with the right channel mappings...or does it not matter due to absolute channels being protocol agnostic?  All of this is obviously assumptions as I just haven't done it yet.

[dkulp]

Love the analogies Dan!  Honestly, I wish that the Falcon Controllers supported DDP too.  I'm more looking for the protocol efficiency value over E1.31.  I'd like to run DDP from the FPP to the Falcon Controllers.  Though, overall, since I haven't had an opportunity to test it, I'm not entirely sure how all the configurations work.  If I'm running DDP, as an example, I know I'd need to run that on the FPP to the Falcon Controller, but I'm assuming that since the channel setup is different I'd need to also configure DDP in xLights so that the binary files (fseq) are built with the right channel mappings...or does it not matter due to absolute channels being protocol agnostic?  All of this is obviously assumptions as I just haven't done it yet.

From what I can tell looking at the code and preliminary spec and such, there are three parts to the zcpp protocol:

1) Discovery - the return from the discovery contains a bunch of information about the controller.   Number of ports, protocols supported, etc....

2) Software can use the stuff in 1 to create config packets to send to the device so the device can configure itself to match.

3) Channel data/sync - this is VERY similar to DDP.   

What I want is the ability to use parts 1 and 3, but skip part 2.   If the discovery result contained the start/end channel that it is configured to need, it becomes very useful for things other than pixel strings.   Think P10 panels.   I'd love for FPP and xLights to be able to send out a discovery and get back all the information about the various FPP instances along with the Falcon things.  With the work I did last week in FPP, having it report the channel range it uses/needs is easy.  Anyway, it would give us the benefits of DDP, but easier to use.  Anyway, I'll be following up with Dave about some of this to make sure it can work that way.   May need to adjust the protocol a bit, but that's why we're looking at it and it's not released yet. 

[nmiller0113]

Sounds great Dan!  Did you happen to see my configurations question?  I'll repeat, hopefully more clearly, here....

I'm not entirely sure how all the configurations work.  If I'm running ZCPP, as an example, I know I'd need to run that on the FPP to the Falcon Controller for it to stream the sequence to the controller.  The part I'm not sure about is I'm assuming that since the channel setup is different I'd need to also configure ZCPP in xLights even though it won't be the player?  So that the binary files (fseq's) are built with the right channel mappings?  Or does it not matter due to absolute channels being protocol agnostic?  Sorry for all of the questions, trying to better understand how I'll need to set this up in xLights as I would be running FPP as my player.

[jnealand]

I suspect you will not need to worry about this until next year.  Lots of time to let the developers work out the kinks before we inundate them with questions.

[nmiller0113]

Possibly, but it sure sounds like ZCPP is going to be live in the next month or so in xLights within the next two point versions according to Keith on the video he made on it....so I'd assume that the Falcon Controller isn't far behind.

Though my questions for Dan, in my previous message, regarding whether there will be a need to run this on xLights to change the way the FSEQ is built, even when running the player on FPP speaking ZCPP to the Falcon Controller may not hit this year as that isn't currently a protocol option...yet