Searching \ for 'Simple, fully functional DTMF decoder' 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: 'Simple, fully functional DTMF decoder'.

Truncated match.
PICList Thread
'Simple, fully functional DTMF decoder'
1999\02\26@102905 by Andrew Russell Morris

flavicon
face
Some time ago there was a thread about DTMF decoders and one gentleman
stated that he had developed a fully functional DTMF
decoder that used an incredibly small amount of PIC processor resources. He
could not share the details with us because he
had done the work for his employer. I'm sure I know how he did it. I
stumbled on the trick quite by accident while testing
software I wrote for my employer. Since this knowledge is too important to
many PICLIST'ers to keep under my hat, and my
employer is not into telephone products, I'm going to share it with you. I
did a quick experiment to verify the concept
works, and writing the code would be easy, I just don't have the time right
now to work out the numbers related to the DTMF
frequencies. The trick can simultaneously detect any number of frequencies
in almost any amount of noise and interference
with an amazingly small amount of code. The secret is synchronous detection.

For those that don't know, let me first explain and give an example of
synchronous detection. A synchronous detector is a
device (hardware or software) that can detect a signal with a high degree
of noise immunity because it is synchronized
to the source of the signal allowing it to average out noise.

Lets say you had a photoelectric eye as a safety device that stopped a
machine if someone got too close to it. On one
side of the six foot access way to the machine is an LED emitting a beam of
infra-red light in a square wave (very
important) to the receiver 6 ft away. On the other side of the access way
is a receiver which contains a photodiode and
a very high gain amplifier that picked up the square wave from the emitter,
but also electrical and optical interference
from the motor drives of all the machines in the area and the mercury vapor
lights overhead. This interference would cause
the machine to shut down for no apparent reason. The synchronous detector
solves the problem because the square wave driving
the emitting LED also synchronizes the detector, finding the signal and
averaging out the (random) noise.

A synchronous detector works as follows: If a received signal is in phase
with the reference signal, a capacitor is charged
or a counter is incremented. If a signal is received which is out of phase
with the reference signal, a capacitor is dis-
charged or a counter is decremented by an equal amount. The noise, being
random, or just not in step with the reference,
will produce no average charge on the capacitor or count in the counter,
while the real signal will. The amount of noise
immunity is determined by the time constant of the capacitor or the number
of counts in a counter.

A synchronous detector can also be used as a frequency detector if the
number of counts or the time constant is not too long.
In my test, my software synchronous detector running a sample rate of 7KHz
@ 20 samples per test, with a trigger threshold
of 10 counts, would produce an output if an unsynchronized input signal
came within about 50Hz of 7KHz or a multiple thereof.
In a DTMF decoder, you will probably need a low pass filter to keep out
harmonics.

In a frequency detector, you won't be turning on and off an LED, so you
would just test the input and increment a counter
(once or a number of times, depending on required noise immunity and
processor speed) for a period of time each time a
high is seen. You would repeat the process for the same amount of time and
counts, only decrementing the counter each time
a high is seen. The cycle rate of incrementing and decrementing would be
the target trequency. The number of samples and the
trigger threshold (count) would set the bandwidth. Noise would be present
both during the incrementing and decrementing and
would be cancelled (averaged) out.

To similtaneously detect multiple frequencies, you would have one register
for each frequency to be detected, initialized at
the middle of their range. You would run the CPU like a state machine,
looking at the input and incrementing and decrementing
the appropriate registers according the CPU clock rate and the periods of
the various frequencies. After an appropriate
number of counts for the required bandwidth, you would look at each of the
registers and any register that was over the
threshold count would indicate that that particular frequency had been
detected. At this point, you know the rest.

The input to the PIC would be a comparator (no schmitt trigger) or high
gain amplifier like in TV/VCR remote receivers, which
would change state at the zero crossings, saturating with the signal and
clipping off noise. The summing of the two DTMF
frequencies would produce a stream of pulses in which square waves of the
two DTMF frequencies could be seen.

I would like to use this technique in a home project, but I don't have the
time right now to sit down and work out the
numbers related to the DTMF frequencies, although I have verified that the
trick will work. I would be grateful if someone
who does have the time and the need to work out the details would return
the favor and share his/her code with me. I won't
be using it in a commercial project since my employer is not into telephone
products. TTFN :-)

1999\02\26@122707 by John Payson

flavicon
face
|In a frequency detector, you won't be turning on and off an LED, so you
|would just test the input and increment a counter
|(once or a number of times, depending on required noise immunity and
|processor speed) for a period of time each time a
|high is seen. You would repeat the process for the same amount of time and
|counts, only decrementing the counter each time
|a high is seen. The cycle rate of incrementing and decrementing would be
|the target trequency. The number of samples and the
|trigger threshold (count) would set the bandwidth. Noise would be present
|both during the incrementing and decrementing and
|would be cancelled (averaged) out.

The problem you're apt to run into is that the phase of the input
signal is unknown.  Consequently, if you just use a single detector
you'll get a signal that may be anywhere from full-value positive
or full-value negative.

There are two ways around this problem:

[1] Use two or three dectors, whose phases are set either 90 or 120
   degrees apart, and use a suitable weighting function to combine
   their results.

[2] Use a reference frequency which is "off" by a known amount; this
   will cause the output of the detector to produce a wave whose
   frequency is the difference between the source and reference
   frequencies.

For DTMF dection, [1] is the way to go although most TV's and FM
radios use [2] in their tuning circuits.

1999\02\26@130235 by Harrison Cooper

flavicon
face
Also...for what its worth....Texas Instruments has a new micro, called the
MSP430 (I think), and there is an app note for decoding/encoding DTMF, and
includes source.  Didn't spend much time looking at it tho...

1999\02\26@134329 by Scott Dattalo

