[comp.dcom.telecom] Touchtone Detection Question

Glenn M Cooley <gmc@wisvr.att.com> (08/03/90)

Some/most systems I've come across which have you enter data through
TT are able to correctly decode my input, long pulses, short pulses,
quick pulses, Bell phones, non-Bell phones.  Other systems, such as
various answering machines are very fickle.  I have to master a
certain pressing technique and can only use certain phones (non-PBX
Bell phones are the best) and still need to use several tries.

Why/comments/etc?

mark kallas <mkallas@digi.lonestar.org> (08/05/90)

In article <10356@accuvax.nwu.edu> gmc@wisvr.att.com (Glenn M Cooley)
writes:

>Some/most systems I've come across which have you enter data through
>TT are able to correctly decode my input, long pulses, short pulses,
>quick pulses, Bell phones, non-Bell phones.  Other systems, such as
>various answering machines are very fickle.  I have to master a
>certain pressing technique and can only use certain phones (non-PBX
>Bell phones are the best) and still need to use several tries.

>Why/comments/etc?

Most of the time answering machines and some voice mail systems
require a two or three second holding time before they will decode an
incoming digit. If I remember right minimum duration for DFMT (TT) is
100 msec, I would guess the average persons button pushing is 200-500
msec. This means the dialer has to hold the button down "a long time".

A second reason PBX may not work is if they are digital instruments.
Digital phones do not have a DTMF send in them, so when a buttom is
pressed the PBX "sees" the botton and then send a digit to whoever
your conected to. These tones are saved in digital form and used to
send digits to the cental office. Most of the time these digits are
only sent for 100 msec.

A third reason some regular (cheap) phones will not sometimes is due
to reverse current. When a phone being dialed, it gets it power, -48
volts from the central office.  Many central offices will reverse
polarity, making + 48 volts, after your call is answered. This is most
often used to tell when billing sould start. On the other hand, if the
phone you using to dial out on will only let you send digits when it
has -48 volts, it won't after the call is answered.


UUCP    : texbell!digi!mkallas
Internet: mkallas@digi.lonestar.org

tad@beaver.cs.washington.edu> (08/09/90)

In article <10356@accuvax.nwu.edu>, gmc@wisvr.att.com (Glenn M Cooley)
writes:

> Some/most systems I've come across which have you enter data through
> TT are able to correctly decode my input, long pulses, short pulses,
> quick pulses, Bell phones, non-Bell phones.  Other systems, such as
> various answering machines are very fickle.  I have to master a
> certain pressing technique and can only use certain phones (non-PBX
> Bell phones are the best) and still need to use several tries.

> Why/comments/etc?

One of the problems with designing a good quality DTMF receiver is
insuring talk-off (falsing) immunity.  Talk-off is when the receiver
falsely detects a digit due to non-DTMF audio ... such as when you are
dialing the payphone in the bar next to the jukebox.  If music is
playing (or you are talking) and it produces a momentary condition
where two frequencies exist within the bandpass for the tones, a tone
receiver could detect the false digit.

One way to make this less likely is the make the tone acceptance
bandwidth for each tone tighter.  Another way is to make the "twist"
acceptance (the difference in level between the high and low tone)
more restrictive.

If you do this, you can have another problem ... some phones may not
be able to signal your receiver.  This makes DTMF receiver design
tricky.

If you are building an answering machine with a really cheap DTMF
receiver (maybe just some filters to detect a couple of digits) one
way to prevent false digit detection would be to lengthen the time
required for detection.  Good DTMF receivers detect tones down to 40
ms, with 40 ms interdigit time.  If you lengthen this to 500 ms, you
will "never" get falsing, as the chances of the two tones being
present in speech or on the jukebox for a half second is remote.


Tad Cook   Seattle, WA   Packet: KT7H @ N7HFZ.WA.USA.NA  Phone: 206/527-4089 
MCI Mail: 3288544   Telex: 6503288544 MCI UW  
USENET:...uw-beaver!sumax!amc-gw!ssc!tad   or,  tad@ssc.UUCP

JDurand@cup.portal.com (08/10/90)

In article <10356@accuvax.nwu.edu>, gmc@wisvr.att.com (Glenn M Cooley)
writes:

> Some/most systems I've come across which have you enter data through
> TT are able to correctly decode my input, long pulses, short pulses,
> quick pulses, Bell phones, non-Bell phones.  Other systems, such as
> various answering machines are very fickle.  I have to master a
> certain pressing technique and can only use certain phones (non-PBX
> Bell phones are the best) and still need to use several tries.

> Why/comments/etc?

The two problems with detecting tones are that you are not allowed to
detect a digit when none is present _AND_ you may not miss or mis-read
a digit that is present no matter what the customer puts on the line
(a lot of my voice-mail boards have been used in 976-xxxx applications
with all sorts of music playing over voice!).  This is NOT easy.  The
boards I am currently working on use a DSP (Digital Signal Processor
[special fast computer]) to first equalize the line, apply auto gain
control, and remove any correlation in the incoming audio to the
outgoing program.  After you do all this, then you use very good
filters and a voting scheme between different methods of detecting the
tone.  This generally works fairly well.
 
In low cost equipment (less than the cost of the DSP alone), a
hardware chip that was designed for central office use is used.  In a
typical call into a central office, there is never any outgoing
program, the only sounds on the line are static and the tones (your
phone is supposed to turn off the mic when you press a button).  If
these chips hear anything other than the pure tone and dialtone, they
assume you are talking and not pressing a button and disable
detection.

I hope this helps.


Jerry Durand, Durand Interstellar, Inc., jdurand@cup.portal.com