Jump to content
Light-O-Rama Forums

GaryMartin

Members
  • Content Count

    126
  • Joined

  • Last visited

Community Reputation

4 Neutral

About GaryMartin

  • Rank
    Member

Recent Profile Visitors

106 profile views
  1. The animated pumpkins are video projection, you can find the guy's stuff here: http://www.halloweenforum.com/sale-merchants/128415-new-singing-pumpkin-projections-new-pricing.html
  2. The snowmen are using TSL3001 based pixel strips, 32 pixels per meter, 32 ICs per meter, 5 vdc. There are 134 Pixels on each snowman with all of them connected to a Sandevices E681 controller.
  3. The only thing I've found to work for me is a Daisy pellet gun, 10 pumps. We're thick with squirrels and rabbits here.
  4. Here's LOR S3 (3.80) running over 1k pixels at very high speeds without any issues whatsoever. Many thanks to those that worked on this addition, it's performing quite excellently! (the snowmen in front have 134 pixels on each one of them, E1.31 out to Sandevices E681s to talk to them)
  5. First off guys, thanks for E1.31! Now having said that, I have some requests to make life a LOT easier using LOR's DMX modes. First off, a more efficient way to convert existing channels from LOR protocol over to a DMX universe. I am unable to find any way to change an entire controller such that it will automatically address the channels. I have been switching all of my DC controllers and FireFli controllers over to DMX. I've had to do the following: 1. Change the controller type to DMX. 2. Change the universe to it's appropriate value (2 in this case) 3. Change the address to the DMX address I want it to have. Now that may not sound that bad, but I have 7 FireFli units that I just changed. 7 * 48 channels or 336 times I had to repeat the above. It would be great if we could drag a box around a group of channels and tell it to set them all to DMX, all to Universe "X" and start the addressing at "Y" and let it go to town. The Channel editor is a MAJOR PITA when it comes to setting DMX address btw. If you could open up that input box so we could just directly key the number, it would be MUCH easier than using the mouse wheel, or scrolling the choice box. That approach worked fine when we were picking a number from 1 to 16, but when picking from 1 to 512 it becomes very very frustrating, very quickly. Side note: Deleting controllers could be much easier if one were allowed to delete a range of channels. Having to do one channel at a time is quite tedious. Now, those editing issues aside, here is a future feature request I hope you guys will consider: We have moved into the realm of thousands of channels dealing with RGB pixel elements. While it's very cool being able to control each light on a string, sometimes we just want to control an entire group of RGB elements. If you could add the ability to define Master channels, a *single* channel in the grid that controlled multiple, user-defined channels as an entire group, that would really rock! I have some new snowmen fixtures that use RGB pixel strips around each circle. If I could have a channel to control just the bottom circle's worth of pixels, the middle and the top circles, it would make life with pixels far more convenient. Heck, I could make a Master channel that controlled all pixels in each snowman, and then one that controlled all 8 snowmen at once! (each snowman uses 130 RGB pixels for 390 channels per fixture)
  6. 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: 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.
  7. 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: 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.
  8. Actually Jeff I've been hanging out in the back there for weeks, you just haven't noticed! Jeff Millard wrote: Have you been peeking through the window to my workshop Gary??? :cool: Jeff
  9. 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: I'm with you. I just don't understand how someone says they will wait, unless they don't have a plan for pixels.
  10. Also, here are the links direct to the ESTA site to get the E1.31 detailed specs. Unfortunately there is a charge to get the official document. http://www.opendmx.net/index.php/E1.31
  11. To help with development of E1.31, or Streaming ACN, here's a great utility to use to monitor the output channels. sACNview is a very handy thing to have around: http://sacnview.sourceforge.net/documentation.html
  12. Correct. IIRC, David Moore used about 80 of the small 3 channel devices on a *single* universe last season. JonB256 wrote:
  13. geronc wrote: Heh, I have four of the E680s and four of the E681s. I used three E680s on the megatree last season and am waiting for native support from LOR to use the rest. One HUGE question I have though, is how well will LOR S3 run with 8,000 channels configured? I used to think I was pushing it with 650 channels but the sequences are going to get *huge* very shortly.
  14. I'm using about 140 strings of CDI and in my third year with some, second year with the rest. No failures and they still all look as bright as the day I got them. Note: I didn't buy any the year CDI had supplier issues. Lucked out there.
×
×
  • Create New...