Trouble adding navigator keypad to ElkM1

The M1 and all other components were bought new from jmac. The control panel is hardware version .13, boot 3.3.6, firmware 5.3.10. I did locate a data hub and have one on the way.

In the meantime this evening I'll try the master code and keep digging to see if I can turn up a clue somewhere.
 
rhosch said:
The M1 and all other components were bought new from jmac. The control panel is hardware version .13, boot 3.3.6, firmware 5.3.10. I did locate a data hub and have one on the way.

In the meantime this evening I'll try the master code and keep digging to see if I can turn up a clue somewhere.
Have you tried connecting just one keypad to the M1 with a short length of cable, so that they keypad is right there by the M1?  Make sure the termination is set right when you do that.  If that works, then that would tell you that the problem is most likely with your cabling.
 
I believe I did early in the process of troubleshooting but you are right, that would be an easy sanity check and something I will do to make sure.
 
Well, I got it to accept the user code finally but have no idea what was causing the problem. The master code was rejected as well, meaning it wouldn't disarm. Any user code I had created would not disarm the system. But, going through the keypad menus it clearly accepted those as valid codes giving access to system program, and allowing me to change user coded through the menu (new codes of course also not disarming the system).

I deleted all users I had created, made one new user with default settings and only changed the user code. That worked. The only difference I can see is that I haven't granted more rights than the default settings as I did last time, but at least it's working.

Very strange.
 
rhosch said:
As for wiring, I am close to but not identical to the recommended method. There are two devices in or adjacent to the control. This is the hardwired zone expander and the KP2 keypad which I installed in the network closet adjacent to the M1 to assist in setup and debugging. These two do not have termination jumpers installed. The KPNAV and wireless receiver (M1XRFTWM hardware 7.3 boot 1.0.8 firmware 1.2.62) are remote from the control (which is hardware .13 boot 3.3.6 firmware 5.3.10). Those remotely located devices do have terminal jumpers.

Technically, according to the installation diagram, I should have a branch going to say the zone expander and then from there to say the wireless receiver. Likewise a branch to KP2 then from there to KPNAV. However, out of convenience, the connection is made at the control board instead of at those local devices. The 4 conductor wire runs from control to those local devices is about 1 foot, so electrically there is essentially zero difference. Not exactly zero, but danged near it. Would be surprised if that's causing the weird user code issue but I am going to change that connection point just to be sure. For the king term, I ordered the data hub because anything past 4 devices in my current wiring scheme would be very cumbersome and I'd like it to be easy in case I want to add on down the road.
 
I was just re-reading this earlier post above about how you have things wired.  If I understand what you've done, it sounds like you have a data bus branch with the KP2 and the input expander, and no terminator.  Not sure if they are daisy chained or if each is wired with a separate cable to the M1.
 
Then you have another branch wired to the wireless receiver and a third branch wired to the KPNAV.  Each of these branches has a terminator.
 
A 3 branch configuration is not valid for a RS485 bus.  Although the cable to the input expander and the KP2 is short, it still makes a difference.  A short cable may not seem like much, but it is still significant.
 
A proper way to do this would be as follows:
 
Term---KPNAV -----(long cable)---- Input Expander ----KP2 ----- M1----(long cable)---- M1XRFTW---Term
 
Pretty close. Technically, I currently have 4 branches all home run to the M1, two being long runs with termination, two being 1ft or less runs without terminations. Electrically it is very close but not identical to the daisy chain configuration with short cable to a device then long cable from there to second device with termination. There is about a 0.01ohm difference in the two configurations, and with rs485 data rates I find it exceedingly unlikely the timing difference between the two would matter.

I will, however, get it corrected to match the published recommendation. Now that I resolved whatever the programming hangup is everything seems to functioning as expected, but the data hub will if nothing else make it easier to expand in the future.

Now on to eliminating the "pop" I get when connecting output 1 to whole house audio amplifiers. I didn't have a 10uF cap on hand when I wired it up and I'm hoping it is just a DC bias issue that blocking cap will remove. I ordered a few which arrived yesterday so fingers crossed.

Seems it's just moving from one little snag to the next with this system!
 
rhosch said:
Pretty close. Technically, I currently have 4 branches all home run to the M1, two being long runs with termination, two being 1ft or less runs without terminations. Electrically it is very close but not identical to the daisy chain configuration with short cable to a device then long cable from there to second device with termination. There is about a 0.01ohm difference in the two configurations, and with rs485 data rates I find it exceedingly unlikely the timing difference between the two would matter.
The RS485 bus is a data transmission line and, to work properly, needs to have both ends (the ends of the 2 branches) properly terminated.  If there is only one branch, then the M1 itself is one of the endpoints, and then you place a terminator on the M1.  
 
You've created a 4 branch bus, with no termination on the two additional branches.  Even though the wire lengths are short, that can still create havoc with signal reflections, waveform distortion and data corruption.
 
