Is there something wrong with my M1?

I've had an M1G in my home for about 15 years now.  It's HW 0.13, Boot 3.3.6, FW 5.2.2
 
I have a 2 (maybe 3) wireless expanders with maybe 15 or 20 wireless contacts and lately I've been getting 'transmitter missing' and 'transmitter low battery' warnings.  I chalked it up to the cold and/or low batteries and have been replacing the batteries in my wireless devices trying to fix it.  For the most part it seemed to be going OK but yesterday it got really weird.
 
I got a transmitter low battery error in one of the zones.  I replaced the battery and rebooted the M1G but the low battery error persisted.   I pulled the whole contact out and checked the tamper switch and battery and it's all fine.  I rebooted again and the M1G reported it as 'Normal'.  The problem is that the M1G now ALWAYS reports it as normal - whether the magnet is near it or not and even, now, whether it has a battery in it or not.  For some reason the M1G is seeing this zone as Normal now even though it most certainly is not.
 
So... not knowing what to do next I tried to do a re-enrol/update of the devices.  I went to the menu page for re-enrol that but it told me an area was armed and that I had to disarm the area first.  I disarmed all the areas and went back but it still tells me that an area is armed.  I armed and disarmed all areas (from the status page) and tried again but it still tells me that one or more areas are armed.  I walked physically to each area to check and they are all disarmed but still I can't get past the 'one or more areas are armed' block.
 
I've power cycled it a few times to no avail.  
 
Any suggestions of what to do next would be much appreciated!
 
mark

Are the "transmitter missing" and "low battery" warnings limited to zones that are on just one wireless receiver, or are they spread across all of them?  If they are all getting these warnings, that would steer me to suspecting the M1 rather than the wireless receivers.  
 
The first thing I would do is check the data bus wiring between the M1 and all the devices that are connected to it (not just the receivers).   Remove the wires at each junction point, make sure everything is clean and re-insert them, making sure you have good, tight connections.
 
At 15 years old, it is certainly possible that the M1 has developed a problem.  Electronic components do age and become more likely to fail as they age.

M1 hasn't been out for 15 years! Was only released about 2005/06.
 
First, which RF receiver are you using? Assuming with the 5.X, you have the Elk GE unit... (released about 2-3 years after the original M1 GE release). So that should put you with an RF2G, no? Otherwise you would have had the GE/Caddx unit and a 4.X FW, unless you've replaced hardware 
 
So the items now to check would be the proper orientation of all 4 antennas (2 dipole and 2 ground plane). Next would be to perform a go/no go test from the M1. Obviously something has changed on the install, or something was installed marginally from the beginning.
 
You should have the RF receiver installed away from the M1G, at least 3-5' (from memory in the manual).
 
Next would be to perform a go/no-go test on a few devices.

Following that, I would remove the suspect transmitter from it's mounting location and try in closer proximity to the M1 and receiver. Install the battery and trip the tamper and note what the LED's on the receiver are doing. What you didn't specify is where the transmitter is installed and distance from the M1. That would be key information, especially if in a non-conditioned environment.
 
Most likely you have a bad transmitter. The system isn't going to be actively supervising the device to be present, only when it fails to check in during the prescribed amount of time you set in your globals (default is 4 hours off the top of my head) and until it's reached that time, the M1 doesn't care if there's a battery in it, the status of it or whatever you toss at it.
 
If you're not experiencing system-wide trouble conditions, then I wouldn't suspect the receiver as the culprit. Also, given the actual age of the system, which I'd put about 7-8 actual years based on your details, I don't think batteries being replaced at this time is out of line and not due to cold conditions, more so age.

Thanks for the reply.
 
I'm going by memory as to the initial install time so I may be wrong about the 15 years.  
 
The receivers are, indeed, M1XRF2G's.  
 
One is located about 150ft from the M1 and the other closer to 250ft.  They've worked flawlessly since install.  I confess, however, that my initial install had a hiccup in that the wire I ran was Cat5e cable.  There are keypads along the length of the run with the final keypad and one of the RF2Gs at the very end of the run.  It turned out that the cable run length to the endpoint was too long for that gauge of wire.  I doubled up the twisted pairs, though, and the problem resolved itself.   
 
The transmitters are GE.  I can no longer upgrade my Elk firmware because of this - it seems I'd have to upgrade to the new RFTW transceivers and that's quite an expense (I'm not sure if I'd have to replace all of my wireless devices too)
 
So the distances would be something like this
 
