Jump to content
Light-O-Rama Forums

LightORamaJohn

Administrators
  • Content Count

    252
  • Joined

Community Reputation

0 Neutral

About LightORamaJohn

  • Rank
    Member

Profile Information

  • Location
    Morristown, NJ
  • Occupation
    b

More About Me

  • Favorite Decorating Holiday?
    c

LOR Software

  • LOR Software Version
    5.1.4
  • License Level
    Pro

Recent Profile Visitors

483 profile views
  1. Exactly, you can configure it in a couple minutes: The Pixie is based on a 16-bit processor which only has enough RAM to support 3,200 pixels. So the max is 200/port. The idea was to provide users who wanted only 10 to 20 thousand pixels with an inexpensive, easy to configure and cable up solution. We sell a lot of these, so we think we've guessed correctly. As an engineer, it's easy for me to understand and use null pixels and power injection, but as an intrinsically lazy person, it's just too much of a nuisance to setup, configure and then repair displays built that way. I think most commercial users believe this too. It's just so much easier to replace a prop, or pull out a defective pixel string and replace it. It's nice to have a prop that's self-contained, so it's not attached to a bunch of other props.
  2. The device has been ready for a while. We've had them in stock for at least 6 months. So, we've been using them for a while and have had no problems -- of course, people using them in real displays will likely expose something(s). We're confident in the hardware. However, we wanted distribution of new firmware to be easy for customers... There were two problems, one was releasing it right before Christmas, which would have incurred a support load we didn't want, and the other was the bootloader. Dan wrote the bootloader in all our devices in LOR year 0. So, as devices became more complicated, bootload times started creeping up. They finally became ridiculous with the N4 director and PixieLink adapter. So, the bootloader has been re-written for these devices. To take advantage of this, we have to distribute a new Hardware Utility. We will merge that into the next PC software release, which we hope isn't more than a month off. There is another minor problem in that we are just being allowed to restart our operation. We have the PixieLink boards, the cases, and the firmware, but they have to be assembled, programmed, & packaged. So, that will happen after we recover from the Mad Grab Sale. Since the PC software and hardware assembly are done by different groups, these should both be ready in a month or so. I hate giving dates, because as we just experienced, the universe has been particularly uncooperative lately. If we are going to miss this date significantly, I will get some of these out to beta testers so that any problems can be resolved well before Christmas.
  3. The PixieLink adapter is not a pixel controller. It maps 192 E1.31 universes to its six RS485 ports. If we were to go the route of using an additional universe just to target the remaining 30 pixels/string, it would have to handle 384 universes. This probably isn't possible, but even if it is, it would mean that the LAN bandwidth consumed by a fully loaded PixieLink device would jump from 32+Mbps to 65Mbps because I have only seen full DMX payloads regardless of the configured pixels/string. It seemed to us to be the wrong way to go, especially since almost no one does power injection to get above 150 pixels/string anyway. Using multiple universes to target one pixel string is an artifact of the higher cost of LAN based E1.31 pixel controllers. The Pixies were designed to make it possible to distribute the controllers rather than use null pixels and power injection. LOR users typically build props like trees, faces, arches, or outline something. If you are just doing a huge matrix, you are probably better off doing it with an E1.31 Pixel controller. There is a new protocol in Pixies specifically for the PixieLink device. You should not use ELOR when using a PixieLink adapter to talk to Pixies. When the PC transmits ELOR, it compresses across pixel strings and across controllers. This is impossible because the PixieLink adapter does not know what Pixie controllers are hanging off its ports. An even if it did, it would have to compare all the universes destined to a port to recreate the compression. This would delay transmission, and I don't think there is enough processor power to recreate the compression in real time. Also, it would be really hard, so I'm tapping out on this. ELOR has a maximum speed of 1Mbps, and usually this speed along with the compression works well. But, I felt that in order to make the Pixie viable for any user (meaning non-LOR too) of E1.31 pixel controllers, it would not be good enough to say your display will probably work well. I wanted guaranteed bandwidth to the Pixies. The new PixieLink protocol that Pixies with 1.05 firmware understand runs up to 8.5Mbps. This allows me to send uncompressed intensity data with guaranteed delivery regardless of complexity.
  4. The PixieLink Adapter does process standard E1.31. Everybody's software already has the ability to transmit E1.31, it would be silly to create some new protocol. The idea was to make an inexpensive device that would allow Pixies, and other LOR G3 controllers, to be easily moved to a standard E1.31 environment. The Pixie firmware, that supports the higher speeds used by the PixieLink Adapter, also supports 200 pixels/port. This is not possible with standard E1.31 since it really is just an IP transport for DMX universes. We will most likely allow (at some point in the future) users to configure universes that have 600 intensities instead of the 512 permitted by DMX -- this internal LOR discussion sounds like we may be running a non-standard E1.31; all we've done is allow the PixieLink Adapter to process a universe in the E1.31 message that is bigger than 512 intensities. Presumably, the Adapter will never see this larger packet from non-LOR software.
  5. The PixieLink adapter converts E1.31 for Pixies (and other LOR controllers) this. See:
  6. The PixieLink adapter allows you to operate your Pixie and most other LOR controllers over Ethernet in a standard E1.31 environment. The attached manual is mostly complete; hopefully the verbiage won't have to be to changed much; depends upon feedback received here. I’m waiting on a couple items. All the pictures have to be redone, but the changes will be cosmetic. We really didn’t want to offer this before last Christmas. The device is easy to use, but fairly complex internally. More time in QA seemed prudent. It’s already difficult to help customers without the introduction of a new device so close to Christmas. Since we have these in stock; we’ll probably offer them as part of the Mad Grab sale next month. This will give people a lot of time to experiment with them, and for us to correct any problems and make any improvements necessary before Christmas. Thanks in advance for feedback. This is the first time we're putting a manual out in draft form. I'm hoping this results in a better product. PixieLink_Man_Web.pdf
  7. You cannot add a pixel IC profile. These are coded into the Pixie. I have implemented the GS8208 (which is also the WS2813) in the next release of the Pixie firmware. If you submit a trouble ticket and send it to me, I can send you interim firmware and you can see if it works. I don't have a GS8208 string to test, but the waveform looks correct on the scope. It looks like you want firmware for a Pixie4, put that in the ticket.
  8. Here's the brochure. We are still playing with the web configuration interface, so I haven't finished the user manual yet. PixieLink.pdf
  9. Singing Trees are pixel based with two 100-pixel strings. You could program them that way, but that is very inconvenient because programming each tree would be different, and it would be time consuming to manipulate 200 pixels. The Pixie controllers have a 'tree' option in the configuration. The trees have names; Zuzu, Elden, Felix, & Ralphie. You configure the 'tree' option. Then the first 8 pixels (24 channels) of the first unit ID controls the face. Pixel 1 is the outline of the tree, Pixel 2 is the topper, Pixel 3 is eyes closed, Pixel 4 is eyes open, Pixel 5 is mouth closed, Pixel 6 is mouth half open, Pixel 7 is mouth full open, & Pixel 8 is mouth O. You can still use the full range of colors/intensities, the programming is consistent across faces, and much simpler than manipulating the individual pixels. You can only have 1 singing tree on a CCCII (Pixie2), ..., and 8 singing trees on a Pixie16.
  10. TheDucks explains how to quickly change the unit ID/network above. A 1M enhanced network should easily handle 16 50 pixel ribbons.
  11. No, only the original CCR is based on the primitive RGB IC. The CCR II has current generation 256 intensity RGB ICs, so it has twice the number of intensities that the original CCR controller simulated. The CCR II ribbon (or pixels) will be smoother than the older controller because if this. The CCR II controller is a Pixie and can control the old CCR ribbons, but it does not simulate intensities beyond what the RGB IC does natively. One thing I have noticed is that people will sometimes not use an enhanced network when driving pixels/ribbons. The older, non-enhanced, network protocol is incredibly command intensive and this can make displays look choppy. This occurs because people are dramatically upping the number of pixels on a network and the older network protocol performs poorly in that situation.
  12. The RGB IC in a CCR ribbon is a very old device that only supports 32 intensities. The CCR controller creates 128 intensities by rapidly updating the pixels and mixing an intensity with some off time. During every four ribbon updates, the controller will use the lower of two adjacent hardware supported intensities once, twice, or three times before switching to the next higher hardware intensity. This happens rapidly enough that your eye integrates it. So, if the CCR turns the pixel on for 3 of the 4 updates, you get an intensity that is 75% of the way to the next intensity supported by the RGB IC. The Pixie does not do this. If your fades are slow enough, your effects will appear choppy.
  13. Capabilities of the Pixie hardware with 1.04 firmware: LOR regular or enhanced networks at speeds from 19.2Kbps to 1Mbps. 170 pixels/port maximum. LOR regular network support is primarily for compatibility with old CCR/CCB sequences. Compatibility (resolution/macros/color effects) mode is only supported for 50 pixel/port configurations when running on a LOR regular network. You can run a LOR regular network with any number of pixels/port up to 170, but the complexity of LOR regular network commands may cause a lack of smoothness with more than 50 pixels/port. S4 PC Software considerations: The Sequencer and SuperStar addon can be configured to generate commands in either network mode. The Pixel Editor will only generate commands for enhanced mode networks. This may be the cause of confusion, if you use the Pixel Editor and set the network type to LOR regular, it will not work. Enhanced network mode will result in the smoothest transitions because it is designed for RGB pixel displays, you should always configure for Enhanced mode if possible. S5 PC Software should always use Enhanced networks.
  14. The support ticket was created at 11PM Friday night. It would have been fixed on Monday morning when people came in, but I forced it now.
  15. Pixie firmware versions: 1.01 Initial release version, bootloader does not work. (must be returned to factory to update bootloader) Macros, color effects, and standalone are not implemented. Only full resolution and resolution 1 implemented. Hold down test button to run test pattern on pixels. Supported: WS2811, WS2801, SM16716, LPD6803, TMI1803, TMI1804, TMI1809. Max pixels/string: 100. 1.02 Initial release version (same as 1.01), working bootloader. 1.03 Macros, color effects, and resolution implemented for 50 pixel ribbons/strings. (original CCR compatibility mode) Single shimmer timer for all pixels (LOR effect). Implement DIP switches for 2nd generation Pixies. Implement standalone - bug can cause standalone sequence to hang. Test button: Hold during power up to reset controller. Hold 5 secs while powered up to reset controller. Press momentarily to start pixel test pattern. Press momentarily again to stop, or wait 5 minutes. Implement DMX input for Pixie2 & Pixie4 - has two bugs. Add RGB ICs: 943, UCS1903 (Use WS2811 for UCS1903, timings adjusted for both) 1.04 4.3.34 Hardware Utility or later required to configure props & per port color order. If you have an earlier version of LOR software that supported Pixie configuration but does not recogninize your pixie with 1.04 firmware then you should upgrade to 4.3.34. If your license does not support upgrading to 4.3.34 and you are not ready for a license renewal then you can use the LOR_DeviceFile.txt (below) which should allow you to configure your pixie with 1.04 firmware. (Replace file normally located in C:\Program Files(x86)\Light-O-Rama\) Support Pixie4DMX (iDMX1000 replacement). Fix DMX input to Pixie2 & Pixie4. Fix boundary problem in Enhanced Network mode that could lose last pixel's data. Fix standalone hang. Standalone transmit rate changed to 500K. Implement Props (singing faces). Implement regular LOR network DMX intensity command. Implement port selectable color order. Max pixels/string: 170. 1.05 Max pixels/string: 200 Props (singing trees) on Pixie16 increased from 4 to 8. If number of pixels/string on Pixie16 set to more than 100, then LOR effects are disabled for all channels, before this version it would always process LOR effects on the first 50 pixels when in LOR network mode. Support for PixieLink protocol Allow Pixie2 in DMX to have 100 pixels on second string. DMX intensities 1-150 = first string 50 pixels. DMX intensities 151-450 = second string 100 pixels. RGB IC GS8208 (also WS2813) RGB IC APA102 (also SK9822) Fatal error 41 halt fixed */ LOR_DeviceFile.txt
×
×
  • Create New...