System Restorals(random resets)

Bubba579

Member
I have an ELK M1 60zones, Fire, Burg, Elk Wireless, 1output expander.

I have an access control system providing 2 relay output to trigger a relay and my garage door. The relay triggers a keyswitch zone to disarm the alarm upon activation.

Occasionally, the M1 will just reset, when it does I get about 10 of my 24 fire zones restored and if I open my garage door the alarm is triggered instead of disarmed.

The log only shows the system restore and power up.

Suggestions?
 
I think I have the same issue. I haven't checked my logs to confirm, but it seems like my wireless receiver resets sometimes and all of my wireless zones show as violated. Over time I think these zones "sync up" where they show as normal. However, if I need to arm the alarm and this just happened, I need to activate each wireless zone (open/close manually) so the systems "syncs up" to the correct status. I have the M1XRFEG (sp?) wireless receiver.
 
Have you verified you haven't passed the last FW that supports that unit? Bus issue?
homejones said:
I think I have the same issue. I haven't checked my logs to confirm, but it seems like my wireless receiver resets sometimes and all of my wireless zones show as violated. Over time I think these zones "sync up" where they show as normal. However, if I need to arm the alarm and this just happened, I need to activate each wireless zone (open/close manually) so the systems "syncs up" to the correct status. I have the M1XRFEG (sp?) wireless receiver.
 
I have M1G 50 zones - 30 outputs 
 
I too have daily system resets occurring - this was happening 3 times daily at differing times - no regular time. updated FW and the problem went away for a month or so . HOWEVER the problem has just started again - dang! 
 
have checked all connections. 
 
any thoughts appreciated
 
Greetings all,
 
I too have had random uninitiated resets. In fact, these have now occurred so often that my wife has suggested that I have the system inform me that it has reset and is no longer protecting us. Therefore, I programmed some rules to to call my cell phone. After a reset, the problem is that the system has to wait until all the wireless sensors (Honeywell) report in. Until then, I can't arm the system. I suppose I could make all the wireless sensors force armable and create a rule to re-arm. To the best of my limited knowledge, this still leaves me with half my building not covered by active sensors. I called my vendor and I called ELK and spoke to Amy. I was told that I have a bus short. Not that I'm infallible, but I've wired aircraft for a living and my alarm system has over 20 wired sensors, several bus devices, and you (ELK Products) mean to tell me that the only two wires to short in my whole system are the bus wiring?!!! Furthermore, why is it that a shorted bus, say for example, a smashed or tampered keypad, is able to reset my system?!!! I would very much like to be given a fix or workaround!!!
 
My hardware and firmware is as follows:
M1G          hardware ver. 0.13   boot ver. 3.3.6, firmware ver. 5.3.10
M1KPNAV  hardware ver. 4.0, boot ver. 1.0.2, firmware ver. 1.0.28,
M1XRFTW hardware ver. 6.4, boot ver. 1.0.6, firmware ver. 1.2.56
M1KRF2H  hardware ver. 4.1, boot ver. 1.0.0, firmware ver. 0.9.8
M1XIN        hardware ver. .05, boot ver. 3.0.5, firmware ver. 1.3.7
M1XEP      hardware ver. 1.0, boot ver. 2.0.4, firmware ver. 2.0.42
 
Feedback and/or solutions would greatly be appreciated. Thanks.
 
I'd go with Amy on this one. Brad too (if you ask him).
 
No workaround. Have you performed the requisite troubleshooting as directed by Elk, such as meter A to B and relational to power/negative and also check for ground faults? You haven't mentioned the troubleshooting steps that have been performed....Have they directed you to roll back or roll up any devices? Have you cut and reterminated the bus devices? Have you split your bus into 2 busses? How is the topology wired? How is the bus terminated? What sorts of errors does the bus report in diag? Have you removed devices (keypads) to see if the problem follows a device or cabling?
 