M1 ---- 150ft ----- M1XRF2g ------- 100ft---- M1XRF2G
 
The transmitter in question is within 10 ft of the first RF2G and there are 5 others in the same location that all function fine.  So... I suspect that it's the transmitter and not the RF2G or M1.  BUT..... at the moment the thing that confuses me the most is that I can't run the enrol/update routine.  When I go to that page it insists that an area is armed but there is no area armed.  I'm not sure what to do about that - I'm stuck.  Regardless of anything to do with transmitters or the RF2G's shouldn't I be able to run the enrol/update?
 
 
mark

RAL said:

Are the "transmitter missing" and "low battery" warnings limited to zones that are on just one wireless receiver, or are they spread across all of them?  If they are all getting these warnings, that would steer me to suspecting the M1 rather than the wireless receivers.  

Click to expand...

Thanks for the reply.
 
I'm not sure how I would tell which wireless receiver it is.  Those transmitters seem to have quite a range and I think they would overlap.  With that said, though, I have had issues with transmitters that are 'closer' to each of the receivers so if I had to pick one over the other I don't think I could.
 
The part that leads me to thinking about the M1 is that it seems to think that there is an area armed and so it won't allow me to run enrol/update.  I've checked and rechecked and no areas are armed so I'm not sure where it's getting this faulty information from.

There's probably a few items going on.
 
First, you can upgrade the firmware on the M1, however you would need to swap the RF2G's to RFEG's.  About $200 street price for a pair. Not ridiculous.
 
Second, you have a topology issue with the light AWG cable, so I'd verify you didn't lose a conductor or two since your install. Most likely you're introducing a voltage drop issue on the bus that should be considered at the last device. Elk specifically notes to NOT daisy chain power, and especially with bus devices, as once they get close to 12VDC operation, issues arise when the voltage sags. 250' from the panel OAL isn't the issue, your issue there was voltage drop due to topology (devices installed in parallel on power). I would suggest you consider changing your topology or install a DBHR and split your bus devices across the 4 pair.
 
Third, Given the information, you most likely have a bad transmitter.

Fourth, your symptoms match a known bug that was fixed via FW releases....I think 5.3 had a SPAR for something similar (armed areas) which I would confirm with Elk....99% 5.3.0 was the last FW supporting the RF2G's.
 
Assuming RP is not flagging an area as armed barring connection, I would try downloading and then dumping the program....or bootstrap the M1 with a blank program and dump your good program back into it (assuming you download successfully). Barring that, you can manually enroll via KP and try that route. Can also pull all power off the board and remove the coin cell under the shield, then re-download the program back into the panel.

DELInstallations said:

There's probably a few items going on.
 
First, you can upgrade the firmware on the M1, however you would need to swap the RF2G's to RFEG's.  About $200 street price for a pair. Not ridiculous.
 
Second, you have a topology issue with the light AWG cable, so I'd verify you didn't lose a conductor or two since your install. Most likely you're introducing a voltage drop issue on the bus that should be considered at the last device. Elk specifically notes to NOT daisy chain power, and especially with bus devices, as once they get close to 12VDC operation, issues arise when the voltage sags. 250' from the panel OAL isn't the issue, your issue there was voltage drop due to topology (devices installed in parallel on power). I would suggest you consider changing your topology or install a DBHR and split your bus devices across the 4 pair.
 
Third, Given the information, you most likely have a bad transmitter.

Fourth, your symptoms match a known bug that was fixed via FW releases....I think 5.3 had a SPAR for something similar (armed areas) which I would confirm with Elk....99% 5.3.0 was the last FW supporting the RF2G's.
 
Assuming RP is not flagging an area as armed barring connection, I would try downloading and then dumping the program....or bootstrap the M1 with a blank program and dump your good program back into it (assuming you download successfully). Barring that, you can manually enroll via KP and try that route. Can also pull all power off the board and remove the coin cell under the shield, then re-download the program back into the panel.

Click to expand...

 
Wow - thanks!
 
That's some seriously good information.
 
Pardon my ignorance but what's a DBHR?  
 
I'm going to try your other suggestions next - loading a blank program and then reloading my current one.  
 
If you have a moment and don't mind a few newb questions...
 
 
- What gauge wire would you say is appropriate for a 250ft cable run to minimize voltage drop.  On that long run there are 2 RF2G's and 4 of the keypads that fit into a single gang box with a decora faceplate.
 
