Jump to content
Light-O-Rama Forums

Smart RGB lights will not stop blinking while Idle, no shows playing


xmasjam

Recommended Posts

OK, the original poster sent me two Wireshark capture files.  One had the LOR Comm Listener running and he had blinky lights, and the second file had the LOR Comm Listener shut off and he had no blinky lights.  The second file had no E1.31 packets.  The first file had about 8,500 packets including universes 1 - 6.  All of the packets had a listed source of the Light-O-Rama Comm Listener.  None of those 8K+ packets had any data bytes that were commanding any channel in universes 1 - 6 to anything except 00 (or off).  In other words, the computer was NOT telling the AlphaPix to turn on any channels.

 

I will admit that it was a fast look (I really want to get to bed), but I'll set up a filter to do a detailed search when I'm awake enough to do so.

Link to comment
Share on other sites

I have an Alphapix16 controller here. I'll set up a test for it, but its not even connected to anything ... power supply or nothing at this time. Will try to do that later today and see if I can catch it messing up. My first tests with it, a couple of months ago, I saw nothing out of the normal going on with it. For the moment, its a backup controller only and was contemplating using it as a replacement for the P12S but found that it can't do something the P12S can. Same for the E682, it can't do this one function either...reversing string command, mid-universe.

Link to comment
Share on other sites

Thanks Jim for looking at my capture files and decoding them. I have opened another trouble ticket with Holiday Coro.

Link to comment
Share on other sites

Same type of issue with mine. Mine though is intermittent Switched power supplies thinking it was that but still had the same problem. So far, the past two months nothing has happened. So I am perplexed. I Had a few email exchanges with Holiday Coro but the issue stopped. I know that if x-lights and LOR are running at the same time there are issues. So I try to remember to shut down x-lights after testing. Could be electrical interference with something nearby too.

Link to comment
Share on other sites

OK, same issue here with my alphapix 16. If the LOR control panel is loaded with the listener running, I get the random blinking. As soon as I unload LOR, the blinking stops. I then loaded up xlights and saw no blinking after running some tests.

 

Honestly, It's not a huge deal while the show is running, but if it doesn't get fixed, I'll have to put my strips on a timer so hey don't blink all night. I suppose I could shut down my show computer, but I generally leave that running 24/7 during show season.

 

Mike

Link to comment
Share on other sites

Thanks Bob for looking in to this issue. When I notice the issue the first thing I did was contact Holiday Coro support and opened a ticket. Their tech's answer to fix the issue was use Xlights software. That is not going to happen. I have LOR equipment, this is the first 3rd party equipment that I have purchaed only because Holiday Coro states on their site that the Alphapix 16 controller works with LOR software. I do not have Xlight software so that is ruled out on causing my RGB lights to blink random but I will need to do so more trouble shooting and I hope I can get this issue resolved. I thought I have stumbled on the cause when I turned off the LOR control panel and all of the random blinking stopped. After seeing all of the posts of other people that is having the same issue with LOR & Holiday Coro Alphapix 16 controller having random blinking issues, I would say to those who are thinking of purchasing this controller to hold off on that purchase until the issue is figured out.

 

To clarify - our solution was not to use xLights to replace LOR S4 but to use it as an A/B test against LOR S4 so we can isolate the issue.  It would be more helpful to us and others if the information were reported to us - we have had only a single known issue of random blinking and it was resolved with replacement of output chips.  When this information is posted on a competitor forum for which we do not check that often, it makes it hard to know if an issue is occurring and how many people it might be affecting.  If there is a problem with the hardware, I can assure you that we wish to get to the bottom of the problem just as much as you do but to do this, we need to have good, valid information (versions, testing processes, sequences, etc).

Link to comment
Share on other sites

OK, the original poster sent me two Wireshark capture files.  One had the LOR Comm Listener running and he had blinky lights, and the second file had the LOR Comm Listener shut off and he had no blinky lights.  The second file had no E1.31 packets.  The first file had about 8,500 packets including universes 1 - 6.  All of the packets had a listed source of the Light-O-Rama Comm Listener.  None of those 8K+ packets had any data bytes that were commanding any channel in universes 1 - 6 to anything except 00 (or off).  In other words, the computer was NOT telling the AlphaPix to turn on any channels.

 

I will admit that it was a fast look (I really want to get to bed), but I'll set up a filter to do a detailed search when I'm awake enough to do so.

 

Just to be 100% clear:

This is exactly what the Comm Listener should be doing in this situation, and it should not cause lights to blink.

Link to comment
Share on other sites

It is in the interest of HolidayCoro and our customers to resolve this issue and to do so, we need good, reliable information.  The reality of E1.31 controllers are that they exist in a world surrounded by a huge number of other systems, software and customer skills sets and this can often make it hard to resolve problems.  So, by having more specific information about a given setup, we can better isolate the issue.  As this forum is that of our competitor and given that we can't determine and track customer issues in ticking system since there are only forum names, not real names and given that each issue could be unique, I'd ask that if you are a customer, please direct the following requested information to us at support@holidaycoro.com so we can properly track your case and get to a resolution.  

 

Since it appears that based on the troubleshooting listed above by several respondents, the problem does not happen in xLights, we will assume this issue to be specific to LOR and not a networking / firewall issue.  Please provide the following in your email to us:

 

* Description of the problem (eg lights continue to blink after end of show in LOR sequence editor)

