DTMF interdigit and duration timing

App_rpt-users
1

I’ve looked through the entire Wiki and even grep’d all the conf files for an answer about this and I have not found a method that changes the tone duration nor the interdigit timing either. I searched the forum and notice this question has been asked multiple times over the years but the questions never receive a response. I’m hopeful this thread doesn’t suffer a similar fate :nauseated_face:

I suspect it is only configurable in the source? If this is case, I would respectfully suggest these parameters should be easily configurable in a conf file somewhere.

2

Your suspicion is correct. But it would take one heck of a coder to change that. I suspect DTMF decoding is done deep inside Asterisk. Remember Allstar is app_rpt running on the Asterisk PBX.

If you are having trouble decoding DTMF that are two things to make sure are correct; de-emphasis and CTCSS filtering. I’ve found the later to be a common problem. Be sure to turn on the PL filter and do it in the radio if possible.

3

The issue for me isn’t decoding of the digits but rather the amount of time required to send a substantial number of digits. There is simply no reason the timing needs to be as long as it is by default (under most circumstances)

4

DTMF decoding is pretty darn fast. What sort of timing are you seeing?

Can you use a macro function for your application?

5

I’m referring to encoding not decoding. It seems that (for example)

asterisk -rx ‘rpt cmd 1100 cop 48 1,2,3’

I haven’t actually measured the timing but it sounds to be around 100 ms with 100 ms interdigit time. A decent quality link can easily deal with half that amount of time

6

As for using a macro function, no I cannot as the data to be sent will be done via a cronjob and the digits sent will vary

7

I’m under the impression COP 48 uses Motorola tone format, standard Motorola rate is 250ms tone, 250ms space. If you are seeing 100ms for each, then it is faster than standard Motorola. I believe the federal standard is 35ms and 5ms respectively, so theoretically it could be faster; depending on implementation.

Bob
K6ECM

8

Well… I was going by ear - as I said I hadn’t actually measured the time (my sense of time appears to be less than accurate!)

Either way, it’s too long but if it can’t be changed, it can’t be changed. Perhaps one of the developers will take pity and decide to attack it :smiley:

9

My question is How many digits are you trying to send that you can’t enter it in manually or thru a script? you say that your trying to enter a long list of digits but never say what your doing. I have never had a problem programming Allstar even from a keypad on a radio. Please tell us what your trying to accomplish

10

Actually what I’m doing is quite simple but I need to set a clock and calendar on a controller at a remote site (done by a bash script, called by a cronjob). Obviously the digits sent are going to change all the time and will consist of 2 sequences sent, each 12 digits long.

I know I know… 24 digits aren’t that bad and I don’t disagree. All things being equal, 500 ms needed for each digit seems a bit much to me, that’s all…

11

This is from an early version of “app_rpt” now known as ASL

/usr/src/astsrc/asterisk/main/channel.c

/*! Default amount of time to use when emulating a digit as a begin and end

  • 100ms */
    #define AST_DEFAULT_EMULATE_DTMF_DURATION 100

/*! Minimum allowed digit length - 80ms */
#define AST_MIN_DTMF_DURATION 80

/*! Minimum amount of time between the end of the last digit and the beginning

  • of a new one - 45ms */
    #define AST_MIN_DTMF_GAP 45

GL
Ken

12

I suspect those constants are part of DTMF decoding. The OP wants to increase the DTMF sending speed.

13

dunno

Google found this from a question where the poster wanted to slow down the DTMF speed. He modified this same routine but in a different place - by adding an additional wait period between the start and stop of tone generation
.
anyway - this would seem to be where DTMF is handled.

Ken