Elk M1 Communications: IP, GSM Uplink 4500, and Phone over Comcast

SteveInNorCal

Active Member
Good afternoon, all. I'm wrapping up the installation of my Elk M1 Gold. Right now working on communications.
  1. I installed the XEP module and brought it up fine.
  2. I created a GMX email account for simple SMTP mail and am successfully getting emails and text messages from both the "Test" button and a rule that fires off a "heartbeat" email or text msg every hour (for now -- will reduce to 1/day). Thanks to all who contributed to earlier threads on email difficulties -- it was relatively painless with all the kind background help many members provided across many threads.
  3. I created a dynamic IP host address using Dyndns and that is working well after configuring my router.
  4. I just installed eKeypad on my iPhone 4s and brought it up ok. Nice app so far. It synced quickly, too, over port 2601. Able to bypass/arm/disarm and control lights. 
  5. I installed an Uplink 4500EZ GSM radio and also bought an AlarmRelay CS monitoring subscription.
This week I'll work with Alarm Relay to get CS comms running (primary over IP and backup over GSM).
 
Finally, on to my questions about communications...
  1. I was originally going to use my legacy POTS line to externally communicate to the M1, but we switched to Comcast for TV, Internet and voice, so I finally yanked out my 30 year old PacBell / AT&T copper line. Now that I've got solid IP communications and GSM communications, I'm wondering if I should just abandon putting the Elk on the Comcast phone line. Have others set up TRIPLE communications (Phone over IP, IP, and GSM)? The IP and GSM will communicate to the CS. I want to monitor the system remotely using phone over IP and the IP line. That seems like overkill, especially with eKeypad now running on my iPhone. But I can see cases where I could lose the iPhone and only have access to a regular phone. So it seems like this would be a nice, simple backup. What do you think?
  2. Here's the rub. I'm experiencing some Comcast phone difficulties that I haven't been able to solve. I set up the phone coms and was able to have the M1 make a call to my mobile using a simple rule that read me the time at 11:30 AM. But I am unable to go off hook and dial "***" to be able to send commands to the M1. Also, I can't get the Elk to answer incoming calls. I haven't yet tested dialing out based on alarm triggers, but that should work based on the success with the outbound call made via rules. Any ideas why "***" doesn't work and why the M1 won't pick up inbound calls? I'm dialing the "***" using our Panasonic cordless phone KX-TGE274S (DECT 6.0).
 
Sorry for the long-winded questions, but it seemed background was necessary. Any help would be greatly appreciated.

Steve
 
I think your problems with dialing "**" and also not being able to get the Elk to answer incoming calls are probably caused by the Comcast box not providing the same electrical signalling as a standard US phone line. 
 
A real telco provided phone line has an on-hook voltage of -48VDC, and uses a ring voltage which is typically 90VAC with a frequency of 20Hz, although in some places, it may vary from as low as 40VAC to as high as 150VAC.   When you pick up the phone and go off-hook, the voltage on the line drops down to around 5 to 15VDC.
 
Some cable boxes use voltages as low as 60V for the ring voltage, since that allows the manufacturer to use the same phone line interface design in other countries where they require the lower voltages.
 
I don't know what voltage threshold the Elk uses when looking for a ring signal.  But if the Comcast box is providing something lower than the Elk's threshold, isn't going to answer.  Similarly, if the Comcast box provides a different off-hook voltage, the Elk might not realize it should be looking for the "**" sequence.
 
Do you know if the Elk is receiving proper line seizure from your Comcast EMTA? You should have a direct dial tone coming from your EMTA (Phone Modem) to the
 
RJ-31X jack on your ELK panel. Then then your secondary pair of wires should output to your telephones.
 
snesgenesis said:
Do you know if the Elk is receiving proper line seizure from your Comcast EMTA? You should have a direct dial tone coming from your EMTA (Phone Modem) to the
 
RJ-31X jack on your ELK panel. Then then your secondary pair of wires should output to your telephones.
The Elk M1 has screw terminals for R/T to telco and R1/T1 to the house. I initially wired it up using an Open House H616 telephone master hub which has a built-in external RJ-31X. But when I ran into trouble, I bypassed the RJ-31X as initial debugging and went straight from the EMTA to R/T on the M1 (phone in), then from R1/T1 on the M1 panel to the house wiring (phone out of M1). There is definitely dial tone on R/T on the M1 as it is getting through the M1 to the house (i.e., house phones work fine).
 
