> <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/>
Reply by Darcy●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 Tauno Voipio●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?
>
> - Logan
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
Reply by Logan Shaw●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 Rafael Deliano●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 Anton Erasmus●January 10, 20062006-01-10
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
Reply by Paul Keinanen●January 9, 20062006-01-09
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.
Paul
Reply by Anton Erasmus●January 9, 20062006-01-09
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
Reply by ●January 8, 20062006-01-08
Sagaert Johan 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.
>
> Johan
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 by ●January 8, 20062006-01-08
Sagaert Johan 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.
>
> Johan
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