Jump to content
Light-O-Rama Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About DrWizard

  • Rank
  • Birthday 06/22/1963

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Orange Park, FL
  • Occupation
    Retired Programmer

More About Me

  • Interests
    Computers in general, Lights in general, Microcontrollers
  • How I learned about Light-O-Rama -
    The Wizard's of Winter viral video from 2005.
  • Favorite Decorating Holiday?

LOR Software

  • LOR Software Version
  • License Level

Recent Profile Visitors

768 profile views
  1. So I just updated to S5 and discovered I cannot run the Sequence Editor over Remote Desktop, it gives an error that it needs a minimum version of 1.5 of OpenGL, and my system only has v1.1. The machine in question has Windows 7 with a Nvidia GeForce GTX650 card with the latest drivers and an OpenGL version of 4.6. My google research so far seems to indicate that it is Remote Desktop that is limited to v1.1, and so far, I'm not finding any workarounds for RDP. Yeah, I could use VNC instead, but the screen refresh rate in VNC is horrible compared to RDP. In RDP I can play a H.264 1080P video across the network and it plays just fine. Forget that in VNC, and likewise, S5 Sequence editor is unusable across VNC due to the terrible refresh rate. Anyone have a workaround for using S5 Sequence Editor remotely? Additional Info: Machine is an oldie but a goodie with an I7-860 3Ghz, 16GB Ram. I could (but would rather not) upgrade it to Win 10 if that will solve the problem but my research so far seems to indicate it would not. S4 S.E. ran just fine over remote desktop with a decent refresh rate and was totally usable. I have gone thru all the VNC advanced settings with no luck at speeding it up. Not fond of TeamViewer and it apparently suffers the same problem anyway. If you are wondering why the heck I am running S5 S.E. remotely, it's because #1) I'm not yet ready to make the full jump to S5 quite yet - I have a ton of scripts and utilities I have written to manipulate my S4 .lms files on my work machine, and #2) My show player machine is in the garage with no place to sit and it's waayyy too hot out there, even in the winter (in Florida).
  2. Is there any change to this status (IE: for S4 and S5 to coexist on the same machine)? I am tech-savvy enough to install one or the other in a virtual machine, but is there an easier way? I have a bunch of cool utilities I wrote to manipulate S4 xml files and there will be significant work involved to get them to work with the (much different) S5 files. Which I will eventually do, but for now...
  3. I had an idea for a security feature that could be exclusive to Light-O-Rama thanks to your more sophisticated communications protocol. Have 'Control Panel' "ping" all the known controllers every few seconds, and raise an alarm if one of them fails to respond, due to failure, [accidental] disconnect, blown fuse or ground fault, or even being stolen. The alarm function could be turned on and off from Control Panel when you are working on the hardware, and when on, if one of the controllers on it's list doesn't respond in a timely manner, it could play a sound file (configurable), pop up a big blinky message box on the screen, and/or send an email and/or text. It could also work with E.131 controllers (any brand) but it wouldn't work with generic DMX controllers (your competition(?)) due to their one-way communications.
  4. UPDATE: So I found in the manual where it says: "If all else fails... power the unit on and off after you click the download button" and that got it to upload. And yes, version 1.15 did fix the enhanced mode problem!
  5. So I've made a lot of changes to my show this year, added, rearranged, reconfigured... Started setting things up and some controllers/channels weren't working. After some troubleshooting I found a workaround and got it all working. It seems that my pair of LOR1602Wg3's with firmware 1.12 will not work in enhanced mode. They are less than 3 years old (bought at 2016 spring sale) My CTB24D and my pair of CTB16PCg3's DO work in enhanced mode, and they are all on the same network. So I noticed there have been a couple of firmware updates for this controller. I could not find a published revision history to see if this was an issue that had been addressed, but I downloaded version 1.15 anyway from the LOR website to my PC. But I cannot get the hardware utility to upload it to the controller. The upload just hangs at the beginning. Screenshot attached. I tried un-daisy-chaining them and connecting only one at a time but that didn't work either. So 1) can anyone tell me why enhanced mode is not working with these relatively new LOR1602Wg3's, and is firmware revision 1.15 supposed to fix this issue? And 2) Why can't I get it to upload? I've uploaded firmware to my old controllers in the past without a problem.
  6. Since most of my display is now LED, and since I have upgraded most of my controllers to G3, I was gonna implement LED dimming curves this year. I understand how to create my own, but I'd rather not reinvent the wheel. But I cannot find a pre-made LED dimming curve anywhere. Not installed with the software, and forum and google searches are turning up nada, nil, zip. Where do I find pre-made dimming curves?
  7. In between bouts of rain I did some more extensive troubleshooting today. Turns out my LOR1602Wg3's are not working with enhanced mode. Hmmm-- Why? Moving this to a new thread...
  8. One controller is an old LOR1602W "Model 3" (blue board). It is the only controller on the primary network using an old black RS-485 adapter. The AuxA network is set for enhanced mode and uses a red high-speed RS-485 adapter and has 5 controllers consisting of: 1 CTB24D, Gen 3, 2½ yrs old. 2 LOR1602Wg3's Gen 3, 2½ yrs old. 2 CTB16PCg3's, Gen 3, 7 mo.s old, bought at this year's spring sale. Network goes from 'puter thru 5' cable to the CTB24 (LOR ID 6), then thru a 40' cable to a CTB16 (ID 4), then thru a 75' cable to a 1602 (ID 3), then thru a 10' cable to the other 1602 (ID 2), then thru a 30' cable to the other CTB16 (ID 5), which has a 122.6Ω terminator. HU as mentioned, sees all 5 controllers correctly, but will only control lights on the first two: the CTB24 and the CTB16. Screenshot attached. Green LEDs on the CTB16's are solid green (indicating receiving a heartbeat) and displays on the new 1602's show the LOR ID (and do NOT display "no conn") Software is 4.3.36 Pro. (Will switch to 5.x after the holiday)
  9. Out of the frying pan, into the fire... I noticed right away (Before I ever posted) as I unpacked everything from last year that the contacts on the cables were corroded. I cut all of them off and put new ones on, and tested them all with a very expensive Time-Delay-Multiplexer cable tester. It checks ALL the electrical characteristics of the cable. There is no such thing as a perfect cable, and this tester tells you if everything is within specifications for cat5, cat5e, cat6, cat7... And I swapped cables around and tried several different ones anyway despite testing good. Turns out the cheap cable connectors also caused the RJ-45 jack pins in 2 of the controllers to corrode as well. Got those all cleaned up. Hardware Utility now sees all 5 controllers on the AuxA network, shows the Unit IDs (all unique),, model number, firmware revision, etc. Can control the lights on the first 2 controllers, but not on the last 3. Cant control 'em from HU or from Sequence Editor. Have double, triple, quadruple checked all settings for unit IDs, circuit/channel #s, and Network in the sequences, and the Network config. Everything seems to be exactly as I think it should be, and I'm stumped as to why it's not working. I'm not new at this, been using LOR since 2006 and I'm an electrical engineer. I have however, been known not to see the forest because of all the trees... Tomorrow I'm gonna try things such as using my spare RS-485 adapter, changing to non-enhanced mode, and chaining the other 5 controllers after the old Gen 1 one on the primary network.
  10. I don't have singing faces, a mega tree, or arches. I do though have lots of pixel strips, and a whole forest of trees in multiple colors on 48 regular channels. I do have a Blue Christmas sequence I have spent a lot of time on, and it includes a bunch of dummy channels representing different parts of the song, as well as a polyphonic transcription and spectrum breakdown. lor@wizlights.com
  11. That song has been on my to-do list for 2 years. May I have a copy of your sequence please? lor@wizlights.com
  12. Not only have I added a lot to my show this year, but the old stuff has gotten moved around to integrate the new stuff. With so many changes it's hard troubleshoot stuff that worked last year... I added 2 new controllers this year, but they are not talking. The network (RS-485) cables are somewhat long and I'm thinking I may need a network terminator at the end of the line. But I didn't need one last year with 3 controllers 200' from end to end. Computer connects with a red HS enhanced adapter with a 5' cable to a CTB24Dg3 (#1). CTB24D connects with a 75' cable "A" to new CTB16PCg3 (#2) From there with a 100' cable "B" to a LOR1602wg3.(#3) From there with a 10' cable to #4, and from there with a 50' cable to #5, but I haven't gotten that far yet... With just the first 2 controllers connected, the Hardware Utility sees both of them. When I connect the 3rd controller, the HU only sees the very first one. If I bypass the 2nd controller, and connect the first to the third, the HU sees both controllers. If I change the order to 1-3-2 the HU only sees the first controller. The cables have been tested with a fancy-shmancy TDM tester that checks for capacitance, crosstalk and all sorts of other conditions and they all test just fine. So do I need to add a 120 ohm resistor across pins 4 and 5 on the last controller on the line?
  13. I disagree. I know how to convert a half wave string to full wave, and it's not that hard. But by rectifying the power before it goes into the controller, I effectively convert 16 strings all at once. It will be even easier to cut a short extension cord and put a rectifier in the middle of it than clipping the LED string in four spots and inserting 4 separate diodes. Triacs, once turned on, stay on as long there is voltage to the anode, even after removing the signal from the gate. They turn off only when the anode voltage goes to zero. So they will work on non-filtered rectified DC. Likewise, the zero crossing detector doesn't detect the voltage crossing zero, per se, it detects that it has gone to zero (or more accurately, when it is not at zero) so that should continue to work as well. Using an AC transformer on full-wave rectified DC results in doubling the frequency (no big deal) and substantially drops the output voltage, and can cause it to overheat. I will definitely need to provide a separate non-rectified source for the transformer. OR, better yet, I could just take it out completely and feed the logic circuit with the 5V DC power supply I already have which drives my pixels, arduinos, and other stuff. Very good point!! I had not considered that one! If I keep the controller close to the lights with short wires, that should not be a problem, but I wasn't planning on doing that. I keep the majority of my controllers centrally located in the garage. This actually may be the one factor that keeps my experiment from working. Possibly. It does double their heat output. If the strings were designed to take advantage of being half wave, and supply peak current a little above what they are rated for (as is oft done with LED matrices) then that could be a problem. I have converted a few cheap Walmart strings to full wave though, and they worked fine. Also, in my sequences, I try not to leave the strings on at 100% for an extended period of time. If I plan to leave the string on for a while, I tend to do it at 75%. I especially try to do that on blue, green, and purple strings to reduce failures of the individual LEDs. I could also make a custom dimming curve to reduce power, but that negates the point of converting to DC to make 'em twice as bright. Truthfully, I feel everything is plenty as bright as it is, but I thought this would make an interesting experiment. Thanks to everyone for their input!!
  14. I have a cheap one from eBay and it works fine. It's actually meant to be a USB to DMX adapter, but of course DMX uses the RS-485 protocol. If you want to run an 'enhanced' LOR network, you need to make sure the chip in the adapter is the FTDI brand, and that it is a genuine FTDI, as there are a lot of counterfeit FTDI chips out there, and FTDI has changed their drivers to detect the counterfeits and not work properly. As I understand it- DMX uses a kinda oddball baud rate of 250,000 which the FTDI chip supports, but most other USB to Serial chips (Prolific, CH340) do not. Thus any RS-485 adapter meant for DMX should, in theory, use the FTDI chip. But again, beware of counterfeits. And DMX uses a different pinout on the RJ-45 connector than LOR, but I see you're already on top of that.
  15. I am planning to run an experiment soon... I am going to put a high-powered high-voltage (400V 25A) bridge rectifier before the power input to the controller. The purpose of which is to make all of my half-wave LED strings work at full-wave and be twice as bright. Since the DC will NOT be filtered, I believe the triacs will still work, and will cut off as they should when the voltage goes to 0v 120 times per second. I also think the zero crossing detector circuit should continue to work for the same reason. Where I anticipate a problem is the transformer that drops the 120VAC to a lower voltage to operate the controller. I will need to isolate that from the power to the triacs, and provide a separate AC power source for it.
  • Create New...