Sean Meighan
Welcome => Do You Need Help? Post it here => Topic started by: nmiller0113 on September 06, 2018, 11:44:04 AM
-
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!
-
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.
-
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/
-
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.
-
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!
-
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
-
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)
-
Only the discovery packet is broadcast.
Sent from my iPhone using Tapatalk
-
Only the discovery packet is broadcast.
Not really:
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.
-
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
-
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.
-
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. :)
-
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.
-
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.
-
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 :)
-
I haven't used ZCPP yet but I am using DDP extensively this year. The efficiency improvements over E1.31 are allowing me to use a single RasPi3b+ to drive 154k channels over CAT5. (no wireless this year). It did require me to add a 16port Gigabit switch to the mix. I'm using 11 of 16 ports now.
That Pi is actually a Remote out in my garage, connected to the Master over a Powerline Ethernet connection. This is the one connection that could probably be Wireless since the only traffic it sees are Sync packets from the Master and updates to FSEQ files.
It may be bucking the trend of getting rid of wires in the yard but the majority of my v2.x FPP based controllers (currently they are the only devices accepting DDP) are either on the walls or roof of my house, keeping CAT5 in the yard at a minimum.
This being said, the timing differences and lags and pauses I've experienced over the years using Wireless Remotes are gone.
When ZCPP becomes available across everything, the switch should only take a few minutes. Or, when DDP becomes implemented on Falcon F16v3 boards, it will be even easier. (My F16v3 and v2 boards are still using E1.31)
-
Illuminationz Arizona is running over 1000 universes from a single PC using E1.31. I'm skeptical that any home user needs to worry about network efficiency. I don't.
-
Gil, I know that a PC and xLights can transmit more data than a Pi, but I've just been pleasantly surprised by how much data I can send with a Raspberry Pi, especially with the 3B+. Using eth0 to send all the data to E1.31 controllers and DDP to FPPs in Bridge Mode (instead of so many wireless remotes like in previous years) has made a visible difference in my display. Plus only having to keep a single Remote updated. (now that I think about it, I could move my Master and FM Transmitter/Antenna to the garage and even eliminate that one Remote).
That Arizona display is tremendous. I doubt I'll ever get there to see it, though. :(
Any idea how many people (paid and volunteer) it takes to manage that display? Looks like it could be a big money make if you had someone to front the $$$$$$ needed to get started.