Wireless doesn't need to be tripped if the system restarts. That's only to get a valid status to report back as faulted or secured. If the system is armed and a RF device transmits a fault signal (IE: alarm) the system will respond accordingly, not require multiple trips before the system views it as an actual alarm. Your property is only unsecured for the immediate second the system reboots and subsequently stabilizes.
 
99% of the issues out there with any systems, including the most complex ones, is the installation media or terminations. I used to believe it was hardware or firmware hundreds of times....and rarely is that the case. I get that you may work with copper as your job, but all it takes is a single misplaced staple (via a T25) or a romex staple hit too tightly or cables burned when pulling them through framing.....So either you need to perform a little troubleshooting or drag out a TDR and start shooting the cables, not a fix or workaround. S\
 
DELInstallations, I thank you for your response. I haven't done any extensive troubleshooting. I had only measured the +VKP to Neg and received +13.84 volts.
 
Inspired by your list, I measured the following on the M1: Neg to Data B=1.43v to 1.75v, Neg to Data A= 1.29v to 1.41v, Data B to Data A= -.19v to .41v (all with a DVM).
 
M1 earth ground is NOT tied to the structured wiring box ground. Data bus NEG is NOT tied to the structured wiring box ground.
 
The system was on and running but not armed. I expected a wider swing between Data A and Data B, although only a difference of 200mv between the two is required to transmit a data bit. With only a DVM, I do not know if voltages between the Data bus terminals are typical voltages for a running RS-485 bus as measured above. I have a keypad and an expansion board daisy-chained on one data bus run and the ELK two way and a Honeywell receiver daisy-chained on the other. I'm assuming that I terminated each end unit for each run...
 
If the above voltages are typical, then I'm stumped. If they are not (DATA A to DATA B should be higher or Data A to NEG should be higher), then I need to do my homework. Thanks for the support!
 
You didn't mention how the cabling and bus is connected, such as through physical connections/conductors or category cable. Part of the largest issue out there is RJ45's and improper crimping. Second to that is cable that is secured too tightly and cold flow of conductors.
 
Too tired to drag out the bus voltage specs, but Elk can provide the troubleshooting steps and what is within their spec. Ground faults are not dependent on the system being connected to earth ground.
 
You're going to need to split the bus/devices and meter or let the system run to see when it behaves and when there's issues.
 
DELInstallations said:
Have you verified you haven't passed the last FW that supports that unit? Bus issue?
I think I have the same issue. I haven't checked my logs to confirm, but it seems like my wireless receiver resets sometimes and all of my wireless zones show as violated. Over time I think these zones "sync up" where they show as normal. However, if I need to arm the alarm and this just happened, I need to activate each wireless zone (open/close manually) so the systems "syncs up" to the correct status. I have the M1XRFEG (sp?) wireless receiver.

Yes It's on a supported firmware, I could try to roll it back. Haven't yet.

I have checked bus, swapped the M1DBH out. Re worked and tested the RJ45 connectors. Checked bus voltage. Checked Power supply voltage, swapped power supply. Checked grounds. Replaced battery.
 
DELInstallations said:
You didn't mention how the cabling and bus is connected, such as through physical connections/conductors or category cable. Part of the largest issue out there is RJ45's and improper crimping. Second to that is cable that is secured too tightly and cold flow of conductors.
 
Too tired to drag out the bus voltage specs, but Elk can provide the troubleshooting steps and what is within their spec. Ground faults are not dependent on the system being connected to earth ground.
 
You're going to need to split the bus/devices and meter or let the system run to see when it behaves and when there's issues.
All the sensors are hardwired homeruns back to a single enclosure. Bus between inputs goes to a M1DBH via CAT5e.(I took it out and used terminal blocks issue is still present)

It's all over the place time wise, usually at night around 11-2 but sometimes during the day.

If it didn't ignore the rules, and beep incessantly at night a reset wouldn't be such a problem.

I walk tested it and everything checks out. I have one glass break sensor that has never worked(think the wire got damaged so it got disconnected from the system)

(Apologies, I understand how to multi-quote but it's not letting me)
 
Back
Top