Will conductor output E1.31 via the Ethernet port?

[akonkman]

I guess this is both a question and a feature request.  I know it's still early, so RJ, if you don't want to discuss at this time, no problem.

I think it would be an outstanding feature if the conductor, coupled with the etherdongle, would be able to output E1.31 via the now-unused Ethernet port. 

I will have another E1.31 device in 2012 (the E681 controller) for controlling some GE Color Effects lights.  I also love the idea of the conductor.  But without E1.31 output from the conductor, I'll need to run both the Etherdongle and the E681 from a PC.  This is certainly possible, but man, did I mention I love the idea of the conductor?   <;d

[rrowan]

Jeff,

Yeah I don't think that is what he was asking.

I am speaking out of turn here since I don't know what is RJ's plan. I would guess out of the gate the Conductor add-on board to the etherdongle won't output e1.31 If its possible at all without a redesign of the pcb. Which does not seem like a good use of his time.

Of course I could be TOTALLY wrong and RJ has already plan for this

just my 2 cents

Rick R.

[tbone321]

I would say that is not in the plan but I could be wrong.  How would you tell it what channels to broadcast on the network connection and what ones to send out as pixelnet on the controller output.  He also intends to send out a sync signal on the network connection for the slave units.  How would these mesh together? 

[akonkman]

Rick,

Yeah, I was more or less inquiring about the possibility of magically making this work with a new firmware or something, using the existing PCB design.  I have no idea what the possibilities are.  More wishful thinking than anything 

As to the question about how you would tell it what channels to broadcast on the network connection versus the pixelnet connection... I guess  you'd have to have some sort of utility to configure that by connecting the etherdongle to your PC first, sort of like how the Smart String utility works.  You'd say something like "Channels 1 through 5999 are output via Pixelnet, and channels 6000 through 6680 are output via E1.31".  I'm sure it's a bit more complicated than that, but the general idea is there.

And yeah, this wouldn't play well (or at all) with the slave units.  But since the conductor/etherdongle combo can spit out bits on that network port, it seems like it might be possible for it to spit out even more bits on that port in the form of formatted E1.31 packets.

Again, this is more just wishful thinking.  I'm fully expecting to go the route that caretaker described, and I'm sure it will work great.  I used LSP last year, and had a few issues until I used xLights to run the show.  It ran flawlessly after that.

I'd like to thank RJ for all the hard work that has gone into the Etherdongle.   <res. I just got mine in the mail today, and I'm very excited to get started on it and see what it can do!

[Voltorb]

I would be VERY interrested in a version of the conductor (or slave) that would output E1.31.  Perhaps after the planned capabilities are rolled out, this can be considered a future add-on.

[tbone321]

While I'm not RJ and just about nothing is impossible, I would really doubt that this is going to happen.  From talking to him here and attending his classes at the Academy, having the Conductor putting out E1.31 would be completely out of line with his design concept and implementation.  The idea is to allow the units to control an almost countless number of channels with no real load on peoples networks and allow for a huge amount of fault tolerance.  Tis is done by the Conductor and slave units containing the data that they will b outputting and the Conductor sending out signals telling the slaves what to play and where in the show they should be.  This is done with small data packets sent out once a second which puts virtually no load on the network regardless of how many slaves are in the system.  The slave units can even miss up to 6 of these timing packets and still function without issue. 

Since the Conductor always puts out 4 full PixelNet universes and does it at a 50ms refresh rate, having it outputting E1.31 on the Ethernet port would do just the opposit.  It would be jamming the Ethernet network making your network pretty much useless for anything else and any delays or glitches such as added traffic from someone dowloading a file or streaming video would be seen in your show and this is with just one Conductor outputting E1.31.  What if you had two or even three of them doing this?  I could just imagine the mess that would make. 

[Steve Gase]

RJ has talked about the EtD (and Conductor?) being a platform for others to do development and offer solutions.
Maybe the conductor framework will be documented enough to allow you (or others) to create the solution you describe.

[akonkman]

Just want to update everyone with my current thoughts about this.  The option I'm currently leaning towards for 2012 will be to use a Slave unit to run all the PixelNet stuff (and thus add just a small sync signal to the network), and then run the E1.31 stuff directly from the scheduler running on the PC (either LSP, if that one works better this year, or xLights).  Assuming LSP and/or xLights supports sending out the Slave sync signal in conjunction with E1.31, I think this provides a nice trade-off... yes, it still requires a PC, but hopefully that PC won't need to be as powerful, since it really is only directly controlling the E1.31 devices/channels, and not the PixelNet stuff.

