DSPRelated.com
Forums

Magnitude by summing |I| & |Q|

Started by Thomas Magma September 3, 2008
Thomas Magma wrote:
> Hello, > > I'm trying to write a very efficient and fast detection algorithm for a > dsPIC. I've already been down the path of the Goertzel and have dismissed it > because of it's use of floating point numbers. I am now using a modified DFT > and would like to get rid of the square root algorithm that calculates the > magnitude of I & Q. It seems to me that simply summing (the accumulated) I > & Q channels it will give you a cheap and dirty indication of gain. Summing > their absolute values, that is. Does anyone see anything wrong with this? > Are there any draw backs of doing this?
How will you get |I| and |Q|? You want not their sum, but sqrt(I^2+Q^2). That can be approximated fairly well by MAX(I,Q) + .25*MIN(I,Q). You can find better approximations at http://dspguru.com/ Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Thomas Magma wrote:

   ...

> OK point well taken, I did the math. But if everyone went ahead and figured > out the answers on their own, there would be no more newsgroups and you > would have too much time on your hands.
I had thought better of you. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
langwadt@fonz.dk wrote:

   ...

> -Lasse
You've been gone a long time. Nice to hear from you! Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
On Wed, 03 Sep 2008 22:48:07 -0400, Jerry Avins <jya@ieee.org> wrote:

>langwadt@fonz.dk wrote: > > ... > >> -Lasse > >You've been gone a long time. Nice to hear from you! > >Jerry
I was thinking the same. Hiya, Lasse! Eric Jacobsen Minister of Algorithms Abineau Communications http://www.ericjacobsen.org Blog: http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.php
On Sep 3, 10:37&#4294967295;pm, Jerry Avins <j...@ieee.org> wrote:
> Thomas Magma wrote: > > Hello, > > > I'm trying to write a very efficient and fast detection algorithm for a > > dsPIC. I've already been down the path of the Goertzel and have dismissed it > > because of it's use of floating point numbers. > > Goertzel can be fixed point. Over four years ago, someone at Rice U > published code to handle DTMF on an 8-bit integer microprocessor. Maybe > you can find it. >
I recall implementing the Goertzel back in 1986 on a then new TMS32010 that came in a plastic DIP and ran at only 14MHz. The part was only $10 which was a real price breakthrough at the time. I did DTMF, MF and MFC-R2 detection and generation in this part all with fixed point processing. If Thomas looks through old appnotes for various DSPs he is likely to find an actual implementation of the Goertzel. Analog Devices put out a pair of books that were full of appnotes (including a Goertzel) in fixed point arithmetic. Clay &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;

clay@claysturner.com wrote:


> I recall implementing the Goertzel back in 1986 on a then new TMS32010 > that came in a plastic DIP and ran at only 14MHz. The part was only > $10 which was a real price breakthrough at the time. I did DTMF, MF > and MFC-R2 detection and generation in this part all with fixed point > processing.
Yes, of course. On the CPU with the 16-bit MAC, Goertzel is more efficient then I/Q accumulation. BTW, DTMF is intended to be decoded by the frequency counters; filter methods, although working well, will never be formally compliant to the standard.
> Analog > Devices put out a pair of books that were full of appnotes (including > a Goertzel) in fixed point arithmetic.
Those two books have many bugs in the code and misprints in the formulae (deliberately?). The books give a good explanation of how the things could be done; however those who look for the canned solutions will be disappointed. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
On Sep 4, 11:20&#4294967295;am, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:
> c...@claysturner.com wrote: > > I recall implementing the Goertzel back in 1986 on a then new TMS32010 > > that came in a plastic DIP and ran at only 14MHz. &#4294967295;The part was only > > $10 which was a real price breakthrough at the time. I did DTMF, MF > > and MFC-R2 detection and generation in this part all with fixed point > > processing. > > Yes, of course. On the CPU with the 16-bit MAC, Goertzel is more > efficient then I/Q accumulation. BTW, DTMF is intended to be decoded by > the frequency counters; filter methods, although working well, will > never be formally compliant to the standard.
Well there were two reasons I did it this way. First the standard doesn't apply to a two hop scenario and back at that time the lines were for certain to be analog, so there was extra twist and observed dynamic range. But also the DTMF spec assumes a quiet channel except for the tones themselves. But many applications involving DTMF such as with voice response systems have to go beyond the spec to work with interference. Often an "early detect" is employed to shutdown the outbound audio and/or a good echo canceller/ 2wire to 4 wire hybrid is used to separate the paths. And actually a filter method involving a DSP was made compliant to Bell specs. Bell Labs did an implementation modelled around a standard central office line receiver during the early '80s. I have a copy of their writeup from the Bell System Journel which describes in great detail their actual application. The other reason I did it that way, was I was replacing a $200 module that did just tone decoding of MFC-R2. My solution was quite a bit less expensive and was accepted by Bell and others.
> > > Analog > > Devices put out a pair of books that were full of appnotes (including > > a Goertzel) in fixed point arithmetic. > > Those two books have many bugs in the code and misprints in the formulae > (deliberately?). The books give a good explanation of how the things > could be done; however those who look for the canned solutions will be > disappointed.
I never programmed an Analog Devices CPU, I've always used Mots and TIs. But I know that TI have an appnote that was quite good which I used as a starting point. Even though the AD books contain typos, I think a salient engineer can figure those out. I thought the books brought fourth a lot of good information. Clay
> > Vladimir Vassilevsky > DSP and Mixed Signal Design Consultanthttp://www.abvolt.com