[sharedmedia=gallery:images:761]
 
 
RAL said:
I think your problems with dialing "**" and also not being able to get the Elk to answer incoming calls are probably caused by the Comcast box not providing the same electrical signalling as a standard US phone line. 
 
A real telco provided phone line has an on-hook voltage of -48VDC, and uses a ring voltage which is typically 90VAC with a frequency of 20Hz, although in some places, it may vary from as low as 40VAC to as high as 150VAC.   When you pick up the phone and go off-hook, the voltage on the line drops down to around 5 to 15VDC.
 
Some cable boxes use voltages as low as 60V for the ring voltage, since that allows the manufacturer to use the same phone line interface design in other countries where they require the lower voltages.
 
I don't know what voltage threshold the Elk uses when looking for a ring signal.  But if the Comcast box is providing something lower than the Elk's threshold, isn't going to answer.  Similarly, if the Comcast box provides a different off-hook voltage, the Elk might not realize it should be looking for the "**" sequence.
Thanks. BTW, when I dial the "* * *" sequence, I immediately get a fast busy signal. I get fast busy signal with a "* *" sequence, too. I just tried and get the same results with the "#" key / DTMF tone.
 
Any thought on possible debugging? Have others succeeded using the Elk to answer with Comcast or other ISP VOIP systems? Sounds like Elk needs to chime in here.
 
First, without getting into the fray, the issue is not a problem with Elk or the M1. While I don't like to do it, I have multiple M1's and EZ8's on VOIP (ahem, buzzword Digital Voice) phone services. Your issue should be brought to the service and equipment provider that is causing the issue (not Elk's problem, their panel works wonderfully on POTS lines). I've also run panels on Uverse's flavor of VOIP, but have had to request ATT to make specific changes to bandwith on a handfull of installs.
 
The issue is most likely compression and the codec and any other connected hardware configuration. In the case of a POTS line the DTMF for either the * or # has a defined action via ma bell's standards and the FCC. With VOIP, not the case. Most likely Comcast has some other functionality programmed into their ATA (such as * blah blah blah, access mode 321) that is based off the * emulated DTMF tone.
 
Dial tone is inconsequential here...the ATA is only simulating it anyways. The item that was brought up is part of the equation, most likely the voltage should be looked into, but further into this, the issue is going to be the VOIP modem.
 
Want to prove it? Get a Viking ringdown simulator and you'll be able to connect to the panel 100% of the time.
 
Thanks, DEL. I was afraid of that. The cheapest ringdown simulator I can find is about $90 and all it would do is prove the panel is working. Given the panel can go offhook and initiate calls, that probably isn't a good use of money.
 
AT&T is going to retire PSTN/POTS sometime in the next 10 years as they transition to IP networks, so I really don't want to spend $400/year to reinstall a single POTS line here. That would be a huge expenditure with limited functionality and usage.
 
A couple of other relevant things:
  • I bought my own Arris Touchstone DOCSIS 3.0 eMTA, so Comcast probably won't talk to me about my equipment or problems.
  • I didn't put the Arris on my Altronix aux PS. The backup battery on the Arris is just the included onboard Li-ion and I'm not sure how much standby time it will provide me. Good info on Arris batteries at this URL, but it only provides estimates of standby and talk time, not time providing IP service. http://www.arrisi.com/product_catalog/_docs/_specsheet/Touchstone-Li-ion-Battery_QIG_20FEB13.pdf
  • My WAP/Router are in an unsecured location, so a burglar can disable IP comms by yanking it out.
  • The Uplink radio is secured in the Leviton flush can holding the Elk and the GSM radio antenna is in the attic with the wire running through a 1.5 inch schedule 40 conduit. So the radio comms should be secure.
So where does that leave me? Abandon the dialer/voice/control features in the Elk that depend on POTS and just use the IP as primary coms and GSM as backup coms? What do you recommend to your customers in this situation?
 
When I answer this question, I can FINALLY complete my wiring!

Steve
 
