ELK M1 GOLD KEYPAD

[crossbar]

Your overall length statement is NOT true. It splits the 485 bus into 4 managed branches. It does not regenerate or repeat the data. Look at the note on the second page of the installation document. Right in the diagram of the topology and connections, 4K total length, which I've confirmed with Elk before (I had a project that required an exceptionally long pull between buildings).
 
Your information about the M1, voltages it operates on and functionality and design criteria is inherently flawed. The main panel does a LBC at 10.2VDC, however the bus devices will start to reboot and lose connectivity far before that value. Once they start to dip below 12V, they start misbehaving, and right around 11.5VDC (memory) is when the reboots actually start occuring with bus devices.
 
The design criteria for the M1 bus devices should be to maintain 12VDC (or as close to) at the end of the run for VD calculations.

Wow.  This is why I am going to just bail on the Elk.  Too many long standing bugs that never get fixed, too many missing features, too much bad documentation, too many functions that just don't work well or don't work at all.
 
Quote from the M1DBHR manual "Like the Main M1 Bus, the Maximum wire length of any of the 4 branches on the M1DBHR is 4000ft." As stated this would mean that you could have up to 4 (or 8 with two M1DBHR) runs of up to 4000' each.  If this is not the case then the documentation should state that the total length of all runs can not exceed 4000' total.
 
If the M1 cuts out on battery power at 10.2V but the M1 peripherals cut out at higher voltages that would make the M1 a useless system on battery power.  From what I have seen so far with the Elk that would not surprise me too much.  But I do think you are incorrect on this.  The manual for the input expander says it will operate form 9-14 VDC.  Other devices I just checked don't state a minimum voltage just 12V or 13.8V operating voltage.   The peripherals would need to operate at least down to 10.2V, and since the output voltage from the M1 is actually 0.5V less than battery voltage this would be 9.7V to the peripherals at the point that the M1 shuts down.  If any of the devices reboot at your 11.5V you better install charge pumps for their power.   This is one big reason that having a majority of your capabilities in lots of "expandable" peripherals is not such a great thing.  More points of failure, more sources of problems, more wires, more installation space required, etc.
 
I've wasted too much time here and on this system already I'm moving on.
 
"The design criteria for the M1 bus devices should be to maintain 12VDC (or as close to) at the end of the run for VD calculations." - Thus my initial point that voltage drop of the power is much more limiting of the wire length than the RS-485 bus.

 

[Del91574]

HAI is even worse for bugs and items that don't get fixed. Don't even get started with documentation.....on a product that costs 3X the amount of a M1 out of the box.
 
I know the documentation quite well. You are referencing the wrong section, it's not a "manual" but where they document the wiring topology. The DBHR does not regenerate data, so that's part of the design itself. That's part of the reason why Elk tells you to NOT install the hubs out in the field.
 
You're confusing system operation and documents as absolute values for system operation and design criteria. A LBC on a security device only disconnects the battery from the panel to prevent a deep cycle, not keep the panel running flawless up until that point. In actuality, almost every system out there, once you start having voltage sag below 12V, the components stop behaving. At 11, then you're already in pretty deep trouble. The panel will send a low battery condition well before the LBC shuts the system down (typically followed with some false alarms or signals).
 
I've gone through this on a few systems attempting to diagnose what was going on upon power loss with peripherals in outbuildings. I had Altronix supplies, Elk LBC's and cold weather that I did not use a proper correction factor on the batteries I installed. The system itself was in a main house, with short conduit runs, appropriate supplies and batteries. Power loss, the panel itself stayed up and running, no issues. The bus devices rebooted and were running about 11VDC. They would reboot (1367 in the log) They would reboot, then lose comms and then reboot again.
 
Think about it this way, your normal 12V SLA battery is NEVER going to be running at 12V or less unless it's bad and needs replacement. Typically, around 12.5V or higher. Same with most charging circuits, 12.5V or higher (within reason). Usually, you're going to see around 13V.
 
You call them "charge pumps" which I'm assuming you're referring to auxiliary power supplies. Very commonly installed on many systems, and in the case of the M1, since there's only 1A to play with to begin, they're going to be a SOP on most installs. Power is easy to fix. You only need to carry a common negative through the system. The distance on the data bus is the item that can't be easily addressed. I haven't gotten a true answer from Elk about using FOC's or repeaters, but they've alluded to timing and latency being the issue.
 
