Searching \ for 'DTMF Decode using 16C6x' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/pots/dtmf.htm?key=dtmf
Search entire site for: 'DTMF Decode using 16C6x'.

Truncated match.
PICList Thread
'DTMF Decode using 16C6x'
1996\06\13@212748 by Steve Hardy

flavicon
face
At the prompting of a fellow PIClister, <spam_OUTFECDSITakeThisOuTspamsubasekb.navy.mil>, I have
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.

Regards,
SJH
Canberra, Australia

PS: Use this and the tone generator and you have yourself a 20bps modem!

1996\06\13@235911 by Eric Smith

flavicon
face
Steve Hardy <.....hardyKILLspamspam@spam@SWENG.STORTEK.COM> writes about DTMF decoding:

> 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.

Eric

1996\06\14@004104 by Steve Hardy

flavicon
face
> From ericspamKILLspamgoonsquad.spies.com Fri Jun 14 14:02:16 1996
>
> Steve Hardy <.....hardyKILLspamspam.....SWENG.STORTEK.COM> writes about DTMF decoding:
>
> > 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.
>
> Eric
>

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
50ms!

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.

Regards,
SJH

1996\06\15@140812 by Steve Childress

flavicon
face
Would very much like a copy of the DTMF decoder code.
TIA
EraseMEstevecspam_OUTspamTakeThisOuTrain.org




Attachment converted: wonderlandthree:WINMAIL.DAT (????/----) (000056D5)

1996\06\17@060425 by Daniel Henzulea

flavicon
face
       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,

               Daniel.

1996\06\17@114632 by Alexej Vladimirov

flavicon
face
Hello PICers!

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:
http://www.ormix.riga.lv/eng/mchip/mchip.htm

It's also can be downoladed from ftp:
ftp://ftp.ormix.riga.lv/mchip/sources/dtmf_dec.zip
File is 60K long.

Alexej Vladimirov  avladspamspam_OUTmail.ormix.riga.lv  [Microchip technical support]

--- GoldED/2 2.50+


'DTMF Decode using 16C6x'
1996\07\10@222445 by PAUL B
flavicon
picon face
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

1996\07\10@223513 by Steve Hardy

flavicon
face
> From: PAUL B <@spam@paulKILLspamspamG0TTS.DEMON.CO.UK>
>
> 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
ftp://ftp.ormix.riga.lv/mchip/sources/dtmf_dec.zip
ftp://ftp.ormix.riga.lv/mchip/sources/dtmf_cod.zip

(Thanks to Alexej Vladimirov  KILLspamavladKILLspamspammail.ormix.riga.lv)

Note that the decoder is not entirely satisfactory with respect to
the 'standards', but works if the tones last for over 150ms.

Regards,
SJH

1996\07\11@153612 by PAUL B

flavicon
picon face
>
>Paul, the code is available from:
>
>http://www.ormix.riga.lv/eng/mchip/mchip.htm - PIC page
>ftp://ftp.ormix.riga.lv/mchip/sources/dtmf_dec.zip
>ftp://ftp.ormix.riga.lv/mchip/sources/dtmf_cod.zip
>
>(Thanks to Alexej Vladimirov  RemoveMEavladTakeThisOuTspammail.ormix.riga.lv)
>
>Note that the decoder is not entirely satisfactory with respect to
>the 'standards', but works if the tones last for over 150ms.
>
>Regards,
>SJH

So what is needed to sort this problem out for dtmf under 150 ms ?

--
PAUL B

1996\07\11@170933 by Scott Dattalo

face
flavicon
face
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.
> >
> >Regards,
> >SJH
>
> So what is needed to sort this problem out for dtmf under 150 ms ?
>

Paul,

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:

> Steve,
>
> 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
looked
> 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
criteria
{Quote hidden}

d(t)
> goes to zero when ever either the sine term or the cosine term goes to zero:
>
> d(t) = 0
> when
>   t = n / (fl + fh)       n = 0, +/- 1, +/- 2, etc.
> OR
>   t = (m + .5) / (fl - fh)       m = 0, +/- 1, +/- 2, etc.
>
> (actually, the .5 is an artifact of the cosine. Since phase is not important,
the .5
> can be ignored. In other words, the .5/(fl-fh) causes a time shift in the zero
crossings.)
>
> 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
signal
> and perhaps slow enough to not overflow say an 8-bit variable counting the
1906 Hz
> pulse width. So roughly speaking, you wouldn't want to sample any faster than
1/1906/256
> 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
the DTMF
> 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
over time)
> 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
difference.
>
> W ~ 1/(fh + fl)
> space between N's ~ 1/(fh - fl)
>
> The reason there are narrow pulses is due to the two frequencies beating
together. Another
> way to look at it is there are certain integers m and n that can cause the
zero crossing
> gap to be decreased.
>
> As an example, suppose we were looking at key 1 (697,1209). The zero crossing
points
> occur at
>  n/(1209 + 697) = 0, 525us, 1049us, 1574us, 2099us, 2623us, 3148us, 3673us,
4197us, 4722us,
>                   5247us,  5771us, 6296us, ...
> and
>  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
pulses.
>
> The time between the occurrence of the narrow pulses is about
379+146+524+525+525 or
> 2099us, which is approximately 1953us (=1/[1209-697]). Now this is not
accurate enough
> by itself to be used as an identifier of the frequencies, but it could be used
as a
> discriminator. Perhaps if you average several of these cycles the
approximation improves,
> but I haven't investigated this.
>
> If you repeat this example for the other 15 keys, you start to see a pattern
develop. I've
> 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
amplitude
> 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
program that
> 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,
the comparator
> hysterisis will "filter" it out. If it is not, then you have a problem. Also,
harmonic
> 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)
the amplitude
> of the fundamental. (This is similar to the Fourier series of a triangle
wave.)
>
> 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
because under
> certain conditions the short pulse is shorter than the sampling period. In
this case,
> you would see one really wide pulse inplace of two wide pulses seperated by a
narrow one.
> I think it's possible to recognize when this happens, so it probably is no big
deal.
>

The only reason I'm throwing this stuff out here is maybe someone else has
already attempted
this approach and have either a) made it work or b) realize it's not possible.
Any ideas or
feedback?


Scott

More... (looser matching)
- Last day of these posts
- In 1996 , 1997 only
- Today
- New search...