E1.31 Questions [Beta Released 6/8/12]

[LightORamaJohn]

DonFL started a thread by this name which asked what & when LOR intended to release regarding E1.31 support in our S3 Software Suite. That thread went in fairly useless directions because we haven't released enough information about our support for E1.31. I have replaced that thread with this one hoping to cover what people want to know or at least provide a stable jump-off point for questions about our E1.31 support.

For those not familiar with E1.31 support, this allows your PC running our S3 software to go out over its LAN port to E1.31 gateway(s). A gateway translates the internet conversations back into RS485 conversations which are connected to your DMX lights and DMX devices. There are no hardware changes required on the PC. LOR S3 uses your existing LAN connection to reach the gateways.

We plan to release the LOR E1.31 4-port gateway this summer. The ports on our gateway will also support LOR protocol so you can individually configure the ports for DMX or LOR. There are jumpers in our gateway that permit the output RJ45 jacks to be configured for standard DMX or LOR wiring.

Since LOR controllers already support DMX, they can already be used on the DMX ports of an E1.31 gateway. If you are using a standard E1.31 gateway, you will have to adapt the wiring since the network jacks on LOR controllers are configured for LOR wiring.

Communications handling in S3 has been enhanced to support 999 DMX universes. These universes can be local via various USB adapters or can be over an internet protocol network terminating at E1.31 gateway(s). LOR's E1.31 implementation follows the E1.31 standard, so we expect the beta period to be quite short since nothing new is being designed here. We will not hold up support for E1.31 for the release of LOR's own E1.31 hardware. You can test using any hardware that supports the standard. Our implementation supports both unicast and multicast. We have moved the configuration of all networks (LOR & DMX) to a separate utility so that there is a uniform interface for all applications in the LOR S3 Suite that talk to your devices.

Check this thread at the end of next week for the announcement of the beta's start date.

I would also like to mention, as I have in another thread, that E1.31 is probably not the best solution for most of our customers. The primary reason for going to E1.31 is to support large numbers of RGB pixels. A 4-port (4 universe) E1.31 gateway will support 680 RGB pixels. We are working on a superspeed for the LOR network. This has the bandwidth to support 900 very active RGB pixels through a single, inexpensive USB dongle using LOR protocol. This simplifies configuration and cabling. Hopefully, testing will not show up anything untoward and we can release superspeed with E1.31 support. Currently, superspeed is implemented in the CCR, CCB/CCP and 16 channel G3 controllers.

(Changed max DMX networks to 999 from 1000 due to technical constraints - Mike)

[LOR Staff]

I stickied this since it's important.

[Guest wbottomley]

Gentlemen... Thank you.

[Guest guest]

John, thanks for the summary.

So I understand your offering of the gateway, but wanted to confirm one thing:

Will S3 software (once E131 capability is added) allow direct connect to an E131 controller? I'm interpreting your explanation as that being the case (for example, S3 with E131, connected direct to a sandevices E681 board, or one of the j1sys devices), and the gateway you describe is purely for interfacing to non-E131 devices, such as standard LOR controllers, or DMX devices. So the gateway is optional, not required.

Please let me know if I am thinking about this correctly.

[LightORamaJohn]

DonFL wrote:

Will S3 software (once E131 capability is added) allow direct connect to an E131 controller? I'm interpreting your explanation as that being the case (for example, S3 with E131, connected direct to a sandevices E681 board, or one of the j1sys devices), and the gateway you describe is purely for interfacing to non-E131 devices, such as standard LOR controllers, or DMX devices. So the gateway is optional, not required.

Please let me know if I am thinking about this correctly.

I think you have it exactly right if what I say in the next paragraph is correct.

My understanding of the E681 is that it looks to S3 exactly like an E1.31 gateway -- it doesn't matter to us that it decodes the DMX messages and drives the pixel strings itself. If it is E1.31 compliant, then no additional hardware is needed. PC -> LAN -> E681. Our gateway is like the J1Sys EthConGateways which we used for our initial testing.

If the E681 is as I explained above, then it is similar to our Matrix controller. It's just that we have a bigger window into the user community so we needed to add some additional hardware to meet their needs.

[Guest guest]

Your interpretation is correct, and answers my question.

[travis p]

john i would like to thank you for your post and information i understand keeping things close to the vest but i can t help saying this info has been kept to close for to longi glad its looking closer to being a reality those of us that have remained loyal to lor are hearing the coke a cloa song playing in our heads CHRISTMAS TIMES A COMING CHRISTMAS TIMES A COMING thanks again

[edvas69]

Guys thanks for the update as I always get questions asking which direction to take with E.31 and LOR, this now makes it clearer for those wanting to use LOR and E1.31 together.

[Beefer]

1000 DMX universes...... :]

[WilliamS]

neat, I have my 1.31 hardware already running with Elor, removing 1 piece of hardware would only make my life easier!

[Shubb]

