I am using Asterisk 11. About 1 out of 10 times my event codes from the alarm panel are missing either the last digit (checksum) and even more rarely the last 2 digits. That digit is instead replaced by the beginning of the same event code.
Ground Truth Event Code: 9999181110020005
== AlarmReceiver: Received Event 9999181110020009
== AlarmReceiver: Nonzero checksum
> AlarmReceiver: DTMF Digit Timeout on DAHDI/1-1
== AlarmReciever: Incomplete string: 999181110020005
Notice how the checksum (5) Shows up in the Incomplete string, but now the account number (9999) only has 3 letters. I am starting to think this is due to unclear DTMF tones from the alarm panel. Is there anyway to clean up the signal, or possibly make the tone last longer within asterisk? I am also aware that Asterisk 11’s AlarmReceiver is said to be broken. Why is that exactly? Do we know the reasons for this and I could possibly fix it? Thanks
EDIT: I ran DTMF debug and noticed a lot of tones were coming in very quickly, around 30-50 ms. So I’v gotten multiple debug messages that look like this:
[Aug 18 23:31:16] DTMF[5171][C-00000012]: channel.c:4191 __ast_read: DTMF end '9' has duration 39 but want minimum 80, emulating on DAHDI/1-1
[Aug 18 23:31:16] DTMF[5171][C-00000012]: channel.c:4292 __ast_read: DTMF end emulation of '9' queued on DAHDI/1-1
It say emulating on DAHDI/1-1, but I’m not sure what that means, is it emulating to a greater length?
Also, When a digit does not show up/replaced by the beginning of another even code, it never shows up in the DTMF debug, it simply is not being detected. Instead of a 5 being detected, it detects a 9. I’m starting to think the DTMF tones aren’t perfect everytime, and asterisk fails to pick them up sometimes, i suppose thats why alarm panels try multiple attempts at sending event codes. Is that the best guess?
Correct. Some channel drivers (such as DAHDI) only provide the core of Asterisk a DTMF end indication - in this case, with a very short duration. The core represents DTMF as having both a beginning and end, which requires us to reproduce the DTMF with both of those signals. The minimum duration that Asterisk will represent is 80ms, which means we extend that short duration DTMF to a slightly longer one.[quote=“supergeen, post:1, topic:67774”]
Also, When a digit does not show up/replaced by the beginning of another even code, it never shows up in the DTMF debug, it simply is not being detected. Instead of a 5 being detected, it detects a 9. I’m starting to think the DTMF tones aren’t perfect everytime, and asterisk fails to pick them up sometimes, i suppose thats why alarm panels try multiple attempts at sending event codes. Is that the best guess?
[/quote]
Based on what you’re seeing, that’s quite possible.
While I’m most definitely not a DAHDI expert, you may have some luck playing around with some settings in chan_dahdi.conf:
; How long generated tones (DTMF and MF) will be played on the channel
; (in milliseconds).
;
; This is a global, rather than a per-channel setting. It will not be
; updated on a reload.
;
;toneduration=100
...
; If you are having trouble with DTMF detection, you can relax the DTMF
; detection parameters. Relaxing them may make the DTMF detector more likely
; to have "talkoff" where DTMF is detected when it shouldn't be.
;
;relaxdtmf=yes
1 Like
Thanks, I’ve turned on relaxdtmf. Out of 25 alarms, the average number of attempts was 1.75, with a few taking up to 8 retires from the alarm panel. I was wondering what the big changes to alarm receiver were in asterisk 13 vs 11? I know more Ademco formats are supported, but would it have higher reliability, because I’m assuming the Industry Standard of failed alarm panel DTMF tones are very low.
Thanks again
You need to shorten mindtmfduration in asterisk.conf. I had the same issue with an Ademco Vista 20p, and set mindtmfduration = 20 to solve the issue.