face
flavicon
face
On Fri, 26 Feb 1999, Andrew Russell Morris wrote:

> Some time ago there was a thread about DTMF decoders and one gentleman
> stated that he had developed a fully functional DTMF
> decoder that used an incredibly small amount of PIC processor resources. He
> could not share the details with us because he
> had done the work for his employer. I'm sure I know how he did it. I
> stumbled on the trick quite by accident while testing
> software I wrote for my employer. Since this knowledge is too important to

That somebody was probably me. But then again it may've been John Payson
too.

All of the details on HOW to decode dtmf signals is discussed from a
somewhat theoretically perspective on my web page:

http://www.interstice.com/~sdattalo/technical/theory/dtmf.html

But as I like to say, "in theory there's not much difference in theory and
practice, but in practice there is." Believe me, there are several tricks
necessary to implement this theory. And in fact, a robust design even
needs a little bit of extra (low-cost) hardware that's not discussed on
the web page.

I can't release the stuff I've written. However, I know that vertical
counters could be utilized to improve my algorithm. Right now, the
algorithm samples all 8 frequencies in an isochronous 84 instruction cycle
loop. I think the vertical counters can cut this down to 70 cycles (or
less).

Scott

1999\02\26@150646 by Engineering Department
flavicon
face
<Andrew Russell Morris wrote in part>

>Some time ago there was a thread about DTMF decoders and one gentleman
>stated that he had developed a fully functional DTMF
>decoder that used an incredibly small amount of PIC processor resources. He
>could not share the details with us because he
>had done the work for his employer. I'm sure I know how he did it. I
>stumbled on the trick quite by accident while testing
>software I wrote for my employer.

<snip>
I found the rest of this fascinating and well worth the band width.

But, either I missed something in the description or the author did.  How
does he
become synchronized with the input signal in the first place.  This
technique sounds like a halfway measure to implementing a phase locked loop
(PLL).  With a PLL you lock to the input signal and synthesize a copy of it
with the PLL VCO.  The VCO output is the synchronous signal used for
detection.  The noise immunity comes from the loop filter which is designed
to respond best to the desired input frequency.  Since DTMF tones are not
related harmonically you need a PLL for each tone.

It seems that the scheme actually ignores synchronization.  This doesn't
mean that it won't work though.  Assuming that the detector and source are
running at exactly the same frequency, the output level will depend on the
phase relationship between the two. The output could be zero if the
relationship is 180 degrees.  If the two frequencies are not identical, and
they probably aren't, then the output will beat at the difference.  This is
probably the signal he is actually detecting.  This also integrates to a
non-zero level, as in the synchronous case, but is dependent on the
capacitor time constant to attenuate out of band frequencies.  This will
probably work as long as there is a tuned RC filter for each of the DTMF
tones. Because of the beating there will need to be several cycles of input
and that means that the detection will be slower that is ultimately
possible.

Can anyone clear this up for me?

Thanks!

Win Wiencke
spam_OUTImageLogicTakeThisOuTspamibm.net

1999\02\26@212804 by Andrew Russell Morris

flavicon
face
Yes, the author will clear it up for you. The synchronous detector is is
only "synchronous" for a short period of time as the input frequency
is near, but not equal to the sample frequency. Only a certain number of
cycles of the input frequency will increment the counter. The "synchronous
detector" is not really being used as such in this case. By adjusting the
number of samples and the trigger threshold, you can adjust how close to
the sample frequency the input frequency must be in order to trigger the
detector. The low pass filter is the counter. You intentionally adjust the
"low pass filter" (and you can do it with hardware, too) so that the low
frequency beat between the sample and input frequencies will pass through
the filter. I've tested the concept with one test frequency and one
interfering frequency and it worked as I stated earlier. I see no reason
why it would not work with multiple frequencies. I will write the code
myself, test it and post it on the PICLIST as soon as I can find the time.

{Quote hidden}


'Simple, fully functional DTMF decoder'
1999\03\01@054501 by Graeme Smith
flavicon
face
Without getting into the DTMF stuff, which I have no experience with...

This Synchronous Scheme, sounds a bit like "Tuned Dendrites" so I can
comment safely, from my A.I. background ;)

Essentially, the idea, is that the "Period" of a waveform results in the
waveform PEAKING at certain times.

A counter, that "Counts" the Peaks in relation to a reference signal, is
therefore going to "Count" frequencies that are closer to the reference
signal with a higher value. This is because only those frequencies that
peak near to the reference will peak often enough to get as high a count.

While Higher frequencies, that are "Harmonics" of the original reference
will count as high as the base frequency, using a slightly off frequency
reference, will actually create TWO detectable frequencies, the frequency
of the signal being measured, and the "BEAT" frequency that is the result
of the reference, and the measured frequency, "Interfering" with each
other.

Because higher "Harmonics" have higher beat frequencies, it is possible
to use a slightly off-frequency signal, to detect whether or not the
signal being measured is the frequency required, or some harmonic of it.

Implimentation is pretty reasonable, if you can do the math, to figure out
the period of a particular waveform, then you set your timer to sample
that waveform every so many cycles. If you take two samples a set distance
apart, every so many periods, then the difference between the samples,
will create your beat frequency, which can then be used with a signal
generator, to calibrate the desired beat frequency, in terms of how many
beats on average to expect in the second sample. When both samples match,
your signal is likely to be the correct frequency.

You probably want to use a "Fuzzy" testing proceedure, in order not to
reject signals that are "Close enough" to be merely suffering from noise,
but, this is almost a software PLL in that as long as your signal is
slower than the sample frequency by some margin, you can have fairly good
assurance that the signal once synchronized is not going to drift off
frequency without being detected.

                               GREY

GRAEME SMITH                         email: grysmithspamKILLspamfreenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.

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