Premium members do not see any ads! Click here to learn more.

COBRA Cobra mods sleep issues 5.02/5.03

G

goneshootin

Well-known member
Joined
Jun 2019
Messages
97
Has anyone else had issues with a Cobra mods running 5.02/5.03 going to sleep after they are armed? After several years of no issues this is the second time in a month I have had a problem.

Last night I visually verified that all the mods woke up when I armed them before the show. The sponsor delayed the start by 10 minutes and in that time one of six mods went black and had to be restarted mid show. It's a hand fired show so I'm usually not more than 25' from the mod when firing.
 
First year using cobra so no I haven't but Scott sent out 2 emails with tips for the fourth and that was mentioned on it. He said the issue happened when using modules that are hardware "A" with software 5.02.

5.0.2 Issues with Hardware A 18M Modules
While we are aggressively working to finalize our 5.0 stable release candidate, 5.0.2 is still a BETA release and has some known issues with 18M Hardware A modules. These issues include a module not waking up from sleep mode, or not being recognized in the module arm count when arming the 18R or 18R2. In both cases, simply power the unit off and back on to resolve.


Might want to check with Scott for particulars.
 
If you still know which mod it was. You might make a note of it in case it's an issue with a specific module. The more info you can give Cobra about the setup (mod type, hardware versions and site specifics, etc) the better. Since you said "It's a hand fired show so I'm usually not more than 25' from the mod when firing." does that imply you're moving around a lot with the remote or is the remote stationary during the show?

You could also verify each module is getting a similar signal when tested individually at a given/specific/same distance/location (having just one module on at a time to take mesh out of the equation) to verify nothing weird is going on internally with an antenna connection or something.

Chris
 
Thanks Chris but I don't need to confer with Cobra about the failure. I've been using the system to fire cakes, the Finale and sometimes bigger shells for the last 6 years. Checking my notes this was the 47th time/show I've used the system in this same exact way. Moving around with the remote during the show when you never get more than 50' from a given mod should not present any issues with a mod going to sleep and not waking up.

As MB pointed out 5.02 is a beta version and mod sleep issues have already been noted.

I'll just go back to 3.03 until 5.02 is stable. The MESH capabilities of 5.0 is a feature I can live without. Any shows I do that are entirely E Fired are usually done with a Starfire or Fire One. Cobra Con show failures was a reminder that the firmware is still buggy.
 
goneshootin said:
Thanks Chris but I don't need to confer with Cobra about the failure. I've been using the system to fire cakes, the Finale and sometimes bigger shells for the last 6 years. Checking my notes this was the 47th time/show I've used the system in this same exact way. Moving around with the remote during the show when you never get more than 50' from a given mod should not present any issues with a mod going to sleep and not waking up.

As MB pointed out 5.02 is a beta version and mod sleep issues have already been noted.

I'll just go back to 3.03 until 5.02 is stable. The MESH capabilities of 5.0 is a feature I can live without. Any shows I do that are entirely E Fired are usually done with a Starfire or Fire One. Cobra Con show failures was a reminder that the firmware is still buggy.
Click to expand...
So what happened at Cobra Con?
 
Especially if it was a problem that I can do something about or need to be aware of, I'd also like to know. No need to embarrass someone if modules were just left in test mode or something similar, but it would be a shame if other people's displays had issues that they might have avoided if they'd known about.
 
I believe the known (documented) issue is with the specific hardware (18M hardware A) not waking from the sleep mode. I wasn't clear if this fit your description of the problem you had. Did it not wake from a sleeping (unarmed) state or are you saying it went to sleep from an armed state?

From what I remember reading about the Cobra Con issue, I thought there was an issue with the SMPTE timecode connection. (I read that as a physical connection issue, but I could be wrong.)

Chris
 
It went to sleep in the arm mode. Scheduled show time start was 9:00. At 8:50 I armed the 6 mods I had in the field, at 8:55 I double checked all mods were armed. At 8:58 I was informed by the AHJ that there was a lost child in the audience and the police were requesting we hold off until the child was found. I took the opportunity to ensure all mods were on and armed for a 3rd time. At 9:10 we started the show.

Approx. 9:15 I realized mod 2 was asleep. I turned it off and back on again and it came back online and I was able to fire.

I had Cobra replace my key switches a few years ago with a more robust slide switch. It took them awhile to find a well built switch that would hold up to weekly beach shows. Once the switches were installed on my mods I lost the test mode on my mods. So it's impossible for me to have one of my mods in test mode. They are either on and armed or off.

Donnie you can get a better explanation from coachtimmyj about the problems he had and I believe part of the greased lightning show did not fire.

I did a show a couple weeks ago with about 40 36m's with 32 cue pyromagic rails. One thing I noticed was some funky weird thing where we had to do math during the continuity check to figure out which shell or device was not showing continuity. Not sure if it has something to do with using a 32 cue rail on a 36m or something else. But basically we did not have cues 17 and 18 on bank 1. Bank 1 stopped at 16 so if cue 18 was not showing continuity on the control panel that translated to cue 2 bank 2 on the mod. Wonky and makes the continuity check take longer.

Second thing I noticed was the lead used 4 mods as nothing but repeaters and we were less than 200 feet from the closest wired up mod. Talk about not having confidence in your system. Why should you have to worry about signal strength when your farthest mod is about 350' away?

Despite the repeater mods we still had problems with the system. Not 100% sure what the problem was but the lead shut down and restarted the system a few times before the control panel showed all the mods. Also if I remember correctly the mods were running 5.09
 
Last edited:
So was mod 2 awake when you started the show? It gets a little confusing when there's an Armed mode on the mod and an Armed State on the remote. When the remote is off, mods will go to sleep in the modules Armed mode. Was it a problem of it waking up when the remote was turned on or did it fall asleep after it reported to be in the Armed State at the remote.

I can imagine using 32 cue slats with Cobra is confusing as it only sees banks of 18. I suppose they could give you some kind of additional renumbering on the Control panel in a future release. This is not a problem when using Cobra slats as they are in banks of 18.

Hopefully they'll find/correct any gremlins floating around in the newer 5.x versions. If you were indeed running 5.09 that's unreleased bleeding edge alpha/beta code.

Chris
 
Our 5.1 release will address a number of gremlins when arming and causing issues such as not waking up. We have thousands of hours into this as we'll be documenting the specific symptoms primarily related to hardware A 18Ms. It's been a huge all-hands effort with several thousands of hours put into this to ensure stability and backwards compatibility to A units. One major fix was the discovery that the hardware A did not have a checksum validation built in which is part of the hardware B OS. What this means is that hardware A could digest corrupt data which can cause undesired behaviour. We built out own checksum layer to fix this.

The issue at COBRA-CON where the modules took too long to stop firing after SMPTE was paused had to do with 5.0.9 specifically, our timecode2 variable, and a signal repeating issue combined. We have since fixed the repeating issue and a proper, and much more aggressive stopping system.

More to come, but wanted to provide an update as I stumbled upon this.

Scott
 
Back
Top