Burnt M1XOVR expander board

[paw500]

I came home from work today and noticed an "output expander lost comm" message displaying on my keypad. At first I thought it was a momentary hiccup in the databus, and so I ignored the message. However, when I checked a little later in the evening, the message remained. So I went and did some more investigating. I checked the log file and indeed there was an event that registered: Expansion Module Trouble, Output Exp. 3. I opened up the can that held this board and the board looked dead - no blinking light. Unfortunately, this was an important output board as it controlled the relay that activates the synchronized sounding (RRS-MOD) for my smoke alarms. Fortunately, I had an extra M1XOVR board on hand, so I popped the dead one out (the removable terminal blocks made that easy!) and inserted the new one in, making sure my termination jumper and address dip switch settings were the same. Then I re-enrolled everything, but the board registered only after several attempts at the process (the system didn't recognize the board until I finally removed and reinserted the databus wiring...). Now everything seems back to normal.

Upon closer inspection of the dead board, I found a burnt integrated circuit chip labeled "U5" on the back side towards the upper left of the board, and directly on the flip side of what looks like two resisters labeled "D24" and "D23". The board is mounted on those plastic pushpins, so it is isolated from the can enclosure- ruling out shorting to the enclosure.

Here's a photo:

Now, does anyone know why something like this happened??

 

[gatchel]

Anything is possible. Any storms in your area recently? D24 and D23 are most likely diodes. I would think something power related would have caused it but once again this is just speculation. Do you happen to know the U5 markings on the chip on the new board? If the solder pads on the board aren't damaged it might be repairable. I don't know how much I would trust it though.

 

[Del91574]

Any of the voltage outputs being used to trigger automation events or similar? What's being controlled by the board?

 

[BraveSirRobbin]

This statement has me concerned:

Then I re-enrolled everything, but the board registered only after several attempts at the process (the system didn't recognize the board until I finally removed and reinserted the databus wiring...).

I'm wondering if something is wrong with your connections or wiring. Did you try this re-enroll process before or after connecting any of the outputs? How is this coming off the main panel (data base hub, etc...)? Might want to check your wiring and even the cable itself for shorts.

 

[JonW]

Like gatchel asked, what are the markings of the U5 chip (from the good board)? Knowing this, we could likely figure out the function of the chip, which in turn, may point you into the source of the problem. e.g. data bus, relay driver, etc.

 

[gatchel]

This statement has me concerned:



I'm wondering if something is wrong with your connections or wiring. Did you try this re-enroll process before or after connecting any of the outputs? How is this coming off the main panel (data base hub, etc...)? Might want to check your wiring and even the cable itself for shorts.

I have had fresh new components (Specifically OVR's) not enroll the first time with perfect wiring and termination. This might be an elk issue...might...

 

[gatchel]

LM393 Voltage Comparator

 

[paw500]

Anything is possible. Any storms in your area recently? D24 and D23 are most likely diodes. I would think something power related would have caused it but once again this is just speculation. Do you happen to know the U5 markings on the chip on the new board? If the solder pads on the board aren't damaged it might be repairable. I don't know how much I would trust it though.

I looked back at historical weather data on weatherspark.com and apparently right about when the log registered the board failure, there was a thunderstorm that hit the area. By the time I got home, other than the wet grounds, you wouldn't even have known a storm of such severity came by. :wacko:

I pulled the new board out again to look for the marking on that chip: LM393 PFRF

 

[paw500]

Any of the voltage outputs being used to trigger automation events or similar? What's being controlled by the board?

I have an output from the ribbon whip from that board that drives a System Sensor RRS-MOD polarity reversal module that synchronizes the sounders of the smoke detectors. I didn't want to go without this life-safety component so I was a bit unnerved when I found the board was fried. Fortunately I had a spare one on hand to quickly do the swap.

One of the relay outputs is used to "reset" (i.e. momentarily cut power to) the smoke detectors.

 

[paw500]

This statement has me concerned:



I'm wondering if something is wrong with your connections or wiring. Did you try this re-enroll process before or after connecting any of the outputs? How is this coming off the main panel (data base hub, etc...)? Might want to check your wiring and even the cable itself for shorts.

When I swapped the new board in, I obviously kept the same bus address and termination jumper setting as the old bad board, since I wasn't changing any rules nor wiring. All I did to do the swap was to remove the terminal blocks, so all my wire terminations stayed the same. I thought that was all I had to do to get it back online. However I had the 5-fast blink pattern on the new board - there is power at the board. But the keypad still reported missing output expander. Also the rules that control the relays on the board (such as to reset the smoke detectors) was not doing anything.

So I figured I'd do the re-enrollment. The first attempt actually REMOVED the output expander from the system. So I did another enrollment. Attempted from within the ElkRP2 software as well as at the keypad, the new board never seemed to register - kept doing the 5-fast blink pattern. So I figured maybe it's a bad databus wiring connection. I loosened, pulled out, re-inserted and tightened the four wires at the databus terminal block on the board. The next enrollment attempt finally worked and the new board got registered into the system; confirmed the rules and relays all work.

 

[paw500]

Like gatchel asked, what are the markings of the U5 chip (from the good board)? Knowing this, we could likely figure out the function of the chip, which in turn, may point you into the source of the problem. e.g. data bus, relay driver, etc.

I pulled the new board out again to look for the marking on that chip: LM393 PFRF

 

[paw500]

LM393 Voltage Comparator

So do we have a more descriptive understanding of what this chip does?

Furthermore, how do we "protect" these boards and other components in our systems?

 

[paw500]

By the way the stamped number on the back side next to the label, which I guess is the board's serial number, of the fried board is 110301 (or it could be 110307 - it's a bit smeared)

 

[gatchel]

Trying to prevent this sort of thing takes a layered approach. If all of the components are in the same building or same can then surge suppression on the power source is a good start. A whole house suppressor and also one at the panel outlet wouldn't hurt.

Nothing can stop lightening. If the conditions are right your out of luck.

If you really want layered protection also add a surge device to the data bus and the 12vdc power line. Don't forget about the phone line. Most would agree that the 12vdc device would be overkill in a typical residential environment where all devices are in the same house or can.

Does the data bus leave the house for any external buildings, garage, etc?

How is your earth ground? How many ground rods do you have or do you have a UFER ground?

There might be ways to strengthen your resistance to such a thing. All of the surge suppressors you can throw at the system won't do much if the ground is horrible...

 

[Del91574]

Not saying there couldn't be a bug in Elk's software/firmware or hardware blowing up but...
the fact that you were unable to enroll starts making me wonder about the bus wiring integrity...such as does this unit connect directly to the bus, hardwired and spliced through or via RJ45's and a hub? Do you have additional power supplies involved?

For giggles, have you tried laying in a bootstrap program in the M1, then trying enrolling or watching what the bus does?

I agree with Gatchel with his post. A surge means nothing if the ground stinks or dissimilar grounds exist. If the system is integral to itself and doesn't leave the building, then supressing the DB isn't really going to benefit you compared to putting a supressor on the AC and telco connections to the panel. Surging the 12V system as it connects to the panel isn't really going to be practical and honestly, it doesn't gain you much, since the host components would most likely blow up before they output a surge that would damage the equipment downstream.