Searching \ for 'DTMF Decoding with a PIC' 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 Decoding with a PIC'.

Truncated match.
PICList Thread
'DTMF Decoding with a PIC'
2000\05\18@094442 by Andy Kelley N1YEW

picon face
Hi,

I have a weird idea on how to decode dtmf tones.  It may work but then again it may not.

1. sample a tone to record it (@ 4kc sample rate or something).
2. then store it.  
3. then compare it to 'known' samples (samples taken during calibration of pic/eeprom with identification(1,2,3,4,5, etc).
4. if it does not match rotate the bits and try again going to step 3 until we get a match(or until we run out of samples)
5. return with the tone number(1,2,3,4,5,etc) in W.

Think this will work or is it just a foolish idea?


CYA!
Andy K.

Amateur Radio Callsign: N1YEW

2000\05\18@100237 by Scott Dattalo

face
flavicon
face
On Thu, 4 May 2000, Andy Kelley N1YEW wrote:

> Hi,
>
> I have a weird idea on how to decode dtmf tones.  It may work but then again it may not.
>
> 1. sample a tone to record it (@ 4kc sample rate or something). 2. then
> store it.  3. then compare it to 'known' samples (samples taken during
> calibration of pic/eeprom with identification(1,2,3,4,5, etc). 4. if it does
> not match rotate the bits and try again going to step 3 until we get a
> match(or until we run out of samples) 5. return with the tone
> number(1,2,3,4,5,etc) in W.
>
> Think this will work or is it just a foolish idea?


There are a few problems with this approach. The most significant is that you're
not continuously sampling. Thus during your processing, a DTMF tone may be
coming in and you'll miss it. Another problem is ensuring that the sample window
is not a DTMF boundary. Another problem is phase shifting between the sampled
tone and the recorded tone. How are you going to align or correlate the two
signals/

If you care to see a technique that DOES work, then checkout:

http://www.dattalo.com/technical/theory/dtmf.html

I haven't publicly released the code to do this... But apparently scenix has
copied this decoding technique and has released the code.

Scott

2000\05\18@102443 by Dave McLaughlin

flavicon
face
Why not just use an off the shelf IC to do the job. Much cheaper (software
time is expensive)
and all the hardwork is done for you including a valid tone signal and
binary output direct to
the PIC. I originally used a bank of 556's to do the job until I discovered
a single chip to
do the job. I know have a drawer full of them for all my intended, never get
done jobs I wanted
to build.

Regards
Da\/e...

{Original Message removed}

2000\05\18@110901 by Jim Hartmann

flavicon
face
I once wrote an autocorrelating DTMF decoder that worked pretty well.  It
worked very well in the presence of noise but it worked poorly when there
was significant twist in the signal (one of the tones higher amplitude than
the other).  I correlated a zero crossing input against two tone references
in real time, 8khz sample rate, taking one row and one column of the DTMF
tones at a time, and 0 and 90 degree phase shifts of each tone.  If
interested I can send more details.

:-Jim





Scott Dattalo <spam_OUTscottTakeThisOuTspamDATTALO.COM>TakeThisOuTspamMITVMA.MIT.EDU> on 05/18/2000 08:59:21 AM

Please respond to pic microcontroller discussion list
     <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>

Sent by:  pic microcontroller discussion list <PICLISTspamKILLspamMITVMA.MIT.EDU>


To:   .....PICLISTKILLspamspam.....MITVMA.MIT.EDU
cc:
Subject:  Re: DTMF Decoding with a PIC


On Thu, 4 May 2000, Andy Kelley N1YEW wrote:

> Hi,
>
> I have a weird idea on how to decode dtmf tones.  It may work but then
again it may not.
>
> 1. sample a tone to record it (@ 4kc sample rate or something). 2. then
> store it.  3. then compare it to 'known' samples (samples taken during
> calibration of pic/eeprom with identification(1,2,3,4,5, etc). 4. if it
does
> not match rotate the bits and try again going to step 3 until we get a
> match(or until we run out of samples) 5. return with the tone
> number(1,2,3,4,5,etc) in W.
>
> Think this will work or is it just a foolish idea?


There are a few problems with this approach. The most significant is that
you're
not continuously sampling. Thus during your processing, a DTMF tone may be
coming in and you'll miss it. Another problem is ensuring that the sample
window
is not a DTMF boundary. Another problem is phase shifting between the
sampled
tone and the recorded tone. How are you going to align or correlate the two
signals/

If you care to see a technique that DOES work, then checkout:

http://www.dattalo.com/technical/theory/dtmf.html

I haven't publicly released the code to do this... But apparently scenix
has
copied this decoding technique and has released the code.

Scott

2000\05\19@124244 by Josh Koffman

flavicon
face
Jim Hartmann wrote:
>
> I once wrote an autocorrelating DTMF decoder that worked pretty well.  It
> worked very well in the presence of noise but it worked poorly when there
> was significant twist in the signal (one of the tones higher amplitude than
> the other).  I correlated a zero crossing input against two tone references
> in real time, 8khz sample rate, taking one row and one column of the DTMF
> tones at a time, and 0 and 90 degree phase shifts of each tone.  If
> interested I can send more details.
>
> :-Jim

Jim,
I'd be interested in some more details of this.
TIA
Josh Koffman
EraseMEjoshyspam_OUTspamTakeThisOuTmb.sympatico.ca

2000\05\20@083910 by Russell McMahon

picon face
Just a thought -

The fact that the original software worked poorly where there was an
amplitude difference in the two tones suggests that the higher amplitude
tone predominated in its control of the zero crossing points (makes sense).

Just maybe you could improve results with two zero crossing inputs with a
high pass and low pass filter feeding each. As the tone pairs are in two
frequency groups one input would be biased towards detecting zero crossings
in each group. The filters' cross-over point would be intermediate between
the two tone groups. The hardware for this would be very simple - possibly
as simple as two RC networks and at worst a one transistor low pass and high
pass 2 pole filter. Also a second zero crossing detector. Still a fairly
minimal hardware solution.


     Russell McMahon


{Original Message removed}

2000\05\20@093345 by Scott Dattalo

face
flavicon
face
On Sat, 20 May 2000, Russell McMahon wrote:

> Just a thought -
>
> The fact that the original software worked poorly where there was an
> amplitude difference in the two tones suggests that the higher amplitude
> tone predominated in its control of the zero crossing points (makes sense).
>
> Just maybe you could improve results with two zero crossing inputs with a
> high pass and low pass filter feeding each. As the tone pairs are in two
> frequency groups one input would be biased towards detecting zero crossings
> in each group. The filters' cross-over point would be intermediate between
> the two tone groups. The hardware for this would be very simple - possibly
> as simple as two RC networks and at worst a one transistor low pass and high
> pass 2 pole filter. Also a second zero crossing detector. Still a fairly
> minimal hardware solution.


Precisely! The caveat is that now your signal has been split in two - a high and
a low frequency portion. This means that the algorithm (at least my version of
it) has to run twice. Btw, for an extra cap, you can get a third order filter.
In other words, one opamp is sufficient for a third order filter. Two opamps can
give you a 5'th. A quad opamp can give you a 5th order low-pass and a 5th order
high pass. The quality of the opamp doesn't have to be too good either.

There other factors to consider as well. For example, if you wish to remove the
dial tone too, then a third order high pass elliptic file with a pole at 440hz
can be implemented. Also, if you wish to avoid aliasing then you also have to
consider filtering out high frequencies as well. For my case (whose details I
can't fully disclose), I used a combination of these analog techniques. And
guess what, it STILL isn't 100% (when you take into account the full
specification which specifies the dynamic range of the incoming signals, their
twist, and the relative strength of "noise" (e.g. voices) present. But, there is
one more really simple analog trick that I'll dangle out there for you to
ponder, but I can't tell. But it's so non-obvious that even if I did tell, you
wouldn't believe! But a couple of LM324's with a handful of resistors and
capacitors and of course a pic can perform wonderfully.

I'd still recommend that you use a dedicated DTMF decoder unless you're trying
to minimize cost. Designing a robust decoder using the techniques I describe
(and hint at) is not trivial.

Scott

2000\05\22@093420 by pandersn

flavicon
face
Why not just equalize the amplitude on the two tones; that is, give the higher tones a boost?

Phil.

On Friday, May 19, 2000 6:50 PM, Russell McMahon [SMTP:apptechspamspam_OUTCLEAR.NET.NZ] wrote:
{Quote hidden}

> {Original Message removed}

2000\05\22@095510 by Scott Dattalo
face
flavicon
face
On Mon, 22 May 2000, Phil Anderson wrote:

> Why not just equalize the amplitude on the two tones; that is, give the higher tones a boost?

Because they're mixed together like cream and sugar in a cup of coffee. If you
know apriori which is too low, then the detection is mostly done.

But, you have stumbled upon one detection method that can be used. For example,
suppose you could generate an analog signal that can be combined with the DTMF
signal so that the detection can be improved. What should that signal look
like? What kind of optimizations can you make? The assumption with these
zero-crossing methods is that no A/D converter is necessary - all you need is a
comparator to detect the zero crossings. Now, if you make use of simple D/A
comparator like a filtered PWM wave or perhaps a magic sine wave, then I suspect
there's an algorithm lurking around to make the detection easier.

Scott

2000\05\22@123856 by Jim Hartmann

flavicon
face
After achieving success with this several years ago in the end I
reluctantly agreed that it is probably more practical to use a decoder
chip, partly because the hardware was done and we had only one zero
crossing input, and partly because of the processing load.  I also agree
that splitting the signal into two bands would solve the twist problem and
would also simplify the code.

I will post my code soon.  It was originally written in assembly for a 6809
then translated and improved for a 16 bit mitsubishi 7700 and that's where
it stands.

:-Jim

2000\05\22@174322 by Plunkett, Dennis

flavicon
face
Yes there is!
Consider the single bit processing method, where the input goes through a
delta stage to reduce the amplitude, and is then passed into a simple
comparator. The output the is PDM, and simple to work with, in fact the
muliplications can be done in hardware with a simple not exor gate setup,
hey, full DSP in a FPGA!

Dennis

> {Original Message removed}

2000\05\23@143723 by Peter L. Peres

picon face
Hi,

Just a thought: How complicated would it be to implement a sigma-delta
converter using the PIC itself, an analog switch and the preamp comparator
? I think that the 2 component frequencies can be detected easier from the
differential of the signal envelope (which is the output of the
sigma-delta) than from zero crossings. Perhaps without Fourier. If there
would be enough time, then the PIC could manipulate the switch to cancel
out one of the frequencies and detect the other by period measurement. I
mean, a sigma-delta whose sample & zero frequency would be varied in
suitable ways. Maybe using the differential AND the zero crossings would
yield a better starting data set.

I suspect that Scott Dattalo or someone else could see some
scheme in this, if there would be one ;-)

Peter

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