- Is it acceptable to ditch the 12v from the Elk down by the first RF2G (ie remove the 12V lines that come from the Elk to that point) and power everything downstream from there with a regulated 12V power supply - like a computer PSU?  That would cut the first 150ft off my cable run and do wonders to minimize my voltage drop.
 
- If I replace my RF2G's with RFTW's will my GE Crystal transmitters still be compatible?  If the RFTW's are only a coupla hundred bucks a pair I'd definitely pick those up and get back on an upgrade path with the M1 - it's been great and very solid.  I have it integrated with my ISY and my Homeseer and it's been fantastic.
 
Thanks again for your help!

MarkJames said:

Wow - thanks!
 
That's some seriously good information.
 
Pardon my ignorance but what's a DBHR?  
 
I'm going to try your other suggestions next - loading a blank program and then reloading my current one.  
 
If you have a moment and don't mind a few newb questions...
 
 
- What gauge wire would you say is appropriate for a 250ft cable run to minimize voltage drop.  On that long run there are 2 RF2G's and 4 of the keypads that fit into a single gang box with a decora faceplate.
 
- Is it acceptable to ditch the 12v from the Elk down by the first RF2G (ie remove the 12V lines that come from the Elk to that point) and power everything downstream from there with a regulated 12V power supply - like a computer PSU?  That would cut the first 150ft off my cable run and do wonders to minimize my voltage drop.
 
- If I replace my RF2G's with RFTW's will my GE Crystal transmitters still be compatible?  If the RFTW's are only a coupla hundred bucks a pair I'd definitely pick those up and get back on an upgrade path with the M1 - it's been great and very solid.  I have it integrated with my ISY and my Homeseer and it's been fantastic.
 
Thanks again for your help!

Click to expand...

 
I'd run at least 18 AWG wire for the power to the remote devices.  That will keep the voltage drop to less than 1V. 16 AWG would reduce the loss further to less than 0.6V for the load you have.
 
The M1DBHR is a retrofit hub that will let you wire the data bus devices as home runs, rather than daisy chained.  That way, each device will draw power over its own direct cable back to the M1.
 
You could use an aux power supply to power some of the devices that are further away from the M1.  But you'll want to use something that has battery backup, rather than an old PC power supply.  Take a look at the Elk P624 if you just need to power the keypads and wireless receivers.  You will need an signal ground (i.e. NEG terminal) connection from the aux power supply back to the M1 if you go this route.
 
You don't want to replace the M1XRF2G with a M1XRFTW since the XRFTW is not compatible with the GE sensors.  Instead, you want to use the M1XRFEG that DEL mentioned.  The XRFEG is compatible with the older GE transmitters and is supported by the newer firmware.

Thanks very much for all the help and info.  
 
I'm going to spend the next day or two going through my system and drawing a map of it - something I should have done at the outset but in my zeal to get it working neglected to do.  I hadn't anticipated running it as far as I did.  We live on a small lake in rural BC and I initially just planned on getting the system out to my garage and to an outbuilding in our yard - that's why I started with cat5e cable. Once I got going, though, I saw a lot of opportunity and flexibility so I expanded it perhaps past where I should have.
 
A couple of other questions pop up, though, before I get going too far. 
 
First off - is the voltage drop as significant a problem on the data lines as it is on the power lines?  I assume the voltage across the data lines is lower and if so wouldn't be as affected by the length of the cable run.  If that's not the case then I may as well skip the P624 idea and replace the cable as the 624 would affect the power issue but not a possible data issue.  I have gigabit LAN running the full length of this install with no problem so I'm inclined to think that the data *should* be ok.
 
Second - if I go with the 624 - I'm not sure what you mean by a signal ground back to the M1.  Looking at the 624 it has transformer inputs and then a +- pair of 6/12/24 VDC outputs.  So if I break the +- 12VDC pair coming from the Elk at the first XRF2G would I be just capping off the power side and reusing the ground wire of that pair somehow?
 
Oh - and thanks as well for the XRFEG pointer.  I would have felt awfully stupid getting the TW's and then having to replace all my transmitters.
 
Thanks!
 
mark

MarkJames said:

Thanks very much for all the help and info.  
 
I'm going to spend the next day or two going through my system and drawing a map of it - something I should have done at the outset but in my zeal to get it working neglected to do.  I hadn't anticipated running it as far as I did.  We live on a small lake in rural BC and I initially just planned on getting the system out to my garage and to an outbuilding in our yard - that's why I started with cat5e cable. Once I got going, though, I saw a lot of opportunity and flexibility so I expanded it perhaps past where I should have.
 
