DSPRelated.com
Forums

some help please on more efficient way to detect tones?

Started by jacobfenton January 8, 2010
I could use some help, since I am very new to DSP. Here is my situation:

I am recieving I/Q data at 250kHz rate, demodulating it with demodulation
algorithm: IdQ+QdI/I^2+Q^2.
Then storing 800 samples and using the Goertzel algorithm to detect 4
different tones.

Currently the DSP cannot calculate all of this and I am getting data
overrun, I have a flag which tells me that the Goertzel is not finished on
the block of 800 before the next block is ready, I have to continually
detect tones. The demodulation is done every time a new frame of data comes
in, and the Goertzel is run in the backround after 800 samples are stored
up (double buffered). I cannot slow down the data rate and I have to detect
4 tones. Currently using a TMS320F28335 DSP running at 144Mhz. 

Is there a more effiecient way to detect the 4 tones, I have read about
sliding Goertzel or sliding DFT, is this more efficient, or have I just met
the limit of the DSP number crunching since my data rate is pretty fast.
Thanks.

-Jacob Fenton



jacobfenton wrote:
> I could use some help, since I am very new to DSP. Here is my situation: > > I am recieving I/Q data at 250kHz rate, demodulating it with demodulation > algorithm: IdQ+QdI/I^2+Q^2. > Then storing 800 samples and using the Goertzel algorithm to detect 4 > different tones. > > Currently the DSP cannot calculate all of this and I am getting data > overrun, I have a flag which tells me that the Goertzel is not finished on > the block of 800 before the next block is ready, I have to continually > detect tones. The demodulation is done every time a new frame of data comes > in, and the Goertzel is run in the backround after 800 samples are stored > up (double buffered). I cannot slow down the data rate and I have to detect > 4 tones. Currently using a TMS320F28335 DSP running at 144Mhz. > > Is there a more effiecient way to detect the 4 tones, I have read about > sliding Goertzel or sliding DFT, is this more efficient, or have I just met > the limit of the DSP number crunching since my data rate is pretty fast. > Thanks.
Several tricks can be applied here; I need to know: What is the SNR? What is the FM deviation? What are the frequencies of the tones? How fast should be the reaction of the detector? You have to distinguish the tones over the background of what? Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
> > >jacobfenton wrote: >> I could use some help, since I am very new to DSP. Here is my
situation:
>> >> I am recieving I/Q data at 250kHz rate, demodulating it with
demodulation
>> algorithm: IdQ-QdI/I^2+Q^2. >> Then storing 800 samples and using the Goertzel algorithm to detect 4 >> different tones. >> >> Currently the DSP cannot calculate all of this and I am getting data >> overrun, I have a flag which tells me that the Goertzel is not finished
on
>> the block of 800 before the next block is ready, I have to continually >> detect tones. The demodulation is done every time a new frame of data
comes
>> in, and the Goertzel is run in the backround after 800 samples are
stored
>> up (double buffered). I cannot slow down the data rate and I have to
detect
>> 4 tones. Currently using a TMS320F28335 DSP running at 144Mhz. >> >> Is there a more effiecient way to detect the 4 tones, I have read
about
>> sliding Goertzel or sliding DFT, is this more efficient, or have I just
met
>> the limit of the DSP number crunching since my data rate is pretty
fast.
>> Thanks. > >Several tricks can be applied here; I need to know: > >What is the SNR? >What is the FM deviation? >What are the frequencies of the tones? >How fast should be the reaction of the detector? >You have to distinguish the tones over the background of what? > > >Vladimir Vassilevsky >DSP and Mixed Signal Design Consultant >http://www.abvolt.com >
SNR = 7dB FM deviation = 30kHz Tones = 7500,8460,10760,12140 Reaction = tone must be present for 25ms to be considered valid. Your last question not sure what you mean, there is no backround just tones on a carrier, this is not DTMF, just a carrier dedicated to sending out tones, and only the 4 specific tones. I know that I can only make the DSP look for two tones every other block, thus speeding up my processing, but they want to look for all four tones in every block of data. I also tried changing the number of sample I look at to detect tones, but all that means is that the next block of data is ready faster if I lower the block size. There is potential gain in optimizing the assembly code the compiler spits out, but that is kind of a last resort I hope. Thanks for you help. -Jacob Fenton
jacobfenton wrote:
> I could use some help, since I am very new to DSP. Here is my situation: > > I am recieving I/Q data at 250kHz rate, demodulating it with demodulation > algorithm: IdQ+QdI/I^2+Q^2.
IdQ+QdI/I^2+Q^2 is not an algorithm, but a formula. The algorithm has steps to compute dQ and dI (where I assume that d stands in for delta) and various others. You may be able to improve the efficiencies of these steps. What language do you use? How good is your compiler at producing fast code? Recognize the IdQ/dt + QdI/dt = d(IQ/dt). Can you wring some speed out of that? Is I^2+Q^2 nearly constant? ... Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
>jacobfenton wrote: >> I could use some help, since I am very new to DSP. Here is my
situation:
>> >> I am recieving I/Q data at 250kHz rate, demodulating it with
demodulation
>> algorithm: IdQ+QdI/I^2+Q^2. > >IdQ+QdI/I^2+Q^2 is not an algorithm, but a formula. The algorithm has >steps to compute dQ and dI (where I assume that d stands in for delta) >and various others. You may be able to improve the efficiencies of these
>steps. What language do you use? How good is your compiler at producing >fast code? > >Recognize the IdQ/dt + QdI/dt = d(IQ/dt). Can you wring some speed out >of that? Is I^2+Q^2 nearly constant? > > ... > >Jerry >-- >Engineering is the art of making what you want from things you can get. >??????????????????????????????????????????????????????????????????????? >
You are correct, the current algorithm is this: W(n)=I(n)*[Q(n+1)-Q(n-1)]-Q(n)*[I(n+1)-I(n-1)] ----------------------------------------- I(n)*I(n)+Q(n)*Q(n) The code is in C, and I have looked into seeing how efficient the compiler makes code, and just recently found out some ways to make it optimize better, and it did get much faster, but we are still needing more speed out of it. I^2+Q^2 is nearly constant, I will look into that further and see if we can throw it out or not. Thanks again for responses, every little bit helps. -Jacob Fenton
jacobfenton wrote:
>> jacobfenton wrote: >>> I could use some help, since I am very new to DSP. Here is my > situation: >>> I am recieving I/Q data at 250kHz rate, demodulating it with > demodulation >>> algorithm: IdQ+QdI/I^2+Q^2. >> IdQ+QdI/I^2+Q^2 is not an algorithm, but a formula. The algorithm has >> steps to compute dQ and dI (where I assume that d stands in for delta) >> and various others. You may be able to improve the efficiencies of these > >> steps. What language do you use? How good is your compiler at producing >> fast code? >> >> Recognize the IdQ/dt + QdI/dt = d(IQ/dt). Can you wring some speed out >> of that? Is I^2+Q^2 nearly constant >> > You are correct, the current algorithm is this: > > W(n)=I(n)*[Q(n+1)-Q(n-1)]-Q(n)*[I(n+1)-I(n-1)] > ----------------------------------------- > I(n)*I(n)+Q(n)*Q(n)
We have different ideas about what an algorithm is. To me, it is a sequence of separate steps. I understand what you mean, and that's what matters. By convention, we use square brackets for discrete sequences and curved parentheses for continuous quantities and for grouping. I would write W[n]=I[n]*(Q[n+1]-Q[n-1])-Q[n]*(I[n+1]-I[n-1]) ----------------------------------------- I[n]*I[n]+Q[n]*Q[n]
> The code is in C, and I have looked into seeing how efficient the compiler > makes code, and just recently found out some ways to make it optimize > better, and it did get much faster, but we are still needing more speed out > of it. > I^2+Q^2 is nearly constant, I will look into that further and see if we > can throw it out or not.
It is likely that the constancy of I^2+Q^2 depends on the constancy of the signal strength at the detector. In turn, that depends on the path and on the stiffness of the AGC. It might be wise to calculate it at least once per block.
> Thanks again for responses, every little bit helps.
Good luck Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
On Jan 8, 2:51&#4294967295;pm, "jacobfenton" <jacob.fen...@gmail.com> wrote:
> >jacobfenton wrote: > >> I could use some help, since I am very new to DSP. Here is my > situation: > > >> I am recieving I/Q data at 250kHz rate, demodulating it with > demodulation > >> algorithm: IdQ+QdI/I^2+Q^2. > > >IdQ+QdI/I^2+Q^2 is not an algorithm, but a formula. The algorithm has > >steps to compute dQ and dI (where I assume that d stands in for delta) > >and various others. You may be able to improve the efficiencies of these > >steps. What language do you use? How good is your compiler at producing > >fast code? > > >Recognize the IdQ/dt + QdI/dt = d(IQ/dt). Can you wring some speed out > >of that? Is I^2+Q^2 nearly constant? > > > &#4294967295; ... > > >Jerry > >-- > >Engineering is the art of making what you want from things you can get. > >??????????????????????????????????????????????????????????????????????? > > You are correct, the current algorithm is this: > > W(n)=I(n)*[Q(n+1)-Q(n-1)]-Q(n)*[I(n+1)-I(n-1)] > &#4294967295; &#4294967295; &#4294967295;----------------------------------------- > &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; I(n)*I(n)+Q(n)*Q(n) > > The code is in C, and I have looked into seeing how efficient the compiler > makes code, and just recently found out some ways to make it optimize > better, and it did get much faster, but we are still needing more speed out > of it. > I^2+Q^2 is nearly constant, I will look into that further and see if we > can throw it out or not. > > Thanks again for responses, every little bit helps. > > -Jacob Fenton- Hide quoted text - > > - Show quoted text -
If I^2 + Q^2 is nearly constant then expand (as a series about the nominal value) and convert the highly inefficient division into a multiplication. For example (x0 is the nominal value and dx = x-x0) 1/x = 1/(x0+dx) = x0/(1+dx/x0) = x0*(1-(dx/x0)+(dx/x0)^2-(dx/x0) ^3+...) which to 1st order is simply x0-dx IHTH, Clay