Before you spend any extra time trying to figure out what's wrong, fix the data bus wiring and eliminate that as a source of trouble..
 
I'm in the midst of installing my M1G altlhough mine is much simpler at this point.  I only have 2 keypads to contend with, but would like to add my wireless zone expander in my next phase.  When purchasing the kit, I wish my retailer had told me that I was going to need either an M1DBHr or MIDBH in order to install the wireless zone expander.  I would agree with one of the earlier responders that the ElkRP doesn't always communicate well between database and panel and you have to make sure that the changes have taken before moving on.
 
Your issues with the keypads remind me of those old "apple networks" in the 90's.  Back in the day ,if you didn't terminate the endpoint appropriately you would experience some pretty bizarre communication issues !  don't even understand how your keypads are communicating with the panel given the topology that you described.  It's pretty clear, only 2 connections to the bus can be made.  Other keypads and or expanders have to be daisy chained on a segment and terminated at the end.  With 4 wire home runs, I don't see how you can effect a daisy chain at the panel.
 
 
From a dc network analysis approach, the only difference in a daisy chained and a star topology is where the connection points are made. It isn't as if a keypad has an rs485 in and an rs485 out. There just a connection point, with a cable coming in and out both connected at that common point.

Imagine you had 2 devices on a single branch, one 1000 ft from the panel and the other halfway between at 500 ft. Start moving the halfway keypad even closer to the panel... 100 ft, 10 ft, 1 ft, 1 inch. As that approaches zero, the connection point for that 1000 ft keypad also approaches zero, until finally it is actually connected at the panel as well.

As pointed out, it's a transmission line so complex impedance does matter, but for very short cable runs, like a foot or less in my case, that impedance is very, very small. Rs485 may be sensitive but not quite that sensitive. I guess my system is proof of that... although I was starting to wonder, it seems I was seeing just a programming glitch not a communications one, and it is functioning fine with 4 branches currently.

As a practical matter I'll fix that as soon as the hub arrives. It will make future expansion easier, but also if and when I run into any other issues I don't want to always be wondering if that tiny difference is actually making a difference!
 
Ok, next issue. I posted this to elk products forum a few days ago and don't think it's even gotten a single view yet. The data hub has been shipped and I will sort out the bus connection as soon as it arrives.

I have connected my M1G to my whole house audio using the line level conversion circuit described by Elk (including the optional 10uF blocking capacitor), which feeds a signal sensing override input on my WHA amplifier.

This works as expected, except the M1G appears to be producing a quite audible and annoying pop both before and after any synthesized voice message (garage door is open, or whatever). The pre-message noise is a sort of pop-boom and the post-message noise is a softer pop or click.

I have swapped inputs on the amplifier, including connecting the M1G to an always on input that bypasses any signal sensing circuitry in the amplifier, and have verified that the noise is being generated by the M1G itself.

Any suggestions on possible remedies? Is there audio out available on the J7 header that might be useful in this situation? Would purchasing the two-way listen in module provide an audio out that might be free of this noise? Or, if there are any thoughts on the origin of this noise (how the panel is powered, grounded, configured, or anything else) Id love to hear them. I have 16 zones of audio available to send messages and sirens to which would be quite nice, but for now Im limited to muddled output through an Elk Echo speaker that really isnt intelligible.
 
I haven't done anything with my M1 and whole house audio, but there have been various threads over the years from other folks who have.
 
The pop you hear seems to originate in the M1, and I get the impression that the way to eliminate it is to use a relay to disconnect things until the M1 starts to speak, using rules to control that.
 
Audio output is available on the J7 connector, but I don't think it will eliminate the pop.
 
http://cocoontech.com/forums/topic/30699-elk-m1-audio-interface-j7/
 
Some other threads that might be helpful:

http://cocoontech.com/forums/topic/3950-voice-select-between-elk-and-sound-card/

http://cocoontech.com/forums/topic/25993-m1-elk-twa-and-elk-124-no-hassle-auto-switching/

 
 
That's a thought. If it happened to keep the relay open until just after the pop noise has finished and open it again immediately after voice message before the ending pop arrives that would work.

I guess a relay is cheap and it's easy to test and see what the timing of that actually is.

I guess the TWA might help. Sounds like it did for at least one person.
 
I vaguely remember having this problem with my Elk at my previous home where I used a relay to switch between the HomeSeer computer's sound card output and the Elk's sound output as I wanted them both to feed my voice announcement speakers via an Elk W800 amplifier.
 
I really can't remember how this was fixed though.  IF there is a way to adjust the sound output of the Elk maximize that, then minimize the volume output of the amplifier and see if that improves.
 
I do remember having to have each voice command out of HomeSeer first switch a relay before making announcements.  Might have had a 'wait xx milliseconds' statement in there after the switching.
 
Sorry I don't have more details
 
Back
Top