I'm so excited I think I wet myself!

Thank you for the update for the software and hardware additions.

I will be looking forward to a release.

Scott

[LOR Staff]

FYI....

We ran into some internal constraints on DMX networks. We had to reduce the maximum DMX Universe number to 999 (from 1000).

[Shubb]

Ok, you can work on the missing universe after you release it. Maybe in E1.31.2 we can have 1000 universes?

Scott

[edvas69]

Jeff Millard wrote:

DevMike wrote:

FYI....

We ran into some internal constraints on DMX networks. We had to reduce the maximum DMX Universe number to 999 (from 1000).

While it's great that it can address 999, it would be nice to have an idea of how many of those a user could actually be controlling at the same time. 512 channels converts to 170 RGB channels. Common pixel strings in counts of 42, 50 or 60 add up quickly. In the current Software revision, I can control around 6 Universes before the Sequence Editor begins to get a little flakey and really choppy. I chatted with cenote about this a while back and he said he didn't have the same issues, then I got busy and lost track of the issue. I'm just wondering what others are finding. I will be running a minimum of 12 E1.31 Universes with the possibility of increasing to as many as 18. If the software won't do it for me, I have hardware that will. )BTW There were no issues when the Sequence played in the showplayer)

Also, what are the intended Baud rates of the new "Super-Speed" LOR network? Inquiring customers would like to know?!? ...and will there ever be a commercially available Chime-O-Matic? (or is that just a pipe dream?)<----- very sorry, I tried very hard not to type that but my fingers just wouldn't listen.

Jeff

I think what a lot of people need to realize is that when going from our traditional displays of under 500 channels to multi thousand channel displays that the software will not perform the same, as the amount of data needed to be processed explodes. So if you are planning on going to many thousands of channels then i would at minimum test to see if your computer is capable of handling these channels as you may also need to include a computer upgrade in your costings.

An example is this

256 channels with 25ms timing over 120 second period would equate to 1228800 data points

now

5000 channels with 25ms timing over 120 second period would equate to 24000000 data points.

Now thats a lot more data that needed to be processed, so it must be taken into consideration that anyone who is getting onto the pixel band wagon must also realize that their old computer hardware that worked fine for 256 channels may just not cut it when doing 5000 channels.

Unfortunatly that is the reality of progress

[LightORamaJohn]

edvas69 wrote:

I think what a lot of people need to realize is that when going from our traditional displays of under 500 channels to multi thousand channel displays that the software will not perform the same, as the amount of data needed to be processed explodes. So if you are planning on going to many thousands of channels then i would at minimum test to see if your computer is capable of handling these channels as you may also need to include a computer upgrade in your costings.

An example is this

256 channels with 25ms timing over 120 second period would equate to 1228800 data points

now

5000 channels with 25ms timing over 120 second period would equate to 24000000 data points.

Now thats a lot more data that needed to be processed, so it must be taken into consideration that anyone who is getting onto the pixel band wagon must also realize that their old computer hardware that worked fine for 256 channels may just not cut it when doing 5000 channels.

Unfortunatly that is the reality of progress

First, let's look at a 5000 channel setup. What edvas69 is doing is multiplying out the DMX data rates to produce very high data point numbers.

For example, a single DMX universe with 512 addresses(channels) would send 40 messages/second which would mean over 20,000 possible brightness changes/second. This is only 512 channels, for 5000 channels it's 10 times that.

In reality, if you actually had a sequence with 5000 events in each 0.025sec interval, you would be a cyborg building a show for other cyborgs and that's not S3's target customer group. On the other hand, you might have 5000 fades running. In this case, the lowest levels of S3 would have to compute 5000 intensities 40 times a second. If it took 100 instructions to compute one fade, then you would have 100 * 40 * 5000 instructions/sec needed or 20M. This is a tiny fraction of a modern PC processor.

On the front end (the Sequencer) you are most likely going to have large screen(s) and the gui and the backend processing associated with your sequencing is going to oink a lot of cpu. You should go to your cyborg neighbor for a PC recommendation.

There are real limits in the number of channels that S3 can manipulate reasonably but I have no intention of revealing those. A 5000 channel sequence is not near the current limit. We have already begun work on upping this limit because, as edvas69 wrote "that is the reality of progress."

[Shubb]

LightORamaJohn wrote:

"oink a lot of cpu"

Is that a techical term?

[LightORamaJohn]

Jeff Millard wrote:

Also, what are the intended Baud rates of the new "Super-Speed" LOR network? Inquiring customers would like to know?!? ...and will there ever be a commercially available Chime-O-Matic? (or is that just a pipe dream?)
Jeff

Superspeed is not set yet but is looking like around 3 times what is currently fastest. There are other new products in progress which constrain this and that will become clear when they arrive, but I won't offer any further explanation.