jacobfenton wrote:
>> >>jacobfenton wrote: >> >>>I could use some help, since I am very new to DSP. Here is my > > situation: > >>>I am recieving I/Q data at 250kHz rate, demodulating it with > > demodulation > >>>algorithm: IdQ-QdI/I^2+Q^2. >>>Then storing 800 samples and using the Goertzel algorithm to detect 4 >>>different tones. >>> >>>Currently the DSP cannot calculate all of this and I am getting data >>>overrun, I have a flag which tells me that the Goertzel is not finished > > on > >>>the block of 800 before the next block is ready, I have to continually >>>detect tones. The demodulation is done every time a new frame of data > > comes > >>>in, and the Goertzel is run in the backround after 800 samples are > > stored > >>>up (double buffered). I cannot slow down the data rate and I have to > > detect > >>>4 tones. Currently using a TMS320F28335 DSP running at 144Mhz. >>> >>>Is there a more effiecient way to detect the 4 tones, I have read > > about > >>>sliding Goertzel or sliding DFT, is this more efficient, or have I just > > met > >>>the limit of the DSP number crunching since my data rate is pretty > > fast. > >>>Thanks. >> >>Several tricks can be applied here; I need to know: >> >>What is the SNR? >>What is the FM deviation? >>What are the frequencies of the tones? >>How fast should be the reaction of the detector? >>You have to distinguish the tones over the background of what? >> >> >>Vladimir Vassilevsky >>DSP and Mixed Signal Design Consultant >>http://www.abvolt.com >> > > SNR = 7dB > FM deviation = 30kHz > Tones = 7500,8460,10760,12140 > Reaction = tone must be present for 25ms to be considered valid. > Your last question not sure what you mean, there is no backround just > tones on a carrier, this is not DTMF, just a carrier dedicated to sending > out tones, and only the 4 specific tones. > > I know that I can only make the DSP look for two tones every other block, > thus speeding up my processing, but they want to look for all four tones in > every block of data. I also tried changing the number of sample I look at > to detect tones, but all that means is that the next block of data is ready > faster if I lower the block size. There is potential gain in optimizing the > assembly code the compiler spits out, but that is kind of a last resort I > hope.
The simplest thing to do would be downsample the signal by /3 prior to processing. Then the sample rate would be 83kHz and there should be enough of CPU. Since your highest tone is 12140, there is not much gain in sampling faster then 25kHz after the discriminator. That's another improvement. Since you only have 4 tones, you can downsample even more, just enough for the aliases not to overlap. A sample rate of ~8 kHz should suffice. Since the signal is stationary over 25ms, there could be more elegant solutions, such as decimate and solve the system of equations or do the same in the spectral domain. Looks like there is no need for DSP. A PIC would do the job. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
If you only need to detect 4 tones, you can get improved
responsiveness (at negligible cost) through using the sliding DFT
instead of Goertzel. If you are unfamiliar with it, the SDFT is simply
an IIR implementation (first order complex feedback, Nth order real
feedforward) for each bin of the DFT which can be efficient if the
number of bins needed are few and/or the analysis rate is also very
high. Your system would consist of a single N-length comb filter/FIFO
which feeds into 4 complex resonators. There is no need to scramble
through 800 samples at a time.