A lot of this isn't unique to the M1, however there are some added challenges with the M1's bus being 485 vs. some of it's competitors. I think what many, yourself included, think where panels like the M1 run short, are not understanding the process to get a unit through UL and the related issues. Don't forget, items like Zwave and the like have only really proliferated within the last 4-5 years. There has been no standardization, either using UPB, Zwave, Zigbee or any other protocol. Remember, when the bulk of these panels came to market, X10 was still viable.
 
What people, like yourself, are complaining about is that the products aren't on the bleeding edge of integration, which they're never going to be. Security systems and panels simply can't and won't be. Hell, even systems that cost tens of thousands are just as conservative, and they're controlling much more.

 

[thing]

As an electronics design engineer I find this very disturbing.  And to think these panels also meet UL.  Any product that is built that cuts out at such high voltages for a VRLA battery operated system (on backup) is just a very poorly designed system.  A SLA battery at C/10 will start at 12.5V then by 50% will be down to 12V and at 20% will be down to 11.5V.  At C/5 you start out at 12.1V are down to 11.6V at 50% and down to 10.9V at 20% and drops off at 10.2V at 0% this is at the battery terminals.  A battery operated system should be designed to operate at a minimum of 9V and even lower for any modules operating at a remote distance (i.e. cable voltage drop).  To hear empirical evidence that the Elk modules reboot in such real world cases is very disturbing (unless they were improperly installed) .  BTW charge pumps are just DC-DC converts that produce a higher output voltage than their input voltage (by drawing more current).  This would allow a remote module to receive a lower voltage and boost it up to the required voltage of the module.   Something that Elk should have designed into their remote modules if low supply voltage is an issue (of course it is always better just to select components for the module that will operate somewhat below the lowest expected voltage levels).
 
What good is a security system that falses and has erratic behavior before it shuts itself down due to a low battery?

 

[RAL]

As an electronics design engineer I find this very disturbing.  And to think these panels also meet UL.  Any product that is built that cuts out at such high voltages for a VRLA battery operated system (on backup) is just a very poorly designed system.  A SLA battery at C/10 will start at 12.5V then by 50% will be down to 12V and at 20% will be down to 11.5V.  At C/5 you start out at 12.1V are down to 11.6V at 50% and down to 10.9V at 20% and drops off at 10.2V at 0% this is at the battery terminals.  A battery operated system should be designed to operate at a minimum of 9V and even lower for any modules operating at a remote distance (i.e. cable voltage drop).  To hear empirical evidence that the Elk modules reboot in such real world cases is very disturbing (unless they were improperly installed) .  BTW charge pumps are just DC-DC converts that produce a higher output voltage than their input voltage (by drawing more current).  This would allow a remote module to receive a lower voltage and boost it up to the required voltage of the module.   Something that Elk should have designed into their remote modules if low supply voltage is an issue (of course it is always better just to select components for the module that will operate somewhat below the lowest expected voltage levels).
 
What good is a security system that falses and has erratic behavior before it shuts itself down due to a low battery?

 
There's more to it than just the voltage produced by the battery.  What matters is the total energy stored in the battery.  The voltage of an SLA battery will drop off differently depending on the discharge rate, as you pointed out.  But even if the voltage has dropped to say, just 10.5V, if the battery can't deliver sufficient current to power the system, things are going the get flaky.
 
You solve this problem by installing an adequately sized battery for the system you need to power and the length of time you need it to operate on battery power.

 

[Del91574]

Bingo.
 
Same thing with calculating the VD of the run and oversizing the conductors instead of pulling that sleek and sexy category cable to everything.
 
Don't forget, once you drive a battery down to the 10.5V range, you're at risk of deep cycling the battery and damaging the system.
 
The system is NOT designed to be run primarily off batteries, it's designed for AC operation with battery backup, as all alarms are. People aren't performing accurate aux power calcs, let alone standby battery calcs in line with the industry norms when putting these things in (often). Toss a couple of 12V 7A's in and call it "good".

 

[thing]

The DBHR does not increase the total length available for the M1's data. 4000' end to end. Only changes the physical topology of the bus so that daisy chaining is not necessary.

 
 