The Chime-o-Matic is my pet project. I finished the controller design in July of 2008 but it's been a continuous flow of other devices that keep pushing it down. I have had a set of for-show-only chimes hanging in my entry foyer for more than 4 year as a constant reminder of this.

I have 6 new devices in various states of completion that need to be done before I can go back to the CoM. Perhaps I should just build the controller and let someone in the user community debug it and write the firmware. Anyway. sorry...

[Guest guest]

Okay, now I HAVE to ask this {since I'm not all that familiar with all this and just trying to understand it}:

Since I, and some others do use Showtime Director units to run our shows WITHOUT the use of a computer.

How would this interface and work with the LOR Director Units? {just like the LOR and use a standard Cat5 cable or ?}

I use an DC-MP3 Showtime Director to run and operate my shows from an SD Card.

So will the firmware need to be updated in the Director units to allow for the E1.31?

Or will these need to be replaced with a different type Director unit that could control both types LOR and DMX via their Cat5 input/output jacks?

And what about older controllers, V1/V2 versions, will they require a firmware upgrade to make them more compatible with the E1.31 protocol?

Or did I just miss the boat and nothing would need to change? So we could still use everything as it is?{older controllers/firmware and same with Director units?}

Like said, I'm asking so if I ever happen to get into this aspect, I know what my current hardware can or can not do, and what I'd have to do to make it work with what I currently own, or would have to replace.

[LightORamaJohn]

Jeff Millard wrote:

LightORamaJohn wrote:

I have had a set of for-show-only chimes hanging in my entry foyer for more than 4 year as a constant reminder of this.

Are these the ones in the photograph that look like a doorbell on steroids?

The device pictured in the stand is far more sophisticated current product. The COM255 controller plugs directly into this device. The device on the wall is mine -- It is very primitive and I need some special interfacing for it. I bought mine on the net from a guy who got stiffed by a church. Very good deal.

The Chime-o-Matic is my pet project. I finished the controller design in July of 2008 but it's been a continuous flow of other devices that keep pushing it down...

...that need to be done before I can go back to the CoM. Perhaps I should just build the controller and let someone in the user community debug it and write the firmware...

So it's still your intent to eventually release a retail product?

Yes, we want to sell this.

Anyway. sorry...

The Chim-O-Matic part of my post was just a way for me to get the "pipe-dream" joke in it. It wasn't meant to berate the fact, just poke fun.

Jeff

[edvas69]

LightORamaJohn wrote:

edvas69 wrote:

I think what a lot of people need to realize is that when going from our traditional displays of under 500 channels to multi thousand channel displays that the software will not perform the same, as the amount of data needed to be processed explodes. So if you are planning on going to many thousands of channels then i would at minimum test to see if your computer is capable of handling these channels as you may also need to include a computer upgrade in your costings.

An example is this

256 channels with 25ms timing over 120 second period would equate to 1228800 data points

now

5000 channels with 25ms timing over 120 second period would equate to 24000000 data points.

Now thats a lot more data that needed to be processed, so it must be taken into consideration that anyone who is getting onto the pixel band wagon must also realize that their old computer hardware that worked fine for 256 channels may just not cut it when doing 5000 channels.

Unfortunatly that is the reality of progress

First, let's look at a 5000 channel setup. What edvas69 is doing is multiplying out the DMX data rates to produce very high data point numbers.

For example, a single DMX universe with 512 addresses(channels) would send 40 messages/second which would mean over 20,000 possible brightness changes/second. This is only 512 channels, for 5000 channels it's 10 times that.

In reality, if you actually had a sequence with 5000 events in each 0.025sec interval, you would be a cyborg building a show for other cyborgs and that's not S3's target customer group. On the other hand, you might have 5000 fades running. In this case, the lowest levels of S3 would have to compute 5000 intensities 40 times a second. If it took 100 instructions to compute one fade, then you would have 100 * 40 * 5000 instructions/sec needed or 20M. This is a tiny fraction of a modern PC processor.

On the front end (the Sequencer) you are most likely going to have large screen(s) and the gui and the backend processing associated with your sequencing is going to oink a lot of cpu. You should go to your cyborg neighbor for a PC recommendation.

There are real limits in the number of channels that S3 can manipulate reasonably but I have no intention of revealing those. A 5000 channel sequence is not near the current limit. We have already begun work on upping this limit because, as edvas69 wrote "that is the reality of progress."

Yes John is correct here, its not actually the data dmx/e1.31 data stream or processing that is the actual limitation, its the actual sequence creation that will see any perforamnce issues due to the added load of the GUI and front end which is what i was actually talking about (i should have been clearer). The reason i used 25ms was because i know many poeple sequence with that timing. This is where your computer may not cut it anymore as both the memory footprint and CPU demands dramatically increase. The performance of this is heavily based on the CPU specs that are being used.

This has been the experience of other grid based software packages and I would expect to be similar for LOR S3. But then their maybe some programmining magic done by the LOR team to reduce the demands and footprint when sequencing.