Jump to content
Light-O-Rama Forums

Richard Hamilton

Members
  • Content Count

    1,244
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Richard Hamilton

  1. It would help to know what controller and LED lights you are talking about.
  2. Interesting. I am able to do that effect in PE on a tree that has RGB bulbs. Maybe you are using something different? Agree though, I use both PE and SS for different effects.
  3. That's cool. I've been using Weather Watcher Live for the past few years. If you are familiar with that software, can you tell me how Weather Conditions 3.0 is different? thanks
  4. Being an electronics engineer, I agree with your comment. Thanks for clearing things up. What I was referring to is that a string of commercially available lights will always quote a wattage or current at 120V AC even if the string might actually be working at a lower voltage via an inline device reducing the voltage. And since the controller output strings are 120VAC, it is an apples to apples comparison. It seems that you understand that. 😁 So, I am suggesting that the OP compare the amperage or wattage that is quoted on a string of lights from the manufacturer and use that as the guideline.
  5. Just to embellish on the reply a little bit. If you want to know how much amperage will be drawn from your outlet. Add up the amperage from all strings that you put on the controller. Although the controller also draws some current, it isn't a lot in comparison to your light strings. This gives you a ball park amount of current that you will be using. And with LED lights, you would won't even get close to the limit.
  6. Just as an fyi, although reinstalling may have been needed to correct your problem, I had a similar problem a couple months ago and was resolved by simply restarting Windows. I think it had something to do with trying to test my lights while I also was running a schedule in the background without realizing I was doing that.
  7. PROBLEM SOLVED. I got colors in sync across all controllers. Here is what I concluded after a couple of hours testing controllers one at a time in my living room with the hardware utility and sequence editor. For reference, all of my Pixie 2D boxes and CCRs (over 10 of them) are relatively new and running firmware 1.03. Some were bought last summer and some bought this summer. Software is 5.1.4 Pro. All these on the same network. Apologies for along post. Trying to give detail info. It's complex to describe. The issue is software related. It's not network or speed related, not jumper differences, etc. If you understand all of below, then you probably haven’t had any alcohol today 😊 Using the hardware utility, a couple of Pixie2D controllers always show the color order as RGB in the dialog regardless of the order I set. However, controllers were actually accepting the color order changes. I could confirm it by running the 3 primary colors in the same utility after I made color order changes. Problem 1: When clicking “refresh” in the hardware utility or restarting, it wrongly defaults to show color order as RGB in the Cosmic Color/Pixie Config dialog, regardless of what I previously set. The controller actually has the correct order in EPROM. The dialog is not initializing the “RGB Order” list box with the correct value; thus misleading me. The same thing happens with the “number of pixels per port” list box. Of interest is my Pixie2D controllers from last summer display the correct color order in the HU dialog when I change the order. Those controllers were originally set to BRG. Thus the dialog is initializing properly for those controllers. It’s only 2 controllers I bought this summer that don’t give the same result. It’s best to set the hardware utility config to the color order that shows the same string colors when testing each primary R, G, & B color in the utility. I attempted to correct color mismatches for the newest controllers in the sequence editor by setting the prop definition to the same color order indicated in the hardware utility. It’s a nice feature to set the color order of props for devices in the sequence editor. Problem 2: There is a mismatch between the color orders in the hardware utility and the sequence editor. See this table: Set RGB in Prop definition if hardware utility is set to RGB. Set RBG in Prop definition if hardware utility is set to RBG. Set GRB in Prop definition if hardware utility is set to GRB. Set BGR in Prop definition if hardware utility is set to BGR. Set BRG in Prop definition if hardware utility is set to GBR !!! Set GBR in Prop definition if hardware utility is set to BRG !!! Notice the top 4 settings are in sync, but the bottom two are reversed. Not sure why it is this way. If all of my devices in the prop definition of the sequence editor at set to RGB, then a couple Pixie2D controllers are out of sync with other controllers. I figured out as mentioned above, if I set each controller to a color order that displays the proper color in the hardware utility, and experiment to set the color order in the sequence editor prop definition to get correct colors, then all is well. It just seems strange that a couple controllers need to be set to RGB, but other similar controllers default to BRG. I never changed them as they recently arrived from the summer sale. I expected they would all come set the same way. Bottom line is although I was reluctant to change color order in the hardware utility from factory settings (worried to mess up something), it was the way to fix the colors. So if a developer is listening, someone might want to look at why the above two color orders don’t sync up between the hardware utility and the sequence editor. Secondly, why does the hardware utility properly initialize the dialog with correct values from EPROM on some Pixie2Ds, but not on others? Gee, I need aspirin now. 😊 No, this is not a complaint…. Just information of what I found. Maybe I am just confused or perhaps this info is in the manual, yet I didn’t find it.
  8. Hmmm, yes, I guess in theory that is entirely correct about moisture content. Having said that, with my little transmitter, I've never noticed any distance reduction whether snow, rain, or low humidity and dry.
  9. dibblejr, sure, maybe I did not make it clear in my post above, but I have looked at the documentation and forum postings. There is only one jumper that seems to be relevant.... J5 which should not be installed. It isn't. Since this morning I am confident I have found the issue and it involves a problem with the software (Hardware Utility & Sequencer combination settings) that I think needs to be fixed and appears to have been there a LONG time. I will give details later after I complete my testing and confirm my suspicions. Hardware seems ok. And on a completely different note, I am inspired by your funny prop of the guy appearing to fall and hand from the roof. I've always liked it, but didn't want to steal your idea 😁
  10. Another good thought dibblejr. Sorry I didn't mention this earlier, yet I performed that experiment although I agree with you that I didn't think it would make any difference as the CCRs were all similar. So the result is the same. If I swap a good color string from another controller, I still get colors out of order on the same controller that has colors out of order. And just for giggles, when I move the CCR from the controller where colors are out of order to a controller where colors are in correct order, then the other controller still shows proper order. Thus, concluding the issue is in the configuration of the hardware.
  11. Hmmm, interesting thought. I will check that out when I get home tonight. thanks for the idea.
  12. First of all, apologies if this information is in another thread. I didn't find it if there is. Rarely do I run into something I can't solve on my on . This is probably the 2nd time in 10 years, but I'm stumped. When doing my test setup this year, I noticed 2 of my Pixie 2D boxes show different color patterns than the other 5 boxes. I see from running the hardware utility that it has to do with the order of the colors sent to the controllers. All of my other 5 boxes show a color order of BRG. However the 2 boxes showing wrong colors on my CCR strip have a setting of RGB. Ok, simple to change, right? I change the order in the Cosmic ColorPixie config dialog and even try changing the number of pixels per port, yet the controller is not saving the values in eprom although the hardware utility replies that the values were accepted. I refresh and see the old values are still there as shown in my photo. Baffling. In the hardware utility, I set a test color to one color, but the color on the CCRs is a different primary color (as expected because it is wrong). I see in the manual something about a jumper on J5 in the box needs to be removed so the values can be accepted by the hardware utility (if I understand that correctly). There is no jumper on J5. I try resetting the controller during power up and it seems to reset according to the LED, yet still same results. I thought maybe I could cheat the process by changing the "channel order" in my prop definition, yet that seems to have no effect either. And yes, I'm using the correct speeds and high speed communicator. All communications work fine. Just that these 2 controllers are not holding their values. Suggestions are appreciate. I am out of ideas.
  13. Actually there already is a method to delete all of the archived channels at once. It sounds like you haven't looked closely at the menus. Look under the SEQUENCE menu to "MANAGE ARCHIVED PROPS".
  14. Well it is hard to think to mention every specific item 😉
  15. Some time ago, I learned there was a trick to bypass that problem. If the music starts almost immediately in the video, it is more likely to be banned. I haven't posted any videos to FB any more, yet noticed that if the music was delayed about 10 seconds into the video, then it was ok. Maybe that still works, maybe not.
  16. That's a great video, but I noted the use of pliers to close the top. I had an issue with that in the past. When some connections didn't work, it was because as the top cover was being slid over the housing by use of pliers, it caused the wire to slide with it and bend the metal teeth to the point of not connecting well. Thus, I think it is best to press the wire down as much as possible on the teeth before sliding on the top. Now, I don't need pliers any more and the connections are more reliable.
  17. Good info K6. Many years ago (before CCRs were popular), I did a really large display for a shopping center down in Texas. I used ELLs to transmit to distant locations. However, for my home I abandoned using ELLS as I was having too many problems with my mostly all CCR display. They couldn't handle the complex high speed patterns and would freeze the CCRs at point. Now I use only wired connections. I suppose that one of those other high speed alternatives is good for complex displays.
  18. In checking my old threads, I see that I forgot to come back here and give an update on what the problem was from the above post. It turns out to be the ELLS ! I took the ELLs out of the network and used cat 5. Everything worked fine after that without changing anything else.
  19. And do keep in mind for the future that the comm port numbers can change on you as depending on where you plug them into the computer, or something else using those ports that were not in use previously, or even more strange is that a a few occasions I was "testing" something with the HU software and it changed the device ID without telling me and I didn't ask it to do that.
  20. Great.... congrats, and thanks for the update. Yup, it is easy to forget little details from year to year such as what does the light mean. So as you realize now that it is either blinking (not communicating on the network) or solid red (controller is being recognized.)
  21. Amen on that reply. To me, it was really worth the time to get used to S5 and I would now never consider going back to S4. In fact, I wonder how I dealt with S4 for so long 😉
  22. No, it is only red color, never green. Makes sense that one or more controllers are going to be on one comm port and one or more on the other comm port depending on how you connected the controllers to the interface. Hopefully you have your prop definitions set to the proper comm port for each controller and you will be ok. Maybe you plugged the adapters into different USB ports on the computer this year than you did last year. Like they say with the stock market..... past performance is no guarantee of future performance. 😁
  23. If I am understanding correctly, you are referring to the led inside the controller. You want it to be solid which indicates it is communicating properly. Are you using more than one USB connection (multiple networks)?
  24. I also have used that transmitter for a few years and never a problem. Inexpensive and reliable. As for the hum or noise, often that is due to having transmitter too close to an RF source like the computer, or a poor quality audio cable, and sometimes even having the "wall wart" power supply too close to the transmitter. I think you would be ok with having this transmitter in the basement a long way from the street because it is almost too powerful to begin with.... even in the low power mode. Yet, to answer your question, I have a 25 ft audio cable on mine with absolutely no hum even when no songs are playing.
  25. I do a little bit as a hobby all year long so I am not so stressed when the season comes. I'll take an occasional Saturday at least once in each month of the year to work on a sequence. It also keeps the mind fresh on the use of the software.
×
×
  • Create New...