E1.31

[GaryMartin]

Naturally we are assuming one LOR network per ELOR device here. That scenario has already been initially tested with good results, pushing 2k pixels with a LOR S3 -> ELOR -> E681 pixel controller setup.

There will be some more intensive testing, trying to push the limits but it seems to work fine so far.

You have to remember, when using CCRs, you're dependant on the speed of the CCR controller itself in listening and accepting commands. The ELOR uses a much faster processor and is able to poll it's incoming LOR network much more efficiently.


srwmemphis wrote:

The only thing that worries me about the ELOR is the amount of data that a user is going to be trying to push through it (4 DMX Universes) over one LOR network! Last year I ran 10 CCR's and had to split them up across three separate LOR networks to keep them from lagging behind. Pixels take a lot of data. Maybe I am speaking out of turn, but from my experience last year, I would be afraid of planning on running tons of pixels over a LOR network. that's why I personally am so insistent on e1.31. The speed of an Ethernet network is far superior.

Just a thought.

SteveMaris wrote:

GoofyGuy wrote:

Smart money is get the ELOR, its as cheap as some of the bad ideas we had the previous years.  If Dan doesnt get it running then so be it.   Im running LOR regardless, the customer support is too good to pass up.  As for my ideas on how to decorate will not be altered becuase of timing on thier part.  As soon as Sean at SandDevices will let me I will have it on the way.  I will be harassing Jeff from there to get the ins and outs if hes willing to share.

I'm with you. I just don't understand how someone says they will wait, unless they don't have a plan for pixels.

[ben]

well gary i do have a plan for pixels i am building a 60 pixel matrix. 8 x 8 pixel candy canes and 2 x 8 channel polls. i am just not going over 1 universe this year but will be next year. so i can wait and see what happens but i like to work a year ahead.

[tpctech]

A vendor for my day job ETC (Electronic Theatre Controls) has created a new Pixel mapping software and it is free. It will drive sACN and or a video projector. Multi-universe and it's effects can be triggered from a sACN input. So it can do cool Pixel based effects and trigged via LOR with sACN when it comes out of with the Sandevice LOR to sACN interface.

http://www.etcconnect.com/community/wikis/products/pixeltoy.aspx

KEN




FEATURES

Streaming ACN output
Video output
Put pixelToy in media server mode and control up to 4 layers from your lighting console
Simple, intuitive interface
Touch screen friendly
Anyone can write plugins
Low lighting budget? All you need is a PC and a projector.
It's FREE!

[SteveMaris]

Dumb question of the day:
What is streaming ACN?
Is that E1.31?

[geronc]

Program looks pretty cool.

Yes, Streaming ACN is E1.31.

[GaryMartin]

Actually Jeff I've been hanging out in the back there for weeks, you just haven't noticed!

Jeff Millard wrote:

GaryMartin wrote:

Naturally we are assuming one LOR network per ELOR device here. That scenario has already been initially tested with good results, pushing 2k pixels with a LOR S3 -> ELOR -> E681 pixel controller setup.

There will be some more intensive testing, trying to push the limits but it seems to work fine so far.

You have to remember, when using CCRs, you're dependant on the speed of the CCR controller itself in listening and accepting commands. The ELOR uses a much faster processor and is able to poll it's incoming LOR network much more efficiently.

Have you been peeking through the window to my workshop Gary???  :cool:

Jeff

[LightORamaJohn]

GaryMartin wrote:

Naturally we are assuming one LOR network per ELOR device here. That scenario has already been initially tested with good results, pushing 2k pixels with a LOR S3 -> ELOR -> E681 pixel controller setup.

There will be some more intensive testing, trying to push the limits but it seems to work fine so far.

You have to remember, when using CCRs, you're dependant on the speed of the CCR controller itself in listening and accepting commands. The ELOR uses a much faster processor and is able to poll it's incoming LOR network much more efficiently.

The last paragraph does not make sense to me. No LOR controller polls the network. Controllers accept commands at whatever speed the network sends them, otherwise they would miss commands. The speed of the processor is irrelevant as long as it can keep up with the network's commands. The bandwidth of the network matters at lot.

How many pixels you can drive on a LOR network is limited by how active your driving sequence is. Using SuperStar, we have found that very active sequences will overrun the available bandwidth on the network at about 300 pixels (900 channels.) If you make heavy use of macros or your sequence is not making a lot of changes quickly, then the number of pixels possible on a network can be dramatically greater.

