[Asterisk-bsd] DTMF decode on Asterisk under FreeBSD, update

[Andy Valencia]

---------------
(Re-sent; I don't think it got through for some reason.)

Hi, folks.

This note is more so it can be archived and indexed for future Google-ing.
But maybe it'll help somebody already on the list.

I had trouble with a link to my 6M ham repeater's autopatch facility.  When
I plugged a plain old VoIP telephone adaptor onto the repeater, all was
well.  Same with a POTS line from the phone company.  But when hooked to a
Wildcard, DTMF decode was poor to non-existent.  I asked here, and never got
any response on the issue.

But you gotta love open source.  I spent a little effort on it on and off
when time permitted, and found that although the Wildcard has a DSP with
DTMF decode, it's not used; the DTMF processing is soft, up in the Asterisk
process.  That's actually good news, because I added instrumentation to the
decode process, dumping it to a trace file in /tmp.  Then I had a little
dump program which would format this after the fact, letting me see what was
happening during the (attempted) decode.

Bottom line from the trace was that, for the kinds of signal levels coming
from my autopatch, DTMF_TO_TOTAL_ENERGY was quite a bit too high.  I
empirically determined that the default value of 42.0 should be tweaked down
to perhaps as low as 35.0.

There was already a compile option RADIO_RELAX, and a "relaxdtmf" option in
the zapata.conf file.  These didn't fix the problem for me, but they
provided a nice hook for me to add my own fix.  I added a conditional
modification of the DTMF_TO_TOTAL_ENERGY value under the same "relaxdtmf"
option, and bingo!  DTMF seems to be working fine.

I'll live with it for a while, see if I have problems with false decodes or
what-not.  Maybe I'll bring the value up a little, because there are a
couple layers to the logic in DTMF decoding to defend against scratchy DTMF
input anyway.  Then I guess I'll submit it for consideration in the Asterisk
source.

Regards,
Andy Valencia