Jump to content
Light-O-Rama Forums
Sign in to follow this  
ben

E1.31

Recommended Posts

GoofyGuy wrote:

Donny M. Carter wrote:
Also the ELOR will be out soon! It will convert LOR to E1.31

http://www.sandevices.com/ELORinfo.html

This looks like the route Im taking so far Donny. 

Good insurance policy if support is not ready. I will be getting one either way myself.

Share this post


Link to post
Share on other sites

It will be a good decision IMO! You can have your cake and eat it too! Being able to use LOR controllers and run pixels will be cool.

Share this post


Link to post
Share on other sites

Donny M. Carter wrote:

It will be a good decision IMO! You can have your cake and eat it too! Being able to use LOR controllers and run pixels will be cool.


MMMM cake, dont know how or why cake is involved but already makes it better.

The adapter has 4 1.31 universes and a DMX 512 universe, cant lose. All of my worries are taken care of with 1 cable.

Share this post


Link to post
Share on other sites

well i am going to wait till Dan brings out 1.31 in S3 as he said he would so i will give him a chance. great to see options out there but i would rather just use 1 peice of software to do the job.

Share this post


Link to post
Share on other sites

Hey Dan

Any news on how E1.31 is coming along in S3? It's been a couple months since you nave chimed in on the topic. :P

Share this post


Link to post
Share on other sites

Ben monro wrote:

well i am going to wait till Dan brings out 1.31 in S3 as he said he would so i will give him a chance. great to see options out there but i would rather just use 1 peice of software to do the job.


I have been thinking the same thing Ben.

Share this post


Link to post
Share on other sites

So if it is November and the E1.31 support is not ready, what will you do? Will you scrap the pixels you have planned and wait until next year?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Program looks pretty cool.

Yes, Streaming ACN is E1.31.

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

×
×
  • Create New...