Your overall length statement is NOT true. It splits the 485 bus into 4 managed branches. It does not regenerate or repeat the data. Look at the note on the second page of the installation document. Right in the diagram of the topology and connections, 4K total length, which I've confirmed with Elk before (I had a project that required an exceptionally long pull between buildings).

Can someone clarify the bus lengths of the M1DBHR?

The manual says that "It splits the main 485 data bus into 4 managed 485 branches."  And then "Like  the  Main   M1 Bus  , the  Maximum wire  length of any  of the  4 branches on the  M1DBHR is 4000 ft."


This seems pretty clear and is what one would expect based on how this would be accomplished.  However DELInstallations seems to be claiming otherwise and since he seems to be a long time installer I would hope he would know what he is talking about.


Is the written documentation from Elk incorrect and the field installer correct or via-versa?  I don't really see how the M1DBHR could do what it does and have a total length limitation, as stated by DELInstallations, there is just no way to implement this if they are all the same bus.  In which case if they are all separate "managed branches" (i.e. separate buses) then they, as stated in the manual, would each have a 4K limit.  Not total.

 

[vc1234]

Is the written documentation from Elk incorrect and the field installer correct or via-versa?  I don't really see how the M1DBHR could do what it does and have a total length limitation, as stated by DELInstallations, there is just no way to implement this if they are all the same bus.  In which case if they are all separate "managed branches" (i.e. separate buses) then they, as stated in the manual, would each have a 4K limit.  Not total.

 
Elk M1 uses a single rs485 bus, no matter how it is physically arranged, not multiple buses.  An rs485 bus is a single differential pair line with multiple drops and the maximum length of 4000', a star configuration is not possible.  Therefore, the installer is right and the documentation is wrong.  It is pretty obvious that there is only one bus just by looking at the controller that has only one rs485 connection point, not four.

 

[Del91574]

Without getting into the entire explanation and what is or is not correct, where, why and how, Elk's DBHR is a star/hub repeater which bidirectionally listens for data on each span and retransmits the data on each span. Nothing else, not a repeater. The length is documented. 4K max system length. The DBHR allows a spoke/hub installation where a non-hub based M1 install is bus based, but either must be physically wired as a bus or additional conductors installed to facilitate a bus (at the cost of OAL bus length).

 

[vc1234]

Oops, I did not notice the "R" for the repeater and thought we were talking about M1DBH.  My fault. Now, I'll have to retract my previous statement and make a U-turn: "thing" and the manual are right and the installer is wrong.
 
If the repeaters are implemented properly, *each* of the 4 segments should behave as a normal rs485 bus with a 4000' max distance limit (due to signal distortion).  See this app note for an example starting on page 3: http://www.detcon.com/1-documents/technotes_and_bulletins/Tech%20Note_485network.pdf.
 
Not sure why  elk manual insists on connecting the 4 way repeater as close to the controller as possible.  If implemented properly, the connection could have been made at any point on the original bus since the original signal is regenerated by the repeater anyway.  Perhaps, elk has additional timing requirements that may be violated if the signal RTT is higher than 2*4000'/0.7*speed_of_light, regenerated or not.

 

[Del91574]

The DBHR isn't pure data regeneration. It changes the topology from bus to spoke/hub "R" means retrofit. 
 
Been through this with Elk. Can't remember the discussion I had with them regarding timing. I brought up using FOC's on the M1 before to get around the distance and remember something being mentioned about it. The distance limitations were brought up many times in the discussion and ways to get around it to facilitate a specific install I was working on at the time.
 
I'd have to search some older datasheets from the original M1's and install hardware that are clearer. Been installing them since they came out around '05.
 
I'm bowing out of the argument in this case. Better things to worry about

 

[thing]

I have to concur with VC1234.  And I was actually able to talk to Elk support and he said the manual is correct.  Just cautioned that anything that has a high data usage may have an issue on one of the M1DBHR legs.  Like the Navigator Panel or RF receiver.  He said firmware uploads may be an issue as well and advised connecting devices to the main bus to do any firmware updates.

 

[Del91574]

You can actually run the M1 with a bunch of 4C bus devices in parallel, unmanaged, and get it to work, but you're gonna have the issues described above.
 
Many hours talking to Elk about bus length and ways to get around it, be managed and reliable.