Jump to content
Light-O-Rama Forums

Richard Hamilton

Members
  • Content Count

    1,249
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Richard Hamilton


  1. It's a good thing.

    I'm pretty sure I'm not telling existing customers anything they don't already know, but for the newbies considering buying LOR....
    I'll sum it up first to say that practically every other company could learn a lot by how LOR treats customers !!!

    Fortunately for almost 15 years, I have NEVER needed customer service.  That says a lot about the reliability of products I've bought over many years.  Over $20,000 combination for my own displays and a couple commercial displays for people.
    Ok, sometimes, something doesn't work.   One of the CCRs I got in a summer sale kit has a flaky connection the connector where sometimes it doesn't work, but I wiggle it and it works.  Thus, I sent an email to support.  I get an answer the next day, they will replace it.  I realize this is a terrible time of the year for tech support, so I try to cut them some slack and tell them to wait until January because right now it is working and if it stops, I figured out a position to slightly bend it so it will work.   Being it is inside an arch (protected), I don't want to replace it now unless it fails completely.  Surprise, LOR doesn't wait.  They take care of the problem immediately by sending out a replacement and of course get the flaky one back.

    So, I don't know who is running that department, or who makes the decisions, but in my one man opinion, they do an incredible job of trying to keep customers happy and products working.

    What the hell happened to support at other companies in America?  Actually, I don't need an answer to that.   I know the answer.  Executives farm out support to places around the world that you can't even understand them on the phone, much less get them to do anything.  I got a better idea.  Outsource the executive jobs to India or China.  Companies will save more money that way and no one will miss the execs anyway  😎

    LOR support.  You are our hero!

     

    Later edit.... oh and how could I forget the incredible support by customers whom spend their time helping others with really great advice and help?  Kudos to all.

    • Like 1

  2. 2 hours ago, MattBrown said:

    I can't imagine what would cause this beyond what has already been suggested. Currently, the S5 Show Player and the S4 Show Player are virtually identical.

    In my personal setup I have an audio amp with volume adjustment for yard speakers and my FM transmitter also has volume control. So the volume coming out of the computer is never any issue.

    Matt

    Yup, I also agree.  I can't imagine that the issue is S5 software.  I also have always corrected these audio imbalances with the mixer.  Also I do the same as K6CC with Zara.


  3. Sounds like Ducks is more familiar with the controllers than I am, yet from an engineering perspective, most electronics can handle at least a 5% variation and some times more.  It doesn't have to be that precise.  You could probably go 12.25 to 12.5 easily.  And I hope you realize it is not the voltage that causes a fuse to blow.  It's the current draw.


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


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


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


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


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


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


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


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

     


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


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


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


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


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


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


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

×
×
  • Create New...