On Tue, 10 Jan 2006 00:09:32 +0200, Paul Keinanen <keinanen@sci.fi> wrote:>On Mon, 09 Jan 2006 13:59:09 +0200, Anton Erasmus ><nobody@spam.prevent.net> wrote: > >>On Sat, 7 Jan 2006 01:48:46 +0100, "Sagaert Johan" <sagaert.j AT >>belgacom.net> wrote: >> >>>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. >>> >> >>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. > >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.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
Software DTMF /tone detection
Started by ●January 6, 2006
Reply by ●January 10, 20062006-01-10
Reply by ●January 10, 20062006-01-10
> 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.You mean that version ( sorry text is in german, but pictures should be obvious ): http://www.embeddedFORTH.de/dtmf.pdf 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: http://www.embeddedFORTH.de/quad.pdf MfG JRD
Reply by ●January 10, 20062006-01-10
Paul Keinanen wrote:> 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.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 by ●January 10, 20062006-01-10
Logan Shaw wrote:> Paul Keinanen wrote: > >> 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. > > > 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? > > - LoganMultiplying 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
Reply by ●January 10, 20062006-01-10
Anton Erasmus wrote:> On Sat, 7 Jan 2006 01:48:46 +0100, "Sagaert Johan" <sagaert.j AT > belgacom.net> wrote: > > >>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. >> > > > 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 > >look up the Goertzel Algorithm. regards, DR
Reply by ●January 10, 20062006-01-10
Anton Erasmus wrote:> <keinanen@sci.fi> wrote: >> Anton Erasmus <nobody@spam.prevent.net> wrote: >>... snip ...>>> >>> 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. >> >> 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. > > 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.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 "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: <http://cfaj.freeshell.org/google/>
