Jump to content
Light-O-Rama Forums

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


xmasjam

Recommended Posts

I have not observed the blinking on either of my E6804 which are powered up 24x7x365 with the LOR control panel running all but a couple minutes per day when the PC reboots.

Link to comment
Share on other sites

We have narrowed the issue that causes the blinking lights to a change in the Source Name (BSR E1.31 - 201x revision 1.14, section6.4.2) in octet 44-107.  What happens is that the Source Name changes from "Light-O-Rama CommListener" to "Light-O-Rama CommListener 3BBA5777A4EF7F\DMX580".  We have no idea why the source ID in the LOR CommListener changes in what appears to be a random way but this, along with the Sync address seems to throw off the controller, possibly making it think that the packet is from another controller.  We are working with our firmware developer to figure out why this happens but we'd also like to understand from LOR why the packet randomly changes.

 

Here is a video that shows the issue:

 

https://youtu.be/xjGbIWl_UEs

 

Here is the packet that results in a random blink:

post-5613-0-43016800-1439693760_thumb.jp

 

Here is a "normal" packet:

post-5613-0-62446600-1439693763_thumb.jp

 

If anyone would like the Wireshark data capture so they can repo the issue, please let me know via PM.

 

Thank you,

David

HolidayCoro.com

 

Link to comment
Share on other sites

David,

I have the Wireshark capture from the original poster of this thread.  I will look at his data to confirm a reproduction of your observations.

Link to comment
Share on other sites

Of the 33 second capture from the original poster that had random blinking packets, I did not see the situation you described. 

 

Here is the WireShark filter I was using for a search. 

 

ip.dst == 192.168.1.50 and frame[110:18] != 65:72:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

 

For those that don't speak WireShark, let me explain a little what you are seeing.  There are two parts to the filter.  The first specifies that the destination IP address for the packet must equal 192.168.1.50 - the IP of the E1.31 card.  This filters out any unrelated packets.  The second part of the filter specifies that the 18 bytes starting with the 110th byte must not equal 65:72:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00.  The 65:72 is the last two characters of Listener and were originally the only part of the filter just to make sure I had the byte count right.  So the filter is looking for the 16 bytes following Listener to all be 00.  Anything else will be caught by the filter.

When I go to bed tonight I will start a capture of my E1.31 traffic.  The first part will contain my evening show with lights running.  The second part will be me overnihgt show, but all the E1.31 lights should be off, and the last part will be after the overnight show ends and no show is running.  I will take a look at the data, but it will likely not be until Monday morning.

Edited by k6ccc
Link to comment
Share on other sites

Here early this morning, I connected and turned on my last year's XP machine that I ran my show with. Son of a gun, its doing the same thing too. I did not update the sequences or change anything from last season's settings that worked. After some coffee, I'll swap out the power supply feeding the controller in case of any possible noise issues. FYI, the random blinking that I'm seeing is not brief intermittent ones across a strip as shown in the video above, but a whole lot of blinking all over any strips connected. I've not attempted to capture any data yet as I think there's something larger going on here or something with a greater impact. Strange in that any command going to the pixel nodes, works just fine. Its any nodes "not" receiving commands that are blinking or twinkling for the lack of a better description. I'm also going to ohms check my 3-wire extension cables too just in case China didn't correctly connect them internally. Stranger things have happened. FYI, the test with the old computer was using LOR 3.12.0

Link to comment
Share on other sites

More, before changing out the PS, I got to wondering if the data refresh rate in the controller was somehow different now. It was set for 2000Kbps from last year. So I slowed it down to 500k and now it wouldn't command at all. Went back to 2000k, lots of twinkling all over. Set it for 3200k and all the issues stopped totally! Now I remember having to slow it down last year to make this work. There now is the possibility that this number might have to be altered based upon what's actually connected for things ( as in the total number of pixels being commanded AND CONNECTED) to work properly. I'll go back to the new computer, new setup, try all of this again and update here.

Link to comment
Share on other sites

this is what I was trying to ask in my first post  changing speed of the Network!!!!! but was shot down ...

Link to comment
Share on other sites

To dgrant...don't waste your time with the power supply. I changed mine out TWICE to see if that was the problem. Didn't help. ..same issue. I noticed that with my tree (16 dtrip) the random blinking with a single pixel (3 led section) happens across at the same row / level across ALL strips at the same time...NOT randomly (twinkling) up or down each strip separately

Edited by BMurray
Link to comment
Share on other sites