POTS really isn't going away, it's just changing and the inherent issues are going to show up and in the case of the telco's, they're going to need to meet the same specs as they're already providing for the POTS line...ring voltage, loop current, etc. but just via another means instead of a direct line into the house. That said, the next-gen hardware is going to need to provide some additional inteligence as how many times I've run across an ATA without a viable connection but still pumping out everything else (including that simulated dial tone) and keeping everything downstream happy. Sure, it's easy for the company to ping the unit and remotely reset it, but it's not a valid item or troubleshooting step, and then how are all these intermingled systems going to be able to determine what or where the issue lies.
 
Without knowing the settings of the Arris ATA, which aren't going to be likely within your control, it's a moot point to try. You could bring the issue up to Comcast and say you're having difficulties with FAX's coming in or going out with how the unit is configured, can they investigate, but again, who knows if they'd do a thing on CSE.
 
You could verify the issue is with the ATA by using a cell with long DTMF tones to see if you can get the panel to pick up and then narrow if the problem is within the house or not (possibly a voicemail feature not enabled, etc).
 
I would get away from connecting the M1 to the ATA for monitoring purposes. Same goes with TCP/IP unless you just want it as a redundant "feel good" but without a bunch of additional hardware it's not going to be secure or really reliable. I've got plenty of IP communicators out there on FACP's and burg panels and you don't want to know how often the heartbeats are missed for X rounds on anything less than enterprise networks and hardware. It's why we're still mandated to maintain a second comms route that is not IP on FACP's.
 
I'd go with cell only and use the VOIP only for anything you want to control via dialing in, but these days, it's just as easy to port to the TCP/IP and get the free or paid apps to do the same (just with an outlay for the full featured apps).
 
Thanks, DEL. Just to be clear, I am not going to be using the voice over IP to transport commands to the Elk. I'm using pure pure TCP/IP comms as primary to Alarm Relay and to my eKeypad app on the iPhone. The Uplink GSM radio is for backup to Alarm Relay.
 
I was just thinking of using the DTMF tone capability of the Elk to interrogate the panel for those not-so-frequent occasions when I am out of reach of cellular data service. Using DTMF tones would be the third way to communicate to the panel after TCP/IP and GSM.
 
Also, I'm currently not using the panel for fire alarm...only burglar. We remodeled our kitchen a year ago and that triggered a code-required update of our smoke alarms so they are AC powered. I put in dual-sensor First Alert alarms with AC power and a red traveler wire between them so they all sound. I don't know if these are rated for attachment to a FA system.
 
BTW, Alarm Relay recommends using the TCP/IP comms as primary because of speed. They say the GSM path can be pretty slow which surprised me a lot.
 
I'm not going to touch the FA and 120VAC interconnection issues. Code compliance issues nonwithstanding, there's too many other reasons and liabilities. Personally, no matter how it's done, it's a half baked,bad idea IMHO. Plenty of reading out there.

So does the issue still persist if you dial in to the ATA from a cell phone or only while you are on an extension?
 
The main reason why AR is pushing the TCP connection is a somewhat selfish one, they aren't mandated to a maximum number of accounts per line card/virtual as they would be with a standard comms route. It also allows them to push away from their expensive POTS trunks (and service contracts for redundancy and service performance and/or cutover after failures) to something that is cheaper for them; The ISP provides the basic drop and they're done, the rest is dealt with by their IT admin. With TCP/IP connection, yes it is fast, however what is not known is how they port the data from Uplink to their receiver, which I suspect is POTS emulation, which would explain their comment to speed differences. I can't comment as far as to if they're really watching the heartbeat and their protocols for that, I don't deal with AR. I admin a customer's site with a Bosch D6200 receiver that is POTS, Connetix (IP) and we receive data ported from the Bosch cells directly from ATT into it. Virtually no difference in speed on any non-POTS comms route.
 
I've tested my own demo panel with an Uplink ported to my CS reciever directly and even on 2G the speed isn't much different than a straight TCP/IP connection via the XEP.  There can be comparable latency on either comms route. In my case, the only reason why I haven't standardized my port to the CS from Uplink is the testing and templating portion I'd have to do, not to mention, the majority of times I'd be doing it, it's easier to have the uplink be transparent to the CS instead of maintaining a pair of accounts...and typically duplicate charges.
 
A little bit off topic, but this item in the news today is an example of why I believe TCP/IP and/or VoIP is just not a reliable enough method for reporting alarm conditions.  Yep - I'm unfortunate enough to have TWC as my ISP.  I would only use them as a backup, and not as the primary means of reporting.
 