A couple of other questions pop up, though, before I get going too far. 
 
First off - is the voltage drop as significant a problem on the data lines as it is on the power lines?  I assume the voltage across the data lines is lower and if so wouldn't be as affected by the length of the cable run.  If that's not the case then I may as well skip the P624 idea and replace the cable as the 624 would affect the power issue but not a possible data issue.  I have gigabit LAN running the full length of this install with no problem so I'm inclined to think that the data *should* be ok.
 
Second - if I go with the 624 - I'm not sure what you mean by a signal ground back to the M1.  Looking at the 624 it has transformer inputs and then a +- pair of 6/12/24 VDC outputs.  So if I break the +- 12VDC pair coming from the Elk at the first XRF2G would I be just capping off the power side and reusing the ground wire of that pair somehow?
 
Oh - and thanks as well for the XRFEG pointer.  I would have felt awfully stupid getting the TW's and then having to replace all my transmitters.
 
Thanks!
 
mark

Click to expand...

 
The signal on the data lines is a low voltage differential signal, which uses little current, and there is negligible voltage drop, even when using Cat5e.  It's the gauge of power wires that matter.  They have to be able to carry the load of all the devices you connect.  If you were to connect everything with Cat5e using home runs to each device, it probably be ok since each one would carry just the load of the single device.  But when you daisy chain them using Cat5e, that's where you can get into trouble with too many devices and/or too long a run.
 
If you add an aux power supply, you need to connect the negative side of the 12V power supply back to the negative side of the M1.  That is, connect the "-DC Output" on the P624 to the NEG terminal on the M1.  You can use the ground wire in you existing cable, as it doesn't need to carry much current.  It's just providing all the devices with a common reference point.   Make sure that you don't connect the "+" sides together as that will cause problems.

Thanks.
 
I'll get to work on it!
 
mark

Well - I couldn't get the 'area armed' message to clear.  I ended up having to do a global initialization to clear it.  Thankfully it's gone now.
 
Along the way I realized, though, that my initial install has some issues as far as the data bus goes.  I'm going to have to make some changes.  
 
The M1 was an upgrade to an existing system.  There were pre-existing cable runs to 3 keypads in the house.  The advice I got when installing the Elk was to use the DBH to connect my old keypads.  That's what I did.  And it seemed to work.  But in reading through the literature the correct way to do it would have been using a DBHR instead.  
 
Presently I have two runs coming off the data bus on the M1.  One set goes to the DBH and the other goes down into my yard with a series of daisy-chained keypads and RF2G's.  But in reading the docs for the DBH I don't think that was an appropriate thing to do.  When you use the DBH you jumper JP3 to terminate.  The DBH has a terminating resistor too.  But then the cable run down into my yard is also terminated.  My understanding is that there should be only 2 terminating resistors.  The DBHR should fix this problem - if it is one - it worked for years like this.  
 
Anyways - I updated the firmware so I'm forced into the new receivers anyways.  I'm gonna swap out the DBH for a DBHR and put the extra power supply along the longer run and see how that goes.
 
mark

The M1 can run 2 branches terminated at the end. When using a passive DBH, you terminate at the panel and via the provided RJ. The DBHR provides 4 managed branches, each of which can be split into 2 parallel branches, so a total of 8 home run cables per DBHR.
 
If you don't terminate the M1 itself, you can add a second DBHR for 16 home run cables unless you look at some of the other items or topology.
 
Keep in mind, the DBHR has devices connected until you have 2 terminated branches per terminal location.....once you terminate, the data does not pass to the next downstream port.

Thanks.
 
At the moment I see that my DBH is wrong for the application.  I used it to run to my existing 4 wire keypads but that makes for a long stub from each keypad and I don't get the proper return path.  It looks like the intention is for the spliced portion to be very short.  In my case the spliced portion is the entire run of the cable.  It's been working but I don't think it's the way it's intended to be.
 
I've ordered 3 new RFEG's (I'm adding one to make sure I have no signal  strength problems), a P112 which is just a power supply in a box with battery backup, and a DBHR to replace the DBH.  This is the first I've spent on it since install in the early 2000's so I don't feel too badly about it.
 
I'll pay more attention to termination etc. this time
 
mark

If you have only 4-wire cable to the old existing keypad locations, then you should not be plugging those into a DBH.  That's where you need to be using a DBHR.
 
There should not be more than 2 terminators on a data bus.  If you use a DBHR, that creates multiple data buses, and then each bus from the DBHR should also have 2 terminators.