[ItsMeBobO]

LightORamaJohn Made a post! Yeah! First one in three months.

[GaryMartin]

Yes, I worded that badly. What I meant was that the ELOR uses a Prop controller CPU instead of just a PIC. There's more processor power available so that it can keep up with the maximum throughput that the LOR network can do.

That's not a big deal compared to CCRs, but compared to stuff like FireFli (which doesn't keep up nearly as well) it matters.

LightORamaJohn wrote:

GaryMartin wrote:

Naturally we are assuming one LOR network per ELOR device here. That scenario has already been initially tested with good results, pushing 2k pixels with a LOR S3 -> ELOR -> E681 pixel controller setup.

There will be some more intensive testing, trying to push the limits but it seems to work fine so far.

You have to remember, when using CCRs, you're dependant on the speed of the CCR controller itself in listening and accepting commands. The ELOR uses a much faster processor and is able to poll it's incoming LOR network much more efficiently.

The last paragraph does not make sense to me. No LOR controller polls the network. Controllers accept commands at whatever speed the network sends them, otherwise they would miss commands. The speed of the processor is irrelevant as long as it can keep up with the network's commands. The bandwidth of the network matters at lot.

How many pixels you can drive on a LOR network is limited by how active your driving sequence is. Using SuperStar, we have found that very active sequences will overrun the available bandwidth on the network at about 300 pixels (900 channels.) If you make heavy use of macros or your sequence is not making a lot of changes quickly, then the number of pixels possible on a network can be dramatically greater.

[LightORamaJohn]

GaryMartin wrote:

...

That's not a big deal compared to CCRs, but compared to stuff like FireFli (which doesn't keep up nearly as well) it matters.

When the CCR was first introduced, LOR began migrating to interrupt driven network processing. This wasn't done because we were losing data, but because it significantly simplified the firmware.

I've thought about FireFli quite a bit over the years. It has a very nice form factor. I find it hard to believe that the processor can't keep up when it's only dealing with 16 pixels. The CCB is running 100 pixels and the additional complexity of macros with a PIC. Unless the FireFli processor is incredibly weak, I would be really surprised if transplanting the CCB code into a FireFli didn't fix the firmware problems.

[GaryMartin]

Unfortunately, the original FireFli-LOR code has issues with any commands shorter than 3/20ths of a second. It also has numerous issues with mis-interpreting network commands and turning on the entire chain, usually in red only for some reason.

The new DMX version of the FireFli firmware fixes all of that since it's being refreshed 40 frames per second.

I have seven FireFlis in my setup, on a seperate network (moving to DMX control for this next season)

LightORamaJohn wrote:

GaryMartin wrote:

...

That's not a big deal compared to CCRs, but compared to stuff like FireFli (which doesn't keep up nearly as well) it matters.

When the CCR was first introduced, LOR began migrating to interrupt driven network processing. This wasn't done because we were losing data, but because it significantly simplified the firmware.

I've thought about FireFli quite a bit over the years. It has a very nice form factor. I find it hard to believe that the processor can't keep up when it's only dealing with 16 pixels. The CCB is running 100 pixels and the additional complexity of macros with a PIC. Unless the FireFli processor is incredibly weak, I would be really surprised if transplanting the CCB code into a FireFli didn't fix the firmware problems.

[travis p]

anything new on e1.31

[Lee Lunday]

I too am looking for an update on E1.31

[Donny M. Carter]

Me 2!

[JonB256]

GaryMartin wrote:

The new DMX version of the FireFli firmware fixes all of that since it's being refreshed 40 frames per second.

I have seven FireFlis in my setup, on a seperate network (moving to DMX control for this next season)

FireFli running DMX was a huge improvement for me. I ran a total of 13 strings on 6 controllers. One of them had 3 strings, the rest ran 2 strings. It always kept up, no matter how fast I sent data. My programming definitely doesn't stress test LOR S3 or the DMX dongles (Pro type), but the FireFli DMX controllers always kept up.

[Lee Lunday]

Jeff, How is that ELOR working for you? I am thinking about getting one to work with.

Lee

[Lee Lunday]

I found some info on the E1.31 here. http://forums.lightorama.com/forum95/32811.html

Lee