Yup; I've been able to configure one OPII panel with CC VOIP and while it works most of the time never really trusted it too much for the alarm panel. 
 
Concurrently have been using Verizon FIOS for another and I have noticed that the phone line quality sucks.  I did originally have a copper connection and they removed it when they installed the fiber connection.
 
I still have copper in the midwest and noticed that AT&T is putting fiber in our little subdivision.  I am wondering if they will replace my copper connection or leave it alone?
 
SteveInNorCal said:
Thanks. BTW, when I dial the "* * *" sequence, I immediately get a fast busy signal. I get fast busy signal with a "* *" sequence, too. I just tried and get the same results with the "#" key / DTMF tone.
 
Any thought on possible debugging? Have others succeeded using the Elk to answer with Comcast or other ISP VOIP systems? Sounds like Elk needs to chime in here.
I have CDV through Comcast and have it facing with my M1 with no issues. I have the rules set where if a zone is breached during an armed status the M1 calls my cellphone and states which zone has been violated. 
 
SteveInNorCal said:
Good afternoon, all. I'm wrapping up the installation of my Elk M1 Gold. Right now working on communications.
  1. I installed the XEP module and brought it up fine.
  2. I created a GMX email account for simple SMTP mail and am successfully getting emails and text messages from both the "Test" button and a rule that fires off a "heartbeat" email or text msg every hour (for now -- will reduce to 1/day). Thanks to all who contributed to earlier threads on email difficulties -- it was relatively painless with all the kind background help many members provided across many threads.
  3. I created a dynamic IP host address using Dyndns and that is working well after configuring my router.
  4. I just installed eKeypad on my iPhone 4s and brought it up ok. Nice app so far. It synced quickly, too, over port 2601. Able to bypass/arm/disarm and control lights. 
  5. I installed an Uplink 4500EZ GSM radio and also bought an AlarmRelay CS monitoring subscription.
This week I'll work with Alarm Relay to get CS comms running (primary over IP and backup over GSM).
 
Finally, on to my questions about communications...
  1. I was originally going to use my legacy POTS line to externally communicate to the M1, but we switched to Comcast for TV, Internet and voice, so I finally yanked out my 30 year old PacBell / AT&T copper line. Now that I've got solid IP communications and GSM communications, I'm wondering if I should just abandon putting the Elk on the Comcast phone line. Have others set up TRIPLE communications (Phone over IP, IP, and GSM)? The IP and GSM will communicate to the CS. I want to monitor the system remotely using phone over IP and the IP line. That seems like overkill, especially with eKeypad now running on my iPhone. But I can see cases where I could lose the iPhone and only have access to a regular phone. So it seems like this would be a nice, simple backup. What do you think?
  2. Here's the rub. I'm experiencing some Comcast phone difficulties that I haven't been able to solve. I set up the phone coms and was able to have the M1 make a call to my mobile using a simple rule that read me the time at 11:30 AM. But I am unable to go off hook and dial "***" to be able to send commands to the M1. Also, I can't get the Elk to answer incoming calls. I haven't yet tested dialing out based on alarm triggers, but that should work based on the success with the outbound call made via rules. Any ideas why "***" doesn't work and why the M1 won't pick up inbound calls? I'm dialing the "***" using our Panasonic cordless phone KX-TGE274S (DECT 6.0).
 
Sorry for the long-winded questions, but it seemed background was necessary. Any help would be greatly appreciated.

Steve
Sorry I read your OP better. My phone service doesn't inbound with the M1 with the intial "***". When I hear the busy signal I press the asterisks 3 more times and I can access the M1 that way. 
 
snesgenesis said:
I have CDV through Comcast and have it facing with my M1 with no issues. I have the rules set where if a zone is breached during an armed status the M1 calls my cellphone and states which zone has been violated. 
 
Thanks. Like you, my M1 will dial out to me no problem via Comcast Digital Voice (CDV?) using a simple test rule triggered by time of day ("make phone call at 11:30 AM"). I also set up another rule to send me an email when it detects the phone ringing and that works fine. 
 
I can't get the M1 to answer when I call it, however, on the internal phone using "* * *". I haven't tried an external line to see if it answers yet. That's for this weekend.
 
Does your M1 answer inbound calls properly? Does it answer if you use an in-house extension and dial the "* * *" sequence?
 
Back
Top