Random Channels Are Staying On

[toddm1919]

Watched one of my shows last night and noticed something strange. Tried to post this last night but the forum went down..so sorry for the multiple posts. Random channels would remain on during a sequence. Once the channel would be programmed to turned on again in the sequence, it would then go out. They are attached to different boxes,some are CMB24s some are LOR1602s. I have my setup split into two networks both running at 115.4k (Some of the 1602 are older so I don't think they can handle 500k.). From what I noticed it looked like it was only on my one (reg) network. Any ideas? How many channels can a network handle at that speed? Could this problem be caused by overloading the network?

I ran the hardware utility and the reg network is showing a total of 34 units on the network when it should only be 15. I have never had an issue like this before. Could it be a bad cat5 cable?

Any help would be greatly appreciated. Thanks.

Edited November 28, 2015 by toddm1919

[toddm1919]

Now I am getting a "Serial Event Error" when I start the Hardware utility. It says

Serial Event Error (Poll Type 49)

Subscript out of range

[dgrant]

The older units will not run at 500K. Slow down that comm buss to the normal 56k and it should reappear. 

[toddm1919]

Thanks dgrant. I had to go through my network controller by controller and found that one of my pixel controllers was causing the issue. Once I replaced that, everything when back to normal.

BTW, I know that the older controller can't handle the 500K, but they can handle 115.4K, right?

[wmilkie]

5 of my older controllers are at 115k, they work fine

[dgrant]

I only have two older ones and I've not changed the default setting on speed for my buss. Things work just fine but I'm sure I'm at the limit of how much it can handle with 14 controllers on the one buss. Now as for a pixel controller, unless you've tied it into the LOR RS485 buss and it actually has that capability such as the Pixcon16, it shouldn't have anything to do with the LOR RS485 Buss.

[rhino]

I'm having the same issue, and very similar to yours, except I don't have the pixels.

 

• 2 LOR networks
• Regular network = 19 controllers (most are G3, 1 G2)  (ELL frequency = 21)
• AUXA network = 20 controllers (most are G3, 2 G2s)  (ELL frequency = 31)
• Running from G3MP3 Showtime Director
• ELL's running at 115K

 

Issue is with AUXA network only.  Random channels will remain on until the next "on" command will come along and turn it off.  (Always hope that an "on" command comes along quickly when this issue arises.)  And boy, does this mess up chases!

 

This AUXA network now looks like this, as I try something every morning and hope it's fixed by the nightly show:

 

G3-MP3 --> Controller Cluster 1 (5 controllers daisy-chained) -->  ELL f31 --> ELL f31 --> Controller Cluster 2 (13 controllers daisy-chained) --> end

 

... then ...

 

another ELL f31 --> Controller Cluster 3 (2 controllers daisy-chained) --> end.

 

I just loaded the latest firmware to all ELLs on this network (frequency 31) this morning.  This evening?  No help.  Still have some channels that "stick", randomly.

 

How does one trouble-shoot this?  I'm expecting ELL issues, but not confident at this point in time.

 

IDEAS?  Please help?

 

This is the difference between "flashing lights" and a "professionally-synchronized display".

 

THANK IN ADVANCE!,

-- rhino

 

 

[dgrant]

I may have resolved my ELL issues just today. I was having weird intermittent problems with my single CCR on its own ELL and from time to time, one of my megatrees which has its own ELL. Kept troubleshooting and getting no where but read the ELL manual again today....carefully this time. It says that if we are using both V4's and V5's, then the V5 needs to be the main transmitter for the others. I was using a V4, communicating to a V4's and V5's. I swapped out and now have a V5 in command and its working perfectly.

[rhino]

I may have resolved my ELL issues just today. I was having weird intermittent problems with my single CCR on its own ELL and from time to time, one of my megatrees which has its own ELL. Kept troubleshooting and getting no where but read the ELL manual again today....carefully this time. It says that if we are using both V4's and V5's, then the V5 needs to be the main transmitter for the others. I was using a V4, communicating to a V4's and V5's. I swapped out and now have a V5 in command and its working perfectly.

dgrant,

 

Thank you, thank you, thank you.  I learned something.  There's a V4 and a V5 ELL.  Gotta' figure out what those are, and what I have.  I probably have a mixture as well.  How does one tell the difference between a V4 and V5 ELL?  Where is this ELL manual that you referred to?  Online?

 

||: THANK YOU! :||

[rhino]

dgrant,

 

Thank you, thank you, thank you.  I learned something.  There's a V4 and a V5 ELL.  Gotta' figure out what those are, and what I have.  I probably have a mixture as well.  How does one tell the difference between a V4 and V5 ELL?  Where is this ELL manual that you referred to?  Online?

 

||: THANK YOU! :||

 

Just found the ELL manual (http://www1.lightorama.com/PDF/RF-V4-V5_Man_Web.pdf), and found the V4 vs V5 section.  I'm reading up now.  No need to reply to this thread... yet.  ;-)

[rhino]

Is the only way to determine a V4 vs V5 ELL is by opening up the bottom and looking at the circuit board?

 

I'll do that if I have to, but we're currently sitting with 6" - 12" of snow/ice.  Propping up a ladder to access the ELLs is not really "desirable".

[dgrant]

If the labels are still on, look on the label. It'll say what kind it is.

[rhino]

If the labels are still on, look on the label. It'll say what kind it is.

Hehe.  After popping open 3 of my extra ones in "inventory", I discovered that little "label trick" around midnight last night.  <forehead palm> D'oh! </forehead palm>

 

Thanks!

 

I'm going out to the display this morning to put a V5 on the "lead" on that network, and see if that fixes it.  Will report back later tonight.

[wbaker4]

Something to try....

 

Use dimming to turn off your channels rather than a hard off.

 

I am using ELOR and have found some pixels randomly stay on if I just turn them off.  Dimming them to turn them off solves the problem.

 

You may not be using pixels, but perhaps the ELL has a similar issue.

 

 

Walt

[rhino]

Something to try....

 

Use dimming to turn off your channels rather than a hard off.

 

I am using ELOR and have found some pixels randomly stay on if I just turn them off.  Dimming them to turn them off solves the problem.

 

You may not be using pixels, but perhaps the ELL has a similar issue.

 

 

Walt

 

Walt,

 

Thanks for chiming in!  I need all the help I can get!  However, I use more fades than offs.  And this "anomaly" occurs randomly -- whether it's coming from a hard "off" or a fade (isn't there an "off" command the sequence sends after the fade hits 0%?).  Regardless, I notice this on some of my chases, which makes heavy uses of the fades.

 

Again, any and all tips/tricks are appreciated!

[rhino]

Hehe.  After popping open 3 of my extra ones in "inventory", I discovered that little "label trick" around midnight last night.  <forehead palm> D'oh! </forehead palm>

 

Thanks!

 

I'm going out to the display this morning to put a V5 on the "lead" on that network, and see if that fixes it.  Will report back later tonight.

 

This did not work.  

 

I replaced the V4 ELL transceiver at the head of this network (AUXA) with a V5 ELL.  Didn't change the results.  Still have (what I call) "hanging channels", where they do not turn off when they're supposed to.

 

What I don't get is that the same type of configuration (different freq) works fine on network 1 (Regular).

 

This is soooo frustrating.  Just ordered a boatload of 25', 50', and 100' cat5's to replace my ELLs.  Really don't know what else to do.

 

GRRRRRrrrrrr!

[dgrant]

Ok, next thing is to look at the sequence where the channel hangs on. Make sure the very last cell(s) are turned off. Back to the ELL's, they need to be away from interference items of course and similar. Something to test, while the lights are stuck on, disconnect the remote ELL that was connected to that controller. If the lights suddenly go off, then you know the ELL is sending the commands. 

[rhino]

Ok, next thing is to look at the sequence where the channel hangs on. Make sure the very last cell(s) are turned off. Back to the ELL's, they need to be away from interference items of course and similar. Something to test, while the lights are stuck on, disconnect the remote ELL that was connected to that controller. If the lights suddenly go off, then you know the ELL is sending the commands. 

 

dgrant,

 

Thanks for hanging in there with me.  However, I'm not sure I follow what you're saying.  I'm repeating here to help me decipher...

 

1.  Look at the sequence where the channel hangs.

 

I'll do this, but since its random channels that are hanging at random times during the song(s), I'm not sure this is the issue.  Yet, I'll give this a "go".

 

2.  ELL's need to be away from interference items and similar.

 

Not sure if I know how to detect interference items.  But, the only things in this "yard" are trees, pinecones, and lots of snow.  It's surrounded by pavement (road, parking lot, and driveways).  There is one utility pole coming into the yard that drops the power on the side of this "yard".  Perhaps I should try a different frequency other than 31 for this AUXA network?  Network 1 is on frequency 21 and it doesn't seem to be having any issues.

 

"Similar" -- I'm assuming you're meaning similar frequencies, similar speeds, etc?  Yes.  The ELLs on this network are all on freq=31, speed=115K.  If these were different, then there would be nothing coming on.  My lights are coming on... just not always going off when they should.

 

3.  While the lights are stuck on, disconnect the remote ELL that was connected to that controller.  If the lights suddenly go off, then you know the ELL is sending the commands.

 

I'm unclear here.  The lights aren't stuck on long enough to disconnect an ELL from the controller and see the results.  It's random, and they will turn off on the next "on/off" command that is sent (usually).  So, we're talking about 1-2 secs in most cases, which doesn't seem like a lot, but we're talking about chases, fades, and darkness being messed up by these random channels remaining on.  And we're talking about LOR stuff here -- hi-grade, professional equipment.  This is not some Walmart off-brand "show in a box" type of thing.  (Sorry, got on a rant.)  What the hell am I doing wrong?!  (Sorry, an outburst.)

[dgrant]

If there's any question about the ELL's, run a Cat5 cable from the computer out to the controller, then test again. You'll be able to verify if its a ELL problem or something else.

[rhino]

Okay -- finally got to this issue on Saturday.  Replaced the ELLs on Network 2 with 100' CAT5 data cables, and the channels appear to be working just fine now.  What a difference this makes in the show, where the channels are working as programmed!  Woo-hoo!

 

Now that the ELLs have been replaced with CAT5 cables, how does one determine if an ELL is working properly or faulty?

 

Again, on Network 2, the G3-MP3 Show director was cabled to a G2 controller, then 4 G3 controllers, then the first ELL (transceiver (RF-V5)).  Then, there were 2 receiver ELLs (RF-V4)s on the same frequency (31) which led to their "controller cluster".  One of the clusters had 10 on it.  The other cluster had 2 on it.

 

Now, there are 20 controllers daisy-chained together on this network 2, and the results are better than with the ELLs.

 

(All controllers are of the Pro Series.)

Edited December 7, 2015 by rhino