Software DTMF /tone detection

Hi

Is it possible to do some software DTMF /Tone detection on an ARM (LPC21xx) ?

I need some links to existing code to implement this kind of DSP techniques. (i am no expert in DSP techniques ) if this type of controller can handle this.

Johan

Reply to
Sagaert Johan
Loading thread data ...

Hello Johan,

With ease. But that would be like going to the grocery store in a Ferrari Testarossa.

Go to TI's site and check the app notes for the MSP430. The one at the bottom of the list is from 1997 and shows how it's done. Includes generation as well. With an ARM you have a lot more horsepower so you could forego the coefficient stinginess the author was forced to do.

Regards, Joerg

formatting link

Reply to
Joerg

Here ya go ...

formatting link

--
Rich Webb   Norfolk, VA
Reply to
Rich Webb

It is certainly possible. 35 years ago I developed a DTMF detection system, with the intent of cramming it all into a single chip of the densities feasible in 1970. I did the development with a few cmos small scale chips (gates, 4 bit counters, etc) and a processor with about a 2 to 5 microsec execution time.

The analog section was a band-splitting filter and two Schmidt triggers, with their hysteresis levels controlled by the peak amplitude in the other channel (i.e. a single diode into a capacitor). This enforced the 20db? maximum level difference.

After that the processing was measuring periods in the two channels and accumulating a moving average. From this I could detect all tones, insert guard bands between tones, etc. The system was very reliable, in that it was extremely hard to induce false signal detection.

I described it at a meeting of the IEEE about 1971, and shortly after that had a violent disagreement with the firm. About two years later they wanted me to sign a patent application, which was illegal because over one year had passed since the publication, and I refused to sign.

As a result I have very little detailed memory of the system, and there are certainly no handy references. However, I can be hired to reinvent it :-)

--
"If you want to post a followup via groups.google.com, don't use
  the broken "Reply" link at the bottom of the article.  Click on
 Click to see the full signature
Reply to
Chuck F.

..but it's a Ferrari for less than 5 bucks.

--Gene

Reply to
Gene S. Berkowitz

Well I've never tried this, but I've heard from people who seem pretty knowledgeable about this that you can just count the zero crossings for a fixed period of time and get a pretty good idea of what button was being pressed. You may want to do a bit of analog filtering. Current standards require recognizing the tone within about 50 mSec. The trick I'm told is to require longer tone duration than that. If you are trying to decode machine generated dtmf signals this might not be a good technique, but if there's a human on the other end it might work fine. If there is some feedback to the user that the keypress was recognized, you could take a fairly long time to recognize it.

I've heard of folks implementing this technique on a pretty small PIC and getting it to work, so doing it on an ARM should be a breeze. And the math should be pretty simple :-)

Mark

Reply to
mhahn

Well I've never tried this, but I've heard from people who seem pretty knowledgeable about this that you can just count the zero crossings for a fixed period of time and get a pretty good idea of what button was being pressed. You may want to do a bit of analog filtering. Current standards require recognizing the tone within about 50 mSec. The trick I'm told is to require longer tone duration than that. If you are trying to decode machine generated dtmf signals this might not be a good technique, but if there's a human on the other end it might work fine. If there is some feedback to the user that the keypress was recognized, you could take a fairly long time to recognize it.

I've heard of folks implementing this technique on a pretty small PIC and getting it to work, so doing it on an ARM should be a breeze. And the math should be pretty simple :-)

Mark

Reply to
mhahn

The ARM is probably fast enough to do a FFT on a number of analog samples of the DTMF signal. It should then be easy to check at which frequencies the peak energy of the signal are.

Regards Anton Erasmus

Reply to
Anton Erasmus

Is that really computationally efficient ?

I would simply generate the I and Q waveforms for the eight (4+4) tones, multiply with the input waveform, square the result for each frequency, add them together (to get the magnitude) and perform some comparisons.

Paul

Reply to
Paul Keinanen

No, it is probably one of the most computationally inefficent algorithms, but the ARM is so fast that it is a viable algorithm. The advantage is, that one can probably decode a DTMF signal within a random audio signal. Or where the noise level is greater than the signal level. AFAICR a 1024 point 32-bit integer FFT takes a few 100 microseconds on a 60MHz ARM7.

Regards Anton Erasmus

Reply to
Anton Erasmus

You mean that version ( sorry text is in german, but pictures should be obvious ):

formatting link
It was said to run on a 4MHz Z80 decades ago. But getting it up on a 8MHz 68HC908 again has proven difficult.

As picture 5 shows during the integration phase there are only additions. Only on dumping ( every 20msec ) the contents of the partial accumulators are mulitplied and added to the main accumulator. That approach works only for coarse approximations of sin/cos but is suited to CPUs without MUL-opcode. Needs sufficient RAM.

The wellknown approximation for the magnitudes are also used:

formatting link

MfG JRD

Reply to
Rafael Deliano

This question is from a real beginner, so bear with me if it's a dumb question, but how does that method account for differences in phase between the sampled signal and the reference signal? Obviously, being out of phase will not cancel out the signal completely when you multiply, but is it easy to show that you won't in some cases guess the wrong frequency? In other words, is it easy to show that the worst case (phase that results in something that looks least like a match) for the right signal is still better than the best case for the wrong signals?

- Logan

Reply to
Logan Shaw

Multiplying with I and Q separately takes the sine and cosine components of the incoming wave separately. The relative values of the sine and cosine components contain the phase information. When the components are squared and then added, the phase components cancel out due to the well-known trigonometric equality, where sine squared + cosine squared = 1, independent of the angle for the sine and cosine (of course the same angle for both). This is essentially the aeons-old Pythagoras' equation.

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

look up the Goertzel Algorithm.

regards, DR

Reply to
Darcy

... snip ...

That may not be a good thing. There are specifications for the ratio of high to low tone level, and for the maximum noise level. Exceeding these can result in false positives, which may be even more disastrous than failure to decode.

--
"If you want to post a followup via groups.google.com, don't use
  the broken "Reply" link at the bottom of the article.  Click on
 Click to see the full signature
Reply to
Chuck F.

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.