'DTMF Decode using 16C6x'
|At the prompting of a fellow PIClister, <subasekb.navy.mil>, I have FECDSI
some code which will perform the complement of the DTMF code generation
function, i.e. will listen for and decode DTMF tones.
Whether this is useful is another matter (since the proper decoder
chips leave little to be desired) however it was a fun exercise.
The code has, as usual, been verified using MPSIM. Unfortunately, my
version of MPSIM likes to reboot my machine if I feed it a stimulus file
longer than about 500 lines. This means that I couldn't completely
verify the code as written. On the other hand, I am confident that the
_algorithm_ is fairly robust. It works even in the presence of substantial
noise so long as the noise is not correlated with any of the 8 DTMF tones.
The tone is detected within about 150ms (I don't know the complete
spec, but I think tones are supposed to last for at least 200ms).
As before, email me _directly_ requesting a copy and I will send it.
One good thing about the algorithm is that it will even work with a 1-bit
ADC (i.e. comparator) providing that the low- and high-group tones do
not differ by more than 10% from each other. Whether this is useful
depends on how 'flat' the PSTN response is.
Since I don't trust the network to be flat within 1dB over 700-1700Hz,
I have implemented this using 8-bit samples. This is tolerant of
substantial variations of frequency response.
The routine does not provide some of the other facilities needed for
a real-world app. E.g. other code will need to determine whether a
tone is expected, and search for the proper pause between tones.
PS: Use this and the tone generator and you have yourself a 20bps modem!
Steve Hardy <SWENG.STORTEK.COM> writes about DTMF decoding: hardy
> The tone is detected within about 150ms (I don't know the complete
> spec, but I think tones are supposed to last for at least 200ms).
DTMF bursts are supposed to last 50 mS, and there is supposed to be at least
50 mS of silence between bursts. Receivers should detect bursts as brief as
|> From goonsquad.spies.com Fri Jun 14 14:02:16 1996 eric
> Steve Hardy <SWENG.STORTEK.COM> writes about DTMF decoding: hardy
> > The tone is detected within about 150ms (I don't know the complete
> > spec, but I think tones are supposed to last for at least 200ms).
> DTMF bursts are supposed to last 50 mS, and there is supposed to be at least
> 50 mS of silence between bursts. Receivers should detect bursts as brief as
> 30 mS.
This may be a problem >:^( I was looking at NatSemi's application note
AN521 - they make their tone generator output 100ms tones. My code
actually picks up the code in 76ms of sampling, however this was
repeated for reliability (making 152ms). Sorry folks, much too slow!
In practice most tone generators seem to generate a lot more than the
minimum required. Well, dammit, _my_ phone sounds a lot longer than
The code could be modified to sample for several tones at once instead
of the 8 sequentially. In theory, everything could be done sampling at
4*1633Hz for 10/697 seconds = 15ms (94 samples). This may be a better
approach but obviously requires a swag of registers to store the
complete sample set. My code uses just (?!) 17.
Would very much like a copy of the DTMF decoder code.
Attachment converted: wonderlandthree:WINMAIL.DAT (????/----) (000056D5)
I like to have a copy of your DTMF decoder code. I'm working in
20bps transmissions on phone lines (e.g. alarm systems), but the results
is not the best. The phone line in my country are so noises (that is...).
Thanks in advance,
P> Would very much like a copy of the DTMF decoder code.
For all interesting for DTMF decoding: this code is now accessible
on my PIC page:
It's also can be downoladed from ftp:
File is 60K long.
Alexej Vladimirov mail.ormix.riga.lv [Microchip technical support] avlad
--- GoldED/2 2.50+
'DTMF Decode using 16C6x'
Hi i was wondering what the current score is with the DTMF decoder
design i followed part of the thread but then had mail problems , is
there a working bit of code to play with ???
> From: PAUL B <G0TTS.DEMON.CO.UK> paul
> Hi i was wondering what the current score is with the DTMF decoder
> design i followed part of the thread but then had mail problems , is
> there a working bit of code to play with ???
> PAUL B
Paul, the code is available from:
http://www.ormix.riga.lv/eng/mchip/mchip.htm - PIC page
(Thanks to Alexej Vladimirov mail.ormix.riga.lv) avlad
Note that the decoder is not entirely satisfactory with respect to
the 'standards', but works if the tones last for over 150ms.
>Paul, the code is available from:
>http://www.ormix.riga.lv/eng/mchip/mchip.htm - PIC page
>(Thanks to Alexej Vladimirov mail.ormix.riga.lv) avlad
>Note that the decoder is not entirely satisfactory with respect to
>the 'standards', but works if the tones last for over 150ms.
So what is needed to sort this problem out for dtmf under 150 ms ?
|PAUL B wrote:
> >Note that the decoder is not entirely satisfactory with respect to
> >the 'standards', but works if the tones last for over 150ms.
> So what is needed to sort this problem out for dtmf under 150 ms ?
With Steve's approach you need a little more power than a PIC can deliver.
Those of you familiar with Analog Device's DSP's may recall this approach
implemented in an ADSP-2100 (see chapter 14 of the Digital Signal Processing
Applications). There they have 16 Goertzel algorithms running in parallel.
8 of them are tuned to the 8 DTMF tones while the other 8 are tuned to the
second harmonic of the DTMF tones. The idea is that if a DTMF signal is
present, then only two of the Goertzel outputs in the lower group of 8
(actually one in the first four and the other in the second four) will have
any significant output. The reason for looking at the second harmonic is to
differentiate DTMF signals (low in 2nd harmonic) from ordinary voice (higher
in 2nd harmonic).
[A Goertzel algorithm provides an efficient means of computing the Discrete
Fourier Transform of a signal.]
I have an idea that may make DTMF decoding possible with a PIC. In a message
to Steve I wrote:
> I've been thinking about this DTMF stuff a little. I must confess that I have
> little interest beyond the theoretical aspects. In other words, I've never
> built any hardware or written any software to encode or decode DTMF signals,
> but I like to mess around with signal processing and efficient algorithms.
> O.K. Having said that, I would like you to consider this idea. Suppose you
> at the zero crossing of the DTMF signals and attempted to perform the decoding
> based on the apriori knowledge of the 8 DTMF frequencies. The "zero-crossing"
> detector is a one-bit A to D converter, i.e. a comparator. (The 16C622 has two
> comparators.) The idea is to sample the comparator output and measure how long
> it takes for the signal to change states. The optimal sampling time and
> goes to zero when ever either the sine term or the cosine term goes to zero:
> d(t) = 0
> t = n / (fl + fh) n = 0, +/- 1, +/- 2, etc.
> t = (m + .5) / (fl - fh) m = 0, +/- 1, +/- 2, etc.
> (actually, the .5 is an artifact of the cosine. Since phase is not important,
> can be ignored. In other words, the .5/(fl-fh) causes a time shift in the zero
> The minimum zero crossing frequency is ~ 1209+697 = 1906, while the maximum
is[Steve, your message has an error right here ^^^^^^^^^^^^]
> 941+1633 = 2574. So the sampling time needs to be fast enough to catch 2574 Hz
> and perhaps slow enough to not overflow say an 8-bit variable counting the
> pulse width. So roughly speaking, you wouldn't want to sample any faster than
> or about 2 us.(Nor could you) My guess is that 10us is comfortable.
> Now for detection... If you look at the time spacing of the zero crossings of
> signals, you'll see something like so:
> W W W N N W W W N N W W W N N W W W N N W W W N
> where do to my impatience, I've abbreviate wide pulses with W and a narrow
ones with N.
> The number of wide pulses between narrow pulses is roughly (exactly, averaged
> the ratio of the sum and difference of the DTMF tones:
> fh + fl
> r ~ ---------
> fh - fl
> The width of the wide pulses is the spacing between zero crossings due to the
sum of the
> DTMF tones, while the spacing in time of the narrow pulses is due to their
> W ~ 1/(fh + fl)
> space between N's ~ 1/(fh - fl)
> The reason there are narrow pulses is due to the two frequencies beating
> way to look at it is there are certain integers m and n that can cause the
> gap to be decreased.
> As an example, suppose we were looking at key 1 (697,1209). The zero crossing
> occur at
> n/(1209 + 697) = 0, 525us, 1049us, 1574us, 2099us, 2623us, 3148us, 3673us,
> 5247us, 5771us, 6296us, ...
> m/(1209 - 697) = 0, 1953us, 3906us, 5859us, 7812us, 9765us, ...
> The pulse widths you would measure would be:
> 525, 524, 525, 379, 146, 524, 525, 525, 233, 291, ....
> W W W N N W W W N N
> So the wide pulses are ~525us, and there are three of them between the narrow
> The time between the occurrence of the narrow pulses is about
> 2099us, which is approximately 1953us (=1/[1209-697]). Now this is not
> by itself to be used as an identifier of the frequencies, but it could be used
> discriminator. Perhaps if you average several of these cycles the
> but I haven't investigated this.
> If you repeat this example for the other 15 keys, you start to see a pattern
> written a simple program in MATLAB to demonstrate this. (It's at home and not
at work so I
> can't append a copy of it). It will cycle through the 16 keys and show the
DTMF signal and
> the "digitized" waveform superimposed.
> Now for the tough part... So far I've assumed that the two tones have the same
> and that there is no noise. From a quick search on the WEB, I learned that
there could be
> up to three dB difference between the two. I emperically found with the MATLAB
> 6 db difference makes it extremely difficult to tell the difference between
two DTMF signals,
> but 3 db can be done.
> I assume that the noise floor is several db below the tones. In which case,
> hysterisis will "filter" it out. If it is not, then you have a problem. Also,
> distortion could also be detrimental. However, I doubt (i.e. guess) that there
are no even
> harmonics and that the odd harmonics are at most 1/n^2 (n = harmonic number)
> of the fundamental. (This is similar to the Fourier series of a triangle
> At any rate, I do not yet have an algorithm to efficiently pluck the DTMF
signals out of
> the acquired data.
And in a subsequent message I also wrote:
> I forgot to tell you one thing about sampling these pulses. It's possible to
miss a short
> pulse with the sampling scheme I described in the last message. This is
> certain conditions the short pulse is shorter than the sampling period. In
> you would see one really wide pulse inplace of two wide pulses seperated by a
> I think it's possible to recognize when this happens, so it probably is no big
The only reason I'm throwing this stuff out here is maybe someone else has
this approach and have either a) made it work or b) realize it's not possible.
Any ideas or
More... (looser matching)
- Last day of these posts
- In 1996
, 1997 only
- New search...