More, before changing out the PS, I got to wondering if the data refresh rate in the controller was somehow different now. It was set for 2000Kbps from last year. So I slowed it down to 500k and now it wouldn't command at all. Went back to 2000k, lots of twinkling all over. Set it for 3200k and all the issues stopped totally! Now I remember having to slow it down last year to make this work. There now is the possibility that this number might have to be altered based upon what's actually connected for things ( as in the total number of pixels being commanded AND CONNECTED) to work properly. I'll go back to the new computer, new setup, try all of this again and update here.

 

The E1.31 protocol is in this format:

 

CAT5/CAT6 > Ethernet > TCP/IP > E1.31 (E1.17)

 

The "speed" part there comes in the Ethernet section of the protocol and is known by common amounts such as haf/full duplex over 10/100/1000 Mbps.

 

The LOR protocol (along with DMX 1.11) is in this format:

 

Telephone Wire-CAT2/CAT3 to CAT6 > RS-485 > LOR / DMX (E1.11) protocols

 

The speeds used on RS485 are based on network quality and other factors and while LOR's network (actually RS485) "speed" can be varied, DMX is set at 250 kbit/s or about .24 Mbps.  This explains why you can only shove so much data (such as in pixels) over a limited amount of bandwidth and at some point, you have to move to Ethernet as a transport - RS485, as great as it is, just can't cut it at higher rates.  

 

See http://www.holidaycoro.com/v/vspfiles/downloads/UnderstandingDMX.pdf and http://www.holidaycoro.com/v/vspfiles/downloads/DMXandLORProtocols.pdf

 

So the short of it - if changing the "speed" of the LOR network really does affect the output of E1.31 data, that would be a bug but I suspect that we'll find no connection between the two.

Link to comment
Share on other sites

To dgrant...don't waste your time with the power supply. I changed mine out TWICE to see if that was the problem. Didn't help. ..same issue. I noticed that with my tree (16 dtrip) the random blinking with a single pixel (3 led section) happens across at the same row / level across ALL strips at the same time...NOT randomly (twinkling) up or down each strip separately

 

The issue that was originally reported and that I've repo'ed is not consistent - it is random in nature.  Anything that is happening over the same pixel, over multiple outputs is likely a configuration issue, possibly with respect to RGB order.  

Link to comment
Share on other sites

It was a configuration issue for the controller itself. Its refresh update to the nodes, internal to the controller, not the speed of the LOR buss on the E1.31 network. When I boosted the speed, everything calmed down nicely. Too slow and it looked like a twinkle command across all node channels. Now this was all on the P12S controller this morning. I've still got to swap all the wiring and etc, back to the AlphaPix16 and do it all again. There's a reasonable possibility that we're discussing two different issues here that sound the same. I'm thinking it was my fault to bring up my issues, thinking the OP's issues were the same as it sounded the same. But dmoore has shown the data capture indicating a different issue than mine. So if I've messed everyone up, I do apologize. I will post again as to my findings with the alphapix16 as there may yet be an issue there but at this moment, I'm thinking it was two different things going on with my setup.

Link to comment
Share on other sites

I have not seen this flashing occur with Pixcon16s in E131 (Or eLOR mode, but that is something completely different).  I have had 3 of them and a 4th from another mfg for several months and have never experienced any flashing with things running at idle.  I will set up a 4 way test today and let it run overnight and wirecapture what is happening.

 

Please don't confuse Thruput (BPS) with wirespeed. Pixcon 16's along with our HS USB adapters can support 1000K wirespeeds on RS485 networks.  Along with running eLOR protocol, we can successfully control approx 1,000 pixels on a single RS485 network.

 

 

 

David (Coro David):  

 

When you catch those weird packets, are the 14 bytes before the \DMXxxx always the same?  

 

Ensure that the only thing running is the LOR Control Panel and the COMM Listener.  When you catch one of those weird packets, without running anything else LOR, run the Light-O-Rama Diagnostic.  Copy all the text, put it into a txt file, and then zip that text file.  Send it to me (mike at lightorama . com).  Once you have done that, If you are running S4 pro please start the LOR Network Configuration program, switch to 'Advanced' mode, and export your registry.  Zip that file and send it to me as well.  Be sure to do everything in order since starting the Net Cfg can change your stored configuration and I need it before the program has a chance to change it.  Please also include the exact version of S3/S4 you are using with you see those packets.   Once I have that, I will open a trouble ticket so we can continue to keep on top of the problem and keep everyone at LOR and you up to date. 

 