clay@claysturner.com wrote:

> On Sep 4, 11:20 am, Vladimir Vassilevsky <antispam_bo...@hotmail.com> > wrote: >
>>DTMF is intended to be decoded by >>the frequency counters; filter methods, although working well, will >>never be formally compliant to the standard.
IIRC the receiver must reject the signals which are more then 3.5Hz away from the standard frequences. With the 40ms duration of the tones, any method which uses just the frequency filters is prone to 1/T uncertainty. An unusual way to make a DTMF decoder was demonstrated here: "A Low-Complexity ITU-Compliant Dual Tone Multiple Frequency Detector" Amey A. Deosthali, Shawn R. McCaslin, Brian L. Evans They used the counters and the adaptive notch filters; that allowed to put the formally compliant decoder into 4 MIPS of PIC16.
> Well there were two reasons I did it this way. First the standard > doesn't apply to a two hop scenario and back at that time the lines > were for certain to be analog, so there was extra twist and observed > dynamic range. But also the DTMF spec assumes a quiet channel except > for the tones themselves. But many applications involving DTMF such as > with voice response systems have to go beyond the spec to work with > interference. Often an "early detect" is employed to shutdown the > outbound audio and/or a good echo canceller/ 2wire to 4 wire hybrid is > used to separate the paths.
I certainly agree with your reasoning, as I know that the filter based decoders work very well in practice. However the formal compliance is good to have.
> And actually a filter method involving a DSP was made compliant to > Bell specs. Bell Labs did an implementation modelled around a standard > central office line receiver during the early '80s. I have a copy of > their writeup from the Bell System Journel which describes in great > detail their actual application.
Can you please explain briefly what they did.
> The other reason I did it that way, was I was replacing a $200 module > that did just tone decoding of MFC-R2. My solution was quite a bit > less expensive and was accepted by Bell and others.
In 80-x, we build the R1.5 decoder using the set of the analog filters. It wasn't very trivial to get the desired Q and stability. A digital solution seemed to be too complex, expensive and impractical :-)
>>>Analog >>>Devices put out a pair of books that were full of appnotes (including >>>a Goertzel) in fixed point arithmetic. >> >>Those two books have many bugs in the code and misprints in the formulae >>(deliberately?). The books give a good explanation of how the things >>could be done; however those who look for the canned solutions will be >>disappointed. > > I never programmed an Analog Devices CPU, I've always used Mots and > TIs.
I have used ADIs and TIs, now looking toward Mots. IMO the ADI CPUs are more logical and the common sense based, and the tools and documens are more friendly then from the other vendors. That makes them very attractive at the beginning.
> But I know that TI have an appnote that was quite good which I > used as a starting point. Even though the AD books contain typos, I > think a salient engineer can figure those out. I thought the books > brought fourth a lot of good information.
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
> > And actually a filter method involving a DSP was made compliant to > > Bell specs. Bell Labs did an implementation modelled around a standard > > central office line receiver during the early '80s. I have a copy of > > their writeup from the Bell System Journel which describes in great > > detail their actual application. > > Can you please explain briefly what they did. > > Vladimir Vassilevsky > DSP and Mixed Signal Design Consultanthttp://www.abvolt.com
Hello Vladimir, Recalling from memory as the article is at home (I haven't looked at it for years), they really modelled the actual analog unit. First the signal would have both a mains and dial tone notch filter to clean it up. Then the signal was split into two branches where one goes through a high band group and the other branch goes through a low band group. The band filters would span either 4 row freqs or 4 column freqs depending on which group we are talking about. Then the output of each group filter would be split and go into four row(column) narrow band pass filters ( I seem to recall they were 4th order each - lower Q - faster transient response). Then each filter's ouput would be rectified and passed into a fast attack slow release circuit akin to a simple AGC. These filtered results would then go to some comparators for thresholding and then the band results were compared for twist analysis. If I think about it when I get back to the farm, I'll find the paper and give you more details. Clay
On Sep 5, 12:49&#4294967295;am, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:
> c...@claysturner.com wrote: > > On Sep 4, 11:20 am, Vladimir Vassilevsky <antispam_bo...@hotmail.com> > > wrote: > > >>DTMF is intended to be decoded by > >>the frequency counters; filter methods, although working well, will > >>never be formally compliant to the standard. > > IIRC the receiver must reject the signals which are more then 3.5Hz away > from the standard frequences. With the 40ms duration of the tones, any > method which uses just the frequency filters is prone to 1/T uncertainty.
The DTMF spec varies a bit with the country, but the Bell, ITU and most other specs say you must detect when the frequency is within 1.5% of the target and reject when its more then 3.5% from the target. Maybe you confused 3.5% and 3.5Hz. There is no problem whatsoever meeting the ITU spec by a variety of methods, including Goertzel, LPC and others. The biggest differentiator tends to be how well they perform in talkoff tests.
> An unusual way to make a DTMF decoder was demonstrated here: > > "A Low-Complexity ITU-Compliant Dual Tone Multiple Frequency Detector" > Amey A. Deosthali, Shawn R. McCaslin, Brian L. Evans > > They used the counters and the adaptive notch filters; that allowed to > put the formally compliant decoder into 4 MIPS of PIC16.
That one looks interesting from a quick glance. I keep aiming to find the time to look in more detail at what they did.
> > Well there were two reasons I did it this way. First the standard > > doesn't apply to a two hop scenario and back at that time the lines > > were for certain to be analog, so there was extra twist and observed > > dynamic range. But also the DTMF spec assumes a quiet channel except > > for the tones themselves. But many applications involving DTMF such as > > with voice response systems have to go beyond the spec to work with > > interference. Often an "early detect" is employed to shutdown the > > outbound audio and/or a good echo canceller/ 2wire to 4 wire hybrid is > > used to separate the paths. > > I certainly agree with your reasoning, as I know that the filter based > decoders work very well in practice. However the formal compliance is > good to have.
Format compliance is trivial to achieve. Making it work well in the real world is where it gets tougher. :-)
> > And actually a filter method involving a DSP was made compliant to > > Bell specs. Bell Labs did an implementation modelled around a standard > > central office line receiver during the early '80s. I have a copy of > > their writeup from the Bell System Journel which describes in great > > detail their actual application. > > Can you please explain briefly what they did. > > > The other reason I did it that way, was I was replacing a $200 module > > that did just tone decoding of MFC-R2. My solution was quite a bit > > less expensive and was accepted by Bell and others. > > In 80-x, we build the R1.5 decoder using the set of the analog filters. > It wasn't very trivial to get the desired Q and stability. A digital > solution seemed to be too complex, expensive and impractical :-)
The 80s is a long period. At the start of the 80s a DSP R1, R1.5 or R2 detector would have been expensive with off the shelf devices, like the NEC or TI DSPs appearing at that time. People did this in the late 70s at very low cost and power using custom bit serial DSP silicon, though. When I used off the shelf DSP processors in about 1986/87 to do DTMF, R1, and R2, 2280Hz and 2600Hz generation and detection for a whole E1, the cost per channel was less than a DTMF receiver chip like the popular 8870s. When testing the 2280Hz and 2600Hz stuff against existing analogue implementations I couldn't find a single analogue implementation which actually complied fully with the specs. I don't know any way in which my implementation failed, it was naturally more stable over time, and it was more robust in talk off tests. Considering the behaviour of some 2600Hz kit, it isn't surprising that blue boxing was so popular. :-)
> >>>Analog > >>>Devices put out a pair of books that were full of appnotes (including > >>>a Goertzel) in fixed point arithmetic. > > >>Those two books have many bugs in the code and misprints in the formulae > >>(deliberately?). The books give a good explanation of how the things > >>could be done; however those who look for the canned solutions will be > >>disappointed.
Those books are particularly bad. Few app notes actually work, or have much consistency between the text the diagrams and the supplied code, but Analog's early DSP material gave little more than vague clues about what might be achieved. I suspect they were put together in parallel with the silicon development, and were not shaken out when real silicon was available.
> > > I never programmed an Analog Devices CPU, I've always used Mots and > > TIs. > > I have used ADIs and TIs, now looking toward Mots. IMO the ADI CPUs are > more logical and the common sense based, and the tools and documens are > more friendly then from the other vendors. That makes them very > attractive at the beginning. > > > But I know that TI have an appnote that was quite good which I > > used as a starting point. Even though the AD books contain typos, I > > think a salient engineer can figure those out. I thought the books > > brought fourth a lot of good information.
They were full of good ideas, but in a very rough state. Regards, Steve