Google books provides access to one of the more recent publications by
Eric Jacobsen and Richard Lyons on the subject and various ways to
simplify it.

http://books.google.ca/books?id=97Iggo5MQt4C&pg=PA145&lpg=PA145&dq=Sliding+Spectrum+Analysis&source=bl&ots=4h6v5XsgeU&sig=pn4NGJ25HH8_Eq03LfRXczbFXyU&hl=en&ei=wddHS9D-Es7rlAfn7t0M&sa=X&oi=book_result&ct=result&resnum=5&ved=0CCIQ6AEwBA

Hope this helps.

--Ben


On Jan 8, 7:56&#4294967295;am, "jacobfenton" <jacob.fen...@gmail.com> wrote:
> I could use some help, since I am very new to DSP. Here is my situation: > > I am recieving I/Q data at 250kHz rate, demodulating it with demodulation > algorithm: IdQ+QdI/I^2+Q^2. > Then storing 800 samples and using the Goertzel algorithm to detect 4 > different tones. > > Currently the DSP cannot calculate all of this and I am getting data > overrun, I have a flag which tells me that the Goertzel is not finished on > the block of 800 before the next block is ready, I have to continually > detect tones. The demodulation is done every time a new frame of data comes > in, and the Goertzel is run in the backround after 800 samples are stored > up (double buffered). I cannot slow down the data rate and I have to detect > 4 tones. Currently using a TMS320F28335 DSP running at 144Mhz. > > Is there a more effiecient way to detect the 4 tones, I have read about > sliding Goertzel or sliding DFT, is this more efficient, or have I just met > the limit of the DSP number crunching since my data rate is pretty fast. > Thanks. > > -Jacob Fenton
On Jan 8, 4:49&#4294967295;pm, Jerry Avins <j...@ieee.org> wrote:
> jacobfenton wrote: > >> jacobfenton wrote: > >>> I could use some help, since I am very new to DSP. Here is my > > situation: > >>> I am recieving I/Q data at 250kHz rate, demodulating it with > > demodulation > >>> algorithm: IdQ+QdI/I^2+Q^2. > >> IdQ+QdI/I^2+Q^2 is not an algorithm, but a formula. The algorithm has > >> steps to compute dQ and dI (where I assume that d stands in for delta) > >> and various others. You may be able to improve the efficiencies of these > > >> steps. What language do you use? How good is your compiler at producing > >> fast code? > > >> Recognize the IdQ/dt + QdI/dt = d(IQ/dt). Can you wring some speed out > >> of that? Is I^2+Q^2 nearly constant > > > You are correct, the current algorithm is this: > > > W(n)=I(n)*[Q(n+1)-Q(n-1)]-Q(n)*[I(n+1)-I(n-1)] > > &#4294967295; &#4294967295; &#4294967295;----------------------------------------- > > &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; I(n)*I(n)+Q(n)*Q(n) > > We have different ideas about what an algorithm is. To me, it is a > sequence of separate steps. I understand what you mean, and that's what > matters. > > By convention, we use square brackets for discrete sequences and curved > parentheses for continuous quantities and for grouping. I would write > > W[n]=I[n]*(Q[n+1]-Q[n-1])-Q[n]*(I[n+1]-I[n-1]) > &#4294967295; &#4294967295; &#4294967295; ----------------------------------------- > &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;I[n]*I[n]+Q[n]*Q[n] >
i recognize that. that is detecting the instantaneous frequency (the rate of change of the phase angle) of an I+jQ signal. this is FM detection, are your 4 frequencies modulating some common carrier? or are you using that to detect one of the 4 frequencies? if that is the case, rather than Goertzel, i might suggest using 4 simultaneously-running "peaking EQ" filters tuned to the 4 frequencies and examine the relative strength or signal coming out of them. (i've used this for DTMF decoding in the past and thought it worked better than Goertzel.) you can get the coefficients of the peaking EQ filters from the Audio EQ Cookbook. you can crank up the Q real high, if you're confident about the stability of the frequency of the tones to deal with a nasty S/N. you would adjust the overall gain (the numerator coefficients) so that the peak is at 0 dB and the side skirts are reduced to -G dB (G dB is the peak gain over the DC and Nyquist gain).
> > The code is in C, and I have looked into seeing how efficient the compiler > > makes code, and just recently found out some ways to make it optimize > > better, and it did get much faster, but we are still needing more speed out > > of it.
> > I^2+Q^2 is nearly constant, I will look into that further and see if we > > can throw it out or not.
if you use your FM formula, you can adjust the gain of your detector with by comparing I^2+Q^2 to a set point (say 1) and adjust the gain up or down by half of the negative of that difference. this i learned from Jerry. if you want a little more LPF behavior with the gain adjustment, then reduce that difference more with a scaling coef of less than 1/2.
> It is likely that the constancy of I^2+Q^2 depends on the constancy of > the signal strength at the detector.
yupper. r b-j