I am going to dig more into the E1.31 protocol.  As far as I can remember, changing the source ID should have nothing to do with lights turning on, since the data is still saying to turn those lights OFF.  Also, the other E1.31 guy (the expert expert) is back from vacation tomorrow and I'll have him in on this as well.  If this problem continues, we may need you to send us some sample boards and possibly some pixels so we can duplicate the issue.  

 

We'll continue to track this in the trouble ticket once created. 

Link to comment
Share on other sites

Ok, I am now capturing packets on 3 Pixcon 16s and a non LOR 16 port pixel controller with 64 universes defined (16 universes on each).  They are static IP at 192.168.249 ,.251,.252,.253.

 

I have wireshark running with the following capture filter:

(ip.dst == 192.168.1.249 and frame[110:18] != 65:72:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00) or (ip.dst == 192.168.1.251 and frame[110:18] != 65:72:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00) or (ip.dst == 192.168.1.252 and frame[110:18] != 65:72:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00) or (ip.dst == 192.168.1.253 and frame[110:18] != 65:72:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00)

I've gone through two million packets so far, and have 0 packets captured.  Like I said, I will let this run overnight to see if I can duplicate the problem.

Link to comment
Share on other sites

Ok, I am now capturing packets on 3 Pixcon 16s and a non LOR 16 port pixel controller with 64 universes defined (16 universes on each).  They are static IP at 192.168.249 ,.251,.252,.253.

 

I have wireshark running with the following capture filter:

(ip.dst == 192.168.1.249 and frame[110:18] != 65:72:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00) or (ip.dst == 192.168.1.251 and frame[110:18] != 65:72:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00) or (ip.dst == 192.168.1.252 and frame[110:18] != 65:72:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00) or (ip.dst == 192.168.1.253 and frame[110:18] != 65:72:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00)

I've gone through two million packets so far, and have 0 packets captured.  Like I said, I will let this run overnight to see if I can duplicate the problem.

 

Mike - 

 

Is this capture being run without the Sequence editor running but with the Comm Listener running?  It doesn't matter what hardware that is connected or even if any hardware is connected.  I'll work on getting the other data you requested and send it to you.

Link to comment
Share on other sites

I've run it multiple ways so far.  The listener is ALWAYS running in each of these circumstances (obviously)

 

Sequence Editor running:

  • but not running a sequence (6 million packets)
    • Then forcing a reload of the Listener by making a trivial network configuration change (a couple of million)
  • running a constant color change sequence on those universes (9 million packets)
    • Also then forcing a reload of the Listener by making a trivial network configuration change (a couple of million)

 

No sequence editor running at all (5 million packets)

and then forcing a reload of the Listener by making a trivial network configuration change (a couple of million)

 

 

Currently I am testing connecting and disconnecting to the listener with different programs in the suite to see if I can get it to dump a bad packet.  8.5 million so far.  

 

 

I have not captured any weird packet with any test.  

 

LOR 4.1.2.  The Network Config is Intel 82566DC-2 GB NIC -> D-Link 24 port unmanaged -> D-Link 8 port unmanged -> devices.  Wireshark running on the computer with the listener.

post-7637-0-44677100-1439754665_thumb.jp

Link to comment
Share on other sites

Received my Pixcon16 today. It'll have to wait to test it as I have to jump in the car and drive all the way to California due to a funeral. 

Link to comment
Share on other sites

As I said two nights ago, I started a Wireshark capture overnight for my live show.  Because of logistics, it did not happen until early Monday morning so therefore, it was about 4.5 hours of my overnight show (which does not have any of the E1.31 lights on), and 6 hours of no show running, but the comm listener running.  There were a little over 6 million packets and I just finished the search and there were no packets that had the extra characters David mentioned.

 

I did the search twice using the two filters below.  The only difference is the destination IP address since there were packets to two different SanDevices E6804 cards.

ip.dst == 192.168.131.98 and frame[110:18] != 65.72.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00

ip.dst == 192.168.131.99 and frame[110:18] != 65.72.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00

 

All was done in unicast and using LOR 4.1.2 on an WinXP based computer.

 

 

Link to comment
Share on other sites

  • 2 weeks later...

I was testing some strips last night for dead pixels, and I noticed something I hadn't before. The random blinking occurs even when a strip is active. Obviously it's hard to see during a sequence, but while I was testing I had them on solid colors. While on, you can still see that random quick blinking throughout the strip. It's much less noticeable while the strip is lit, but it's there just the same.

 

Mike

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