Elk keypad failure

[jbauer]

Last night at about midnight my Elk M1 keypad started beeping at me, and the loudspeaker said something unintelligible about "keypad number 1 missing". I couldn't make the beeping stop until I turned the Elk off and back on again.

This was clearly frustrating, but my bigger concern is what about reliability? Do the keypads sometimes just stop responding and need a reboot? Has this ever happened to anyone else before?

The keypad has been 100% reliable for the first 2 weeks that we owned it, and it has been fine ever since the problem last night.

Any input is valued.

- jason

 

[rfdesq]

The only ELK keypad failure I had was caused by a lousy RJ45 connector install (done by me). It was flaky into the M1DBH. I rebutted the cable and it has been solid since.

 

[jbauer]

No RJ45's here, just a straight run of CAT5e from the green phoenix connector in the Elk to the grease filled splices at the keypad.

- jason

 

[Digger]

When the keypad beeps does it say "Lost Comm" etc. If so it looks like the keypad is losing communication with the panel. I would check the connections of the white and green wires to that keypad.

 

[jbauer]

Yes, it says "Lost Comm". I will recheck all connections. Is this something that simply doesn't happen unless there is a wiring problem?

- jason

 

[rfdesq]

The only time I have lost communication is during a firmware upgrade or a bad connection.

 

[Digger]

Yes, it says "Lost Comm". I will recheck all connections. Is this something that simply doesn't happen unless there is a wiring problem?

Other than updating firmware I have never seen a keypad lose communications unless there was a wiring problem. It happens to the best installers occasionally so dont feel bad if you have one bad connection in your whole system. It happens!

I would redo all of the connections for the white and green wires for that keypad. most likely it will solve the problem. Rarely do you see a hardware problem cause this but I guess its not impossible.

 

[Spanky]

The other thing is proper wire runs, everything in a series bus, and termination jumpers in place at each end of the series bus. With power off, data A and data B should read about 65 ohms +/- 10 ohms.

Try re enrollment of all bus devices using ELKRP or a working keypad.

Move the keypad that failed to the M1 and connect dirctly to the control and check operation.

 

[BraveSirRobbin]

I also am suspecting cabling problems.

No RJ45's here, just a straight run of CAT5e from the green phoenix connector in the Elk to the grease filled splices at the keypad.

Do a continuity and leakage check of these cables with an ohmeter. The "How to Install A Security System" describes this procedure if you need it.

 

[jbauer]

Just idle curiosity here... shouldn't the keypad "auto-recover" when a communication packet is dropped? So lets say there is a temporary open in the RS-485 network and some packet that keypad was waiting for didn't get ACK'ed. So the keypad starts beeping, but tries to recover at the same time. At least, that is what I would expect.

If that is true, then why did I have to power the whole system down in order to re-establish comms?

It seems to me that if it was a cabling issue then rebooting the Elk would not fix it if the open was still there. And if the open was NOT still there, then the keypad should have stopped beeping. What are the odds of me rebooting the Elk at the exact same moment the open in the cabling disappeared?

Perhaps I'm wrong here, does the keypad NOT auto-recover from lost comms?

- jason

 

[rocco]

I don't have my Elk yet, so I am speaking from my experience with other alarm systems.

The communications may have recovered, and may have even been fine when it alerted you, but I believe a security system needs to draw a distinction between the communications now working, and alerting you to the fact that it had failed.

Since this is a "Security" system, and the communications failure, no matter how brief, may have been due to a security breach, I wouldn't expect it to stop beeping until it made you aware of the problem.

Granted, requiring a reboot would be a pretty heavy-handed way of acknowledging the problem, but I'm not sure there might not have been another, though less obvious, way to shut the thing up.

 

[Spanky]

The M1 System's data bus does autorecover from packet loses or connection opens. If the data bus does recover, some piece of silicon on an IC could have latched up that was not feeding the automatic watchdog power down system.

The watchdog system monitors most of the IC's.

 

[jbauer]

Thanks for the info spanky. Does this mean that if I had left it alone it would have stopped beeping at some point in time?

If not, how do I get it to shut up without rebooting the system?

- jason

 

[electron]

I believe pushing the * key will silence the beeping.