OP2 DCM sometimes sends wrong event code

[dan_n]

Summary: OP2 DCM sometimes sends "Fire Zone Bypass" during automatic test call.

My OmniPro II (chip firmware 3.0) has been mostly trouble-free since I installed it in 2005. When our local phone company discontinued landline support 2 years ago I installed a fixed wireless terminal (VoLTE) for the house phones. The first one lasted a year and then became unreliable. I replaced it and also had the OP2 do a weekly automatic test call to my alarm service so I'd know about a failure sooner. That worked fine for months, but now the OP2 sometimes sends the wrong event code (Fire Zone Bypass) instead of E602 Periodic Test Report. That always gets a callback from the alarm service and probably won't be tolerated much longer.

Obviously there isn't a real Fire Zone Bypass or the consoles would be beeping constantly and showing a trouble message. I'm worried about it sending the wrong code during a real emergency, or sending a duress code during a test call!

A cold reboot fixed it for a few weeks but it came back. I reset EEPROM and reloaded my setup but that only fixed it for 2 weeks. The only thing left I can think to try is upgrade the chip firmware to the latest (4.0?). Where can I get one?

Any other ideas to try?

 

[dwalt]

According to the Contact ID code list, Weekly Test is 602 and Fire Bypass is 571. I thought you might have a noisy connection to the monitoring service but 602 and 571 are quite different. You can try a newer version of software. I am skeptical as it seems to be an intermittent problem. If you can't find a 4.0 eprom, send me a pm.
dwalt

 

[ano]

I'm not sure I would trust Contact ID over anything except a landline phone line. If you don't have that, get an alarm communicator that connects to your panel with Contact ID and connects to their system with Internet or cellular. Ask your alarm company for a recommendation for an alarm communicator that they support and recommend. This will solve your problem. I use a Alula BAT-CONNECT to cellular, but there are many others as well.

 

[dan_n]

Thanks for the ideas.

The first time it happened I also thought it was an improbable perfectly corrupted communication that changed bits in both the event code and checksum that resulted in a valid message that the alarm co accepted. Since it's happened multiple times exactly the same way the most likely explanation is the OP2 itself is generating a valid message block using the wrong event code.

Something in the hardware is borderline failing. Could be a memory (at nearly 20 years old consider the retention age for EEPROM/EPROM), voltage out of spec, etc. That's one reason I want to try a new firmware chip, and the release notes mention some fixes for Contact ID issues. Is there a raw BIN file for OP2 4.0? I can UV erase/program or program a OTP.

I agree that DCM over VoLTE isn't as good as a landline but it works way better than VoIP. The only issue I ran into was one device I tried would not pass the 1400Hz kissoff tone from the alarm co even though everything else was perfect.

 

[dan_n]

One new data point: I disabled "Report Bypass/Restore" and it still reported a Fire Zone Bypass

I'll begin a thorough HW diagnosis, and I have a new EPROM freshly programmed with 4.0b that I'll try soon.

 

[dan_n]

So far I've removed every socketed chip, read out each one and saved a copy, and tested the SRAM chip. My programmer/tester (XGecu T48) said address pin A9 failed open-circuit test, but there's zero information on the SRAM test for these so I don't know what that really means and if it's a real problem.

I installed my new 4.0b EPROM and was a little worried since it took quite a while before the heartbeat blink started, but it came up okay and connected to PC Access over the network and looks like everything is there. It may have been writing to the EEPROM for the first startup.

Today's test call was received okay. I learned something very useful that if I put my account in test mode, the alarm co website will show the raw signal (CID) received for any call. Also I listened to the call and heard a clear undistorted 1400Hz kissoff tone from the alarm co, but the OP2 seemed to ingore it and resent the CID data several times and even did a second call out. I may have to scope the signals around the DSP input to see if the analog input waveform looks okay.

 

[dan_n]

To follow up, I'm still seeing this issue occasionally but have now 100% ruled out the panel as the cause of the wrong code. New data appears to show the alarm company ignoring the checksum and accepting a garbled message.

I had a digital recorder on my phone line and captured the communication when a wrong code was received. An audio waveform viewer shows my panel sending the correct 15 digits with correct timing (60mS DTMF tone + 60mS space), but the CS receiver sends the 1400Hz kissoff acknowledge 20mS before my panel sends the 16th digit (checksum). In theory that could be normal as they could still cut the acknowledge tone short, but they didn't so I think they just ignore the checksum.

As to how event 602 could become 571, it's seems more probable if you look at the DTMF frequency chart:



If the received frequencies are off a little (>5%) and everything moves over 1 column, 602 becomes 5B1 which should be rejected but eventually might decode as 571. But then why only the event code shifted? The 4-digit account number has to match exactly for acceptance.