* A screen shot showing the controller settings web page

* A copy of the sequence you are running

* The exact version of the LOR Sequencer you are running (this is listed in the title bar of the sequence editor - eg 3.11.2 Advanced)

* The steps to reproduce the problem

* Any additional information you might have about the issue

 

There is not a need to send wireshark captures as we need to first be able to reproduce the problem ourselves either using in-house hardware or customer hardware and we can capture that data if needed directly.

 

Thank you,

David

HolidayCoro.com

Link to comment
Share on other sites

Same type of issue with mine. Mine though is intermittent Switched power supplies thinking it was that but still had the same problem. So far, the past two months nothing has happened. So I am perplexed. I Had a few email exchanges with Holiday Coro but the issue stopped. I know that if x-lights and LOR are running at the same time there are issues. So I try to remember to shut down x-lights after testing. Could be electrical interference with something nearby too.

 

This is correct - if two applications such as xLights and LOR are running at the same time, you can get odd-issues also.

 

If I had to say the #1 cause we see of "odd behaviour" with E1.31 output is firewalls/anti-virus apps "inspecting" the data, then there a host of other ones:

 

* Virtualized environments (parrallels)

* Multiple network interfaces without proper routing

* Outputs shorted resulting in completely dead or partially dead outputs

* Wireless network issues

* Incorrectly configured sequences (output not working, shifted colors, only part of pixels working, etc)

Link to comment
Share on other sites

Is the power clean? I had all kinds of blinking when off that turned out to be a noisy supply. Just a thought.

Link to comment
Share on other sites

Is the power clean? I had all kinds of blinking when off that turned out to be a noisy supply. Just a thought.

 

The problem does not occur when the strips are powered on and LOR is unloaded, so dirty power is not the likely culprit in this case.

 

Mike

Link to comment
Share on other sites

Let me stick one very simple thought into the mix here, are we sure that the last cell in whatever sequence, was blank or at %0? If anything was still on even a little, that controller would probably be continuing to do what it was told too do! Try launching a sequence, stop it, touch the "lights off" button and see if there's anything still happening. 

Link to comment
Share on other sites

Let me stick one very simple thought into the mix here, are we sure that the last cell in whatever sequence, was blank or at %0? If anything was still on even a little, that controller would probably be continuing to do what it was told too do! Try launching a sequence, stop it, touch the "lights off" button and see if there's anything still happening. 

In my case it occurs even when the sequence editor is not loaded, but the comm listener is. That will pretty much eliminate a buggy sequence.

 

Mike

Link to comment
Share on other sites

Still, was the last command sent, all off? Even though the SE is turned off, the controller had still received a command. Someone who is connected to their controller, try a empty animation sequence for like 5 seconds. See if the blinking stops and stays off after unloading the listener too.

Link to comment
Share on other sites

From the point of view of the controller, the final command of the sequence is not the final command.  In fact, the controller doesn't even know there's such a thing as a "sequence" in the first place.  The Comm Listener will continue sending many commands to the controller after the sequence is over.  These commands should be (and, according to k6ccc's reading of the comm trace, are) telling the controller to turn off its lights.  Over and over, the Comm Listener is telling the controller "turn off your lights".

Link to comment
Share on other sites

Still, was the last command sent, all off? Even though the SE is turned off, the controller had still received a command. Someone who is connected to their controller, try a empty animation sequence for like 5 seconds. See if the blinking stops and stays off after unloading the listener too.

This is the way I tested it last night. I powered up the controller/strips, no blinking. Loaded up LOR but NOT the sequencer, random blinking. Ran a sequence, when it was done, random blinking. Unloaded LOR, blinking stopped. Loaded up xlights and ran some tests, no blinking. Shut down xlights and loaded LOR (no sequencer), random blinking. I'll try your suggestion with an empty animation tonight.

 

Mike

Link to comment
Share on other sites

OK, the original poster sent me two Wireshark capture files.  One had the LOR Comm Listener running and he had blinky lights, and the second file had the LOR Comm Listener shut off and he had no blinky lights.  The second file had no E1.31 packets.  The first file had about 8,500 packets including universes 1 - 6.  All of the packets had a listed source of the Light-O-Rama Comm Listener.  None of those 8K+ packets had any data bytes that were commanding any channel in universes 1 - 6 to anything except 00 (or off).  In other words, the computer was NOT telling the AlphaPix to turn on any channels.

 

I will admit that it was a fast look (I really want to get to bed), but I'll set up a filter to do a detailed search when I'm awake enough to do so.

 

I have now done a proper filter search on the Wireshark files that the original poster sent me of the E1.31 data stream wherein he was seeing blinking lights.  I have confirmed the unlike my quick manual search, I have now verified that of the 8500+ packets, there were ZERO packets that contained anything except 00 for all data bytes.

 

Remember that for DMX systems, the data originator (in this case the LOR Comm Listener) is sending the level for every channel many times per second (about every 22 milliSeconds).  DMX systems have no more intelligence than that.

Link to comment
Share on other sites

Thanks Jim for checking the capture files I had. I have just sent all of the information that Holiday Coro has requested along with the sequences so they can test it out in their lab. 

Link to comment
Share on other sites

This used to happen to me with a Pixlite4, but the flashes were not as quick. Then one day it just stopped.

Link to comment
Share on other sites

This used to happen to me with a Pixlite4, but the flashes were not as quick. Then one day it just stopped.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...