Jump to content
Light-O-Rama Forums

LightORamaJohn

Administrators
  • Content Count

    243
  • Joined

  • Last visited

Everything posted by LightORamaJohn

  1. TheDucks explains how to quickly change the unit ID/network above. A 1M enhanced network should easily handle 16 50 pixel ribbons.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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. LOR_DeviceFile.txt
  7. Here's the one I used. It's possible the latest version of LOR is organized differently; I don't follow the software that closely. LOR_DeviceFile.txt
  8. Looks like a bug in that Hardware Utility. Attached is an old one. Right click the light bulb and select unload Light-O-Rama just to be safe. Then drop this on the desktop and see if you can fix the end to end problem. LORHardware.exe
  9. For 5v pixels, we generally use 20ma/color, so for one row: (0.20amps)(3 colors)(48 pixels) = 2.88amps/row. 8 rows, one side of a Pixie16, would be 23amps; which is well within limits. 20 rows is almost 58amps. It might be the case that there is a peculiar power dip because all the LEDs come on full white and this is preventing the microprocessor from properly booting. The Pixie16 is powered from the port 1-8 power supply. Try pulling the row pixel string plugs for half of the strings powered by the power supply connected to ports 1-8. If the Pixie behaves correctly, you will probably have to dedicate each of your 30 amp power supplies to one side of the Pixie16 and get a smaller supply for the Pixie4.
  10. It doesn't matter if you configure more pixels than there are in a string/ribbon. Data beyond the last physical pixel is ignored. The only effect you will see is when using the test button to test the pixel strings/ribbons. There will be a pause before the controller steps to the next color because the controller is sending data to non-existent pixels at the end of your strings/ribbons.
  11. If your Pixie has a DIP switch, setting all positions to 'off' means you want the Hardware Utility to set the Unit ID. If any switches are on, then the DIP switch overrides the Hardware Utility setting when the controller next powers up. There is only one manual for all Pixies. The new manual was put up a couple days ago.
  12. Maybe a different wording. If you set the number of pixels to anything other that 50 with the Hardware Utility, the only logical resolution that you can set in the Hardware Utility that does anything is 1. If you set the logical resolution in the Hardware Utility to anything other than "1" with pixels strings that are not 50 pixels, the logical resolution is ignored and you get the full resolution of whatever number of pixels you configured.
  13. When the number of pixels is anything other than 50, the only logical resolution that works is "1", which makes the string will look like a dumb rgb ribbon. Any resolution other than "1" when the number of pixels is other than 50 means the controller will operate at full resolution.
  14. A enhanced network requires that the Comm Listener be running for LOR programs to access the network (except the Hardware Utility). There should be a "CL" icon near the "SE" and "PE" icons. Make sure you started LOR by running the LOR Control Panel from the start menu. There should be a red light bulb in the list of icons displayed when you click the "^" on the lower right.
  15. Just noticed this thread. I have a beta release available, but would like to release just the Pixie16 version. I've tried to mimic the CCR, but this is pretty much a rewrite so until people actually run it on their props we won't know if it's close enough to the original CCR/CCB/CCP. Are you interested in running this through on your equipment and then submitting tickets where it falls down? Tracking troubleshooting conversations through this forum is just too hard. Once we get the Pixie16 working, the others should have few, if any, problems. These are the changes in the interim: If the number of pixels/port is 50, then color effects, macros and resolution should work. The implementation is very different in this controller, so the timing could be slightly different. The number of pixels has been increased to 200/port on the Pixie16 and 400 on the other Pixies. The current LOR software supports 170 pixels/port. The support for more than 50 pixels/port requires an Enhanced Network -- the processing and memory resources required for a regular network are just too much. There is a single shimmer timer for all pixels when running on a regular LOR network. A standalone sequence can be downloaded. Standalone used to send commands to other controllers at 19.2Kbps, it does that at 115.2 now. The Test Button behavior is different. If the button is held while powering up the controller, it tests the EEPROM and resets the controller -- it will flash the status LED rapidly if everything is OK and you should release the button to allow the controller to boot, otherwise it will flash an error code to indicate what's wrong with the EEPROM. If the button is pressed momentarily while the controller is powered, it will run the test pattern until you press the button again or 5 minutes goes by. If you hold the test button for 5 seconds while the controller is up, it will reset and reboot the controller. You will know this is happening because the LED will flash rapidly and you can release the button. The interactive inputs are implemented.
  16. The UF50D uses exactly the same firmware as the CF50D, and that firmware has been upgraded to understand enhanced networks. If you load the latest firmware the UF50D should work. DIP switch 11 being ON tells the firmware that it's in a UV flood as opposed to RGB.
  17. The easiest way to play with this is the Hardware Utility. Make sure shows are disabled and the Sequence Editor is not running so the Hardware Utility can get the USB port. Start the Hardware Utility and click Refresh to find your controller(s). Note the unit ID of the 50w F -- it will show up as "nn - F50RGB" Note the nn unit ID. Depending upon your version of the Hardware Utility, click the Console or Light Console button. Make sure the correct unit ID is selected in the Console. Move the first three sliders to set the color you want to strobe. Then move slider 5 to 50% intensity -- the flood will flash about once/second. You can experiment moving 5 up and down to get the flash rate you want and note the Intensity level for your sequence. You can move slider 4 up to make the flashes longer. Again, note the Intensity if you want to change this in your sequence.
  18. Yes, these are black light floods. The flood head only accepts one 50w LED chip. The back of the head is a pretty large heat sink that isn't designed to dissipate 100w. The head would have to be almost twice as big to contain both RGB & UV LED chips. For comparison purposes, the individual flood heads on the older CCF were about 18w. Other than the UF50D being designed for outdoors, the big advantage of it is that LEDs are instant on/off so strobe effects are possible. The datasheets and user manual are ready, so I'll ask to have them put up on the doc page.
  19. The replacement flood is 50w and is being manufactured now. There are two versions, RGB & UV. The flood head contains the controller and there is a separate power supply; both outdoor rated. To the software they look and are driven exactly like a single head CCF. I will get data sheets and a user manual up this week.
  20. CCB/CCP controller needs v1.18 firmware to correct this problem. See this thread: http://forums.lightorama.com/index.php?/topic/29328-ccbccp-preventing-garage-door-opener-transmitters-from-working/
  21. Make sure there is nothing wrong with the USB485B adapters: Even if they are not configured properly in the software, as long as they are plugged into the USB port, they should supply accessory power. If they are supplying accessory power, LED1 on the ELLs should be flashing about once/second. Some PCs have high and low power USB ports. If you find that the ELLs flash when the USB485B is plugged into one PC USB port but not another, that could be the problem. There is no limitation on the number of ELLs you can use other than the maximum of 16 (one on each USB485B on comm ports 1 through 16.) The Hardware Utility on recognizes the ELL when it first starts up. If you change the comm port, you probably have to stop and restart the HWU to get it to see the ELL on that port.
  22. You should not have a problem controlling the d-light controllers. Many years ago I did find that two-way communications with d-light controllers seemed to require a d-light adapter, so hardware utility type functions (set unit id, see all controllers) did not work with a LOR adapter.
  23. The jumpers on the CMB24D that select LOR Network or DMX E1.27-2 change the wiring of the RJ45 jacks. These jacks are always RS485 and should never be connected to a LAN. When these jumpers are in the LOR Network position, the RJ45 jacks are wired to be connected in a standard LOR Network and/or use LOR USB485 adapters. When these jumpers are in the DMX E1.27-2 position, the RJ45 jacks are wired in the way commonly used by DMX networks. The Entec Open DMX has an XLR5 connector. You would need to purchase a standard XLR5 to RJ45 converter. It would map the wires in the XLR5 to an RJ45 connector with E1.27-2 wiring. In this case, you would put the CMB24D jumpers in the DMX position. If you use a LOR USB adapter, leave the CMB24D jumpers in the LOR Network position even if you are running DMX through the adapter.
  24. No problems have been reported by multiple users, but I would recommend using it only if your remote garage door opener does not work. The attached firmware does two things. 1) It changes the data clock frequency. 2) It only updates the bulb strings when something changes. During the day when the display is inactive, there should be no interference. During a show, it depends upon how active the bulbs are. It only takes a fraction of a second of inactivity for the GDO to get through unimpeded. Even when the bulbs are continuously active, the change in data clock frequency allowed me to open the door, but the range was restricted. If you find any anomalies in the way the bulbs work it's probably because I missed a spot where I need to update the bulb strings. In this case, please explain exactly what effect/activity you had on the bulbs when they messed up. Old firmware version here: http://www1.lightora...B100D-V1_16.lhx CB100D-V1_18.ZIP
  25. No problems have been reported by multiple users, but I would recommend using it only if your remote garage door opener does not work. The attached firmware does two things. 1) It changes the data clock frequency. 2) It only updates the bulb strings when something changes. During the day when the display is inactive, there should be no interference. During a show, it depends upon how active the bulbs are. It only takes a fraction of a second of inactivity for the GDO to get through unimpeded. Even when the bulbs are continuously active, the change in data clock frequency allowed me to open the door, but the range was restricted. If you find any anomalies in the way the bulbs work it's probably because I missed a spot where I need to update the bulb strings. In this case, please explain exactly what effect/activity you had on the bulbs when they messed up. Old firmware version here: http://www1.lightorama.com/downloads/CCB100D-V1_16.lhx CB100D-V1_18.ZIP
×
×
  • Create New...