Elk Wireless NX-454 false alarm

[MrSoul]

Hi everyone, my first post! you guys are great, and have helped me with my Elk-M1 install, which has been up and running for about a month.

My sensors are entirely GE wireless, with many NX-454 window sensors. A few days ago while in away mode, my cell rang with a burglar alert from the Elk. I rushed home to Outputs blaring, neighbors at the ready, police on their way, etc. Check on the process working correctly. Problem was, the violated zone was not violated in any way.

I've had no other issues. I now have this zone disabled b/c I am wary of a 3am false alarm giving me (and the neighborhood) a heart attack. I'm going to put in a different mode to see if it continues to trip.

IVB, I know you had some issues. Anyone else have input? can I expect more false alarms?

 

[IVB]

what wireless receiver do you have?

 

[Spanky]

Additional GE RF packet testing has been implemented into the next M1XRF software release due out the week of November 12th, 2007. This will require the upgrading of the M1XRF's application software and the M1 Control. The current RF decoder's bit error rejection is good, but the new decoder algorithm is extremely robust in the rejection of bit errors. Bit errors can be introduced into the data packet from RF noise, transmitter drift, and transmitted packet clash.

If you are using the GE RF receiver, the M1 responds to whatever the receiver decodes. In this case, all the error checking is within the GE RF receiver.

 

[MrSoul]

ELK-M1XRF2G.

Spanky, does this mean a bit error would trigger an alarm?

 

[Spanky]

Every hour a supervised transmitter sends a signal to the receiver. This supervisory packet provides the packet data information with a bit set telling the system that this transmission is a supervisory packet. The basic transmission protocol uses a very simple parity and checksum algorithm along with the ID code must be enrolled into the control. Normally it will take bit errors at exactly the right locations in the protcol to be decoded as an alarm packet instead of a supervisory packet. The odds are extremely small that this could ever happen. Remember it is possible to win the lottery although the odds are against you!

When the new application software is released next week, update your system which will enhance the decoding algorithm.

 

[MrSoul]

Thank Spanky, good info. most likely the false alarm wasn't due to the packet, but not sure what else could do it..... I'll look for the update next week.

 

[nilsp]

I have the same equipment and problem as listed on this thread. My family members have requested the alarm be disabled after multiple middle of the night false alarms.
I have upgraded the firmware as suggested. My question is how can I run the system for a month or so with no sound output, but good logging of when alarms are triggered? If I have no failures for a month, then I would feel comfortable re-enabling. I guess removing the sirens is easy, but not sure how to catch issues in the logs. Ideas?

 

[ddennerline]

[Oh. I did not see this was a 2007 thread, so I was in fact running late M1RF2G firmware. I guess there's still a error-bit decoding problem.]

I too have received one false alarm with one of my M1RF2G GE wireless sensors over the past year. To figure out what happened, you can inspect M1G's log file. Most likely you will see a violation and restoral with the matching timestamps.

In talking with Elk technical support, there wasn't much that could be done except replace the sensor. I changed the batteries in all my other sensors too. You can use ElkRP > Communicator > Zone RC and click the “Restoral CID†option. This way the alarm company will see that window was opened/closed in zero seconds. This seems to be a marker of a false positive, so a better decision can be made about police involvement.

I've had system installed for 18 months. I figured one heart attack a year wasn’t enough to rip the whole thing out and start digging into my walls.