Perhaps this is more in line with what RJ was thinking when creating the Slave unit, anyway.

Another option that I've come up with, although I don't have the technical skills to pull this off myself, would be the creation of some sort of "PixelNet to E1.31" converter.  One issue with this might be the cost of such a converter, and I'm not sure it would have wide applicability.

[tbone321]

RJ has talked about the EtD (and Conductor?) being a platform for others to do development and offer solutions.
Maybe the conductor framework will be documented enough to allow you (or others) to create the solution you describe.

I do not believe that the Conductor was included in that.  He has setup the Etherdonge with that in mind and IIRC, he will be releasing a daughter card for it that allows people to connect to it for development of their own daughter cards.  The Conductor is a completed device and RJ has made the point many times that he wants people to develope new items, not remake or modify existing ones.  One of the primary reasons that this site and the Lynks equipment works as well as it does is because there are not 50 different versions of it or of the firmware.  Opening the Conductor for open development would cause that exact problem. 

[tbone321]

Just want to update everyone with my current thoughts about this.  The option I'm currently leaning towards for 2012 will be to use a Slave unit to run all the PixelNet stuff (and thus add just a small sync signal to the network), and then run the E1.31 stuff directly from the scheduler running on the PC (either LSP, if that one works better this year, or xLights).  Assuming LSP and/or xLights supports sending out the Slave sync signal in conjunction with E1.31, I think this provides a nice trade-off... yes, it still requires a PC, but hopefully that PC won't need to be as powerful, since it really is only directly controlling the E1.31 devices/channels, and not the PixelNet stuff.

Perhaps this is more in line with what RJ was thinking when creating the Slave unit, anyway.

Another option that I've come up with, although I don't have the technical skills to pull this off myself, would be the creation of some sort of "PixelNet to E1.31" converter.  One issue with this might be the cost of such a converter, and I'm not sure it would have wide applicability.

One thing to remember is that the EhterDongle IS an E1.31 device so if you are going to have the PC sending out E1.31 data, then you migh as well just use the EhterDongle as is to pick up that signal and senf out PixelNet to the devices requiring it and letting the other E1.31 devices work on their own.

[Steve Gase]

I am a software developer, and not a hardware developer.

I look at the ability to develop software applications for the PC, or android, and firmware that would run on any of the Lynx devices with MUCH more enthusiasm than trying to go back to school to understand resistor, IC, capacitor, design and placement.

In other words I'd like to contribute to new features and kits by making software contributions -- and if I need to design a daughterboard for the EtD I will likely sit on the sidelines and watch.

[tbone321]

That would probably be a discussion that you would have to have with RJ but the last time I spoke with him, he made it clear that he fully intends to keep the firmware for his devices to himself but was more than willing to help others with the firmware for their own designs.  What I hope he does do is publish some of the specs on communicating with some of his devices such as the Conductor so that I and others can design applications that work with them.

[akonkman]

One thing to remember is that the EhterDongle IS an E1.31 device so if you are going to have the PC sending out E1.31 data, then you migh as well just use the EhterDongle as is to pick up that signal and senf out PixelNet to the devices requiring it and letting the other E1.31 devices work on their own.

Yep, I understand that the EtherDongle is E1.31 also.  I'm just trying to cut down on the amount of work that the PC has to do (and the related "stutter" that the pixels might have because of it).  I experienced some minor stutter in 2011 using the PixelNet firmware on the USB/Lynx dongle, and I am thinking with additional pixels this year, it might get worse.  Although I've also heard that the EtherDongle is quite improved in that respect versus the USB dongle... although that might very well be a function of the PC interface (USB versus ethernet).  Regardless, I think I'll try running the EtherDongle as-is from the PC, along with my other E1.31 devices, and see how that goes, with the thought that the Slave unit may be a way to improve things if needed (basically, by offloading some of the work from the PC). 

[tbone321]

I don't think that you will have much of an issue with the EtherDongle.  Ethernet is so much faster than USB that unless you have some real network issues or running a piecs of crap like Vista, you shoupd be good to go.  I like your idea about using a slave unit and having the show software issue the timing packets along with the the E1.31 packets but there may be some issues in doing that and I really don't think that you would need it.