Jump to content
Light-O-Rama Forums

Richard Hamilton

Members
  • Content Count

    1,244
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Richard Hamilton


  1. On 1/8/2018 at 2:02 PM, Ed K said:

     I can do some effects in SS that I cannot do in PE.  One example are spirals on my mini trees that begin at the bottom of a blank tree and move up (like I am uncovering the spirals while they turn). 

     

    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.


  2. 16 minutes ago, jfuller8400 said:

    Hi All,

    I've just released version 3.0 of my WeatherConditions console application for getting current weather data for use in other programs (such as Zara).  You can download it from here:

    Weather Conditions 3.0

    I updated some of the error handing to be more fault tolerant if the results from the api call don't contain all of the expected information.

    Please start using this version and let me know if you have any problems with it.

     

    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


  3. 17 hours ago, TheDucks said:

    That is not exactly correct. Because you are working at 12V (or 5V) the currents are much higher for a given wattage compared to 120VAC.

    A string of 50 12V bullets is 3A. 1000 bullets would be 30A.  Now that is a lot of LEDS and well past what you can reliably drive with the 8 ports on a CMB24 (the voltage drop on strings of 100 becomes pretty bad.. I guess that you could run 2 strings of 100 (200 nodes)  per port, but that would push the capacity HARD 2 * 6A * 4) 

    My 12V PSU can supply 33A. running it that hard for very long, is not advised (80% derate rule)

    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.


  4. 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.


  5. 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.


  6. 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.


  7. 27 minutes ago, TheDucks said:

    The moisture content of the Air changes how much signal is absorbed (reduces distance).

    The type of transmission antenna affects the 'pattern' of where the power goes. A simple dipole (rubber ducky) distributes all around.  on the other end: A Yaggi type pin points. the signal.  A typical 'City' VHF (Analog era TV with only a couple of elements) antenna, directs it forward

    Keep as few objects as possible between your target and the xmitter. High up tends to be better

    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.


  8. 1 hour ago, dibblejr said:

    I’d look at the LOR documentation and ensure all jumpers are correct.

    Or if it’s new submit a HD ticket and see if they wi replace it under warranty. May take a while though.

    JR

    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 😁

     


  9. 17 hours ago, dibblejr said:

    Try changing the strings to one of the good color order pixies and see what happens.

    If they are the same strings the results should be correct colors.

    I do not think the string itself can cause the color order to not change and save. In the hundreds I have assisted I have not ran into that. Along with my slew of pixies controllers.

    JR

    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.


  10. 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.

     

    2018-11-14_084735.jpg


  11. On 11/2/2018 at 10:33 AM, TBS99 said:

    Here is one good video:

     

    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.


  12. On 11/2/2018 at 1:23 PM, k6ccc said:

    A regular forum member here is debtoes who runs a several block neighborhood in Clovis, CA.  I have been to see that display and the behinds the scenes parts.  She is using ELLs as Mr. P mentioned for everything except her own house.  The larger you get, the more complicated that will get.  There are several alternatives as well.  For example, using WiFi or even point to point microwave or point to multi-point microwave.  Both of those require using E1.31 (AKA DMX over ethernet).  If it's all houses on one side of the street, it's not that hard to do it all or mostly via wired connections too.

    Very involved to do a large show like that.

     

    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.


  13. 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. 


  14. 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.


  15. 12 minutes ago, denamy1 said:

    Okay so it actually was the sequence I was playing. For the heck of it I tried another sequence and the CCR tree worked fine. WHEW.. I thought the red light meant trouble!

    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.)


  16. 11 minutes ago, default said:

    Is this something like you are talking about. Took me all of about 3 minutes to create scratch. Don't give up on S5. It can do what you want and more! Just takes a little time to learn and understand it. If you need help with how this is setup, let us know.

    Alan...

    sample%20strings.gif

    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  😉

     


  17. 29 minutes ago, denamy1 said:

    Yes the light is RED in the Pixie Controller unit controller. I thought it was supposed to be green? I am running the pixie controller and the regular LOR controllers on separate USB. The pixie controller is the red adapter. Like I said it was fine last season.

    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. 😁


  18. On 11/1/2018 at 3:51 PM, ~DOC~ said:

    I have looked at that one but there are many complaint for hum / Hiss noise. Did you experience this? This unit hooks to the PC with a 3.5 mm audio cable. How much of an extension can I install. My PC is in the basement and at the back. I would say that most will tell me I need to mount closer the road. 

    On 11/1/2018 at 2:48 PM, Mr. P said:

    I use a fm transmitter from my pc which transmits to a stereo receiver for my outdoor speakers and to car radio's. You don't need to go expensive as by law you are not suppose to transmit too far.

    here is one of my cheaper but very reliable transmitters:

    https://smile.amazon.com/gp/product/B00CM2VPMQ/ref=oh_aui_search_detailpage?ie=UTF8&psc=1

     

    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.

     

    • Thanks 1

  19. 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...