Page 1 of 1

Weird Gold Elite issue

Posted: Tue Aug 31, 2004 2:36 pm
by wavetar
Have a customer with 4 Elite consoles. All 4 positions are intermittantly doing the same thing...while using the console, it'll suddenly become 'unresponsive'...won't let you choose a different resource, won't let you transmit on the selected resource...nothing. Within several seconds, the Centracom program will then show the little 'please wait...application is closing' window & shut itself down. You can then restart the Centracom program & it'll work fine...'til the next random time.

The consoles only seem to do this while being used...ie: if left alone, the program never seems to shut down. There is always at least 1 console not in use, so it's not uncommon for one to not be used for several days or even weeks...and it the program never goes down.

There's no error messages in the status line when this occurs, you don't see the 'Link down' window, nothing.

This isn't happening with any of the other 20 or so consoles on the system (various different customers, but all the same platform...NT4, Service Pack 6, same version of Centracom).

These units are all remote consoles, connected to the distant CEB via Newbridge T1 channel banks. Come to think of it, the main difference with this site compared to others is that it's about 40 miles from the CEB, while the others are within 5 miles or so.

The local FTR hasn't seen this before, nor has anyone he's asked within Motorola, apparently. I've gone so far as to verify program versions, running NT's 'checkdisk', and verifying all modem & LAN wiring. My next step is to try reloading either Centracom, SP6, or both.

Anyone have any ideas?

Todd

Re: Weird Gold Elite issue

Posted: Tue Aug 31, 2004 6:09 pm
by Jim202
[quote="wavetar"]Have a customer with 4 Elite consoles. All 4 positions are intermittantly doing the same thing...
Todd[/quote]

This probably doesn't mean much to you, but by any chance are the channel banks running in the free timing mode? It is important that channel banks being used over T1 circuits maintain sync with the source of the data. In this case the remote CEB. Shouldn't matter how long the circuit is. What normally is done is to use the received data to sync the transmit data going back to the source. In your case this would be the remote CEB.

Some techs that don't know much about T1 circuits and just let the channel banks float free as to the time sync of the data stream. In many cases this works most of the time. Its when there is a time slip in the T1 channel bank timing and you loose a burst of data. This can wreck havic to a system that needs to maintain a tight control over the data in both directions.

Jim

Posted: Tue Aug 31, 2004 9:08 pm
by Alan
I believe the system may be a SmartZone. In that case all T1's will time sync to the Embassy. The Embassy will have a GPS reference(generally).

Posted: Wed Sep 01, 2004 8:38 am
by wavetar
Thanks for the tip, Jim. The T1 side of things was set up by the local system provider, but I'm 99% sure the timing is sync'd with the Embassy, as Alan noted (it is SmartZone). I do however believe it has something to do with the link, as there's nothing unusual about the console installation, and is one of the few 'common' sources that would affect all consoles. The local telco is on strike here (going on 6 months)...good luck getting someone who knows what they're doing to look at their side of it!

Todd

Posted: Wed Sep 01, 2004 9:29 am
by Nand
9 Months of winter...6 months on strike…3 months of road work...Ah Canada.

Nand.

Posted: Tue Sep 13, 2005 2:31 pm
by wavetar
While looking for another Centracom topic, I came across this one & realized I hadn't updated it.

Long story short, Motorola sent me a special diagnostic program called "AppSite" to install on the affected OPs. It basically keeps track of everything that's going on in the computer, especially with the Centracom program. I recorded a few crashes with it & after Motorola analyzed the data, they were able to tell me exactly what the operators were doing to cause the crash. Let's see if I can remember the sequence...

An operator would open a resource icon (to adjust the volume, for instance)...Motorola calls this opening a "flap". With the flap still open, they would receive a call on a little used talkgroup which resided in another folder, so would go to the activity log to answer the call quicker, and open up the flap there as well, since it's volume was usually turned down. Then, they would leave that flap open and return to using the icons in the folder. This would cause the crash, everytime. Turns out, it was a "known" fault after all, which was fixed in later versions of Centracom.

That only took about 6 months for it to get "rediscovered" again. No wonder we don't tend to believe them when they say "I've never heard of that problem before".

Todd