CC and GCC for time delay estimation

On 1/4/14 7:45 PM, mnentwig wrote:
>
>   a sine burst is a bad signal for delay estimation. You'll see why when you
> look at its crosscorrelation. It resembles itself too well.
> A chirp is a better choice, for example. Generally,  use the available
> bandwidth, that is, ideally a constant power density (keywords: Cramer-Rao
> bound; time-of-arrival TOA).

yeah, as much broadbanded as possible.

dunno if it would be better than a linear-swept chirp (it *would* have a 
slightly better crest factor) but maybe a maximum-length sequence would 
be the best choice for calculating cross correlation and time of arrival.

maybe not.  i dunno.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

True. Cellular systems use for example Zhadoff-Chu sequences, which is just
that. 	 

_____________________________		
Posted through www.DSPRelated.com

On Friday, January 3, 2014 4:02:53 PM UTC-5, robert...@gmail.com wrote:
> Hi guys, I have to determine the time lag between two signals x and y for an acoustic distance measurement setup. The signal x is the test input signal and y is the reflected signal from the acoustic path. This is modeled the following: y = h * y + N whereas N is additional gaussian noise and h is the impulse response of the acoustic path. (The operator * states for a convolution operator). My first approach for determining the time delay was correlation based. Doing a cross-correlation (CC) between the two signals x and y and take the maximum of the absolute of it. Here is a little Matlab example of this trivial approach: [Rxy, k] = xcorr(y, x); [~, loc] = max(abs(Rxy)); lag = k(loc); The performance of this was not that good since there is a distortion through the acoustic path and noise. I looked up this problem a bit on the internet and found the generalized cross correlation (GCC) which introduces a weighting function in the frequency domain. I tried these approaches but did not get any meaningful results respectively an improvement to a simple CC as described above. Consider for example the following snipped with a PHAT weighting function: N = max(length(x), length(y)); X = fft(x, N); Y = fft(y, N); Gxy = conj(Y) .* X; Gxy = Gxy ./ abs(Gxy); Rxy = fftshift(real(ifft(Gxy))); This does not yield a meaningful result. There is no correlation visible when plotting this. Also other weighting functions (ROTH, HT, SCOT) do not really show an expected result. Can anyone help and give me some advice why there is no improvement using GCC or what I'm doing wrong with it? Thank you in advance! Cheers Robert



On Friday, January 3, 2014 4:02:53 PM UTC-5, robert...@gmail.com wrote:
> Hi guys, I have to determine the time lag between two signals x and y for an acoustic distance measurement setup. The signal x is the test input signal and y is the reflected signal from the acoustic path. This is modeled the following: y = h * y + N whereas N is additional gaussian noise and h is the impulse response of the acoustic path. (The operator * states for a convolution operator). My first approach for determining the time delay was correlation based. Doing a cross-correlation (CC) between the two signals x and y and take the maximum of the absolute of it. Here is a little Matlab example of this trivial approach: [Rxy, k] = xcorr(y, x); [~, loc] = max(abs(Rxy)); lag = k(loc); The performance of this was not that good since there is a distortion through the acoustic path and noise. I looked up this problem a bit on the internet and found the generalized cross correlation (GCC) which introduces a weighting function in the frequency domain. I tried these approaches but did not get any meaningful results respectively an improvement to a simple CC as described above. Consider for example the following snipped with a PHAT weighting function: N = max(length(x), length(y)); X = fft(x, N); Y = fft(y, N); Gxy = conj(Y) .* X; Gxy = Gxy ./ abs(Gxy); Rxy = fftshift(real(ifft(Gxy))); This does not yield a meaningful result. There is no correlation visible when plotting this. Also other weighting functions (ROTH, HT, SCOT) do not really show an expected result. Can anyone help and give me some advice why there is no improvement using GCC or what I'm doing wrong with it? Thank you in advance! Cheers Robert

If it's some kind of sonar-type device you can try pulse compression by using e.g. chirp-like signal or phase-modulated signal with Barker codes, followed by cross-correlation of transmitted and received signals

What's the application ?

On Sunday, January 5, 2014 12:05:05 AM UTC-5, robert bristow-johnson wrote:
> On 1/4/14 7:45 PM, mnentwig wrote:
> 
> >
> 
> >   a sine burst is a bad signal for delay estimation. You'll see why when you
> 
> > look at its crosscorrelation. It resembles itself too well.
> 
> > A chirp is a better choice, for example. Generally,  use the available
> 
> > bandwidth, that is, ideally a constant power density (keywords: Cramer-Rao
> 
> > bound; time-of-arrival TOA).
> 
> 
> 
> yeah, as much broadbanded as possible.
> 
> 
> 
> dunno if it would be better than a linear-swept chirp (it *would* have a 
> 
> slightly better crest factor) but maybe a maximum-length sequence would 
> 
> be the best choice for calculating cross correlation and time of arrival.
> 
> 
> 
> maybe not.  i dunno.
> 
> 
> 
> 
> 
> -- 
> 
> 
> 
> r b-j                  rbj@audioimagination.com
> 
> 
> 
> "Imagination is more important than knowledge."

Analog TV uses a windowed chirp for ghost echo cancelation. It is a pretty good model for a broad spectrum, yet still work inside of broadcast TV specs, signal.

Clay

Not sure I can help, but I took some courses about time delay estimation, and GCC was a prominent part of it.  But that was some 30 years ago, so I don't recall all of the details.

We started out with CC and found that it didn't work well for certain conditions (eg: low SNR, interfering sinusoid, etc.).  We then studied GCC and explored its various forms.  As you know, it uses a 'window' or shaping function in the frequency domain to emphasize those parts of spectrum where the SNR is expected to be higher, and deemphasize those parts that have more noise or interference.  In all the cases we looked at, the problem was posed as a two-hydrophone/passive sonar problem.

Depending on which mathematical terms you decided to keep or throw away, you could get the various forms of GCC � each one good at some things, or not so good at other things (eg: some forms of GCC are better at being able to handle sinusoidal interference).  Sometimes one type would devolve into another under certain conditions (eg: ML reduces to an Ekhart filter at low SNR).  Sometimes it was a bit confusing.  I think that one of the forms reduces to a toaster strudel at high SNR � or something like that.

That said, it seems that what you're doing is more of a matched filter operation rather than GCC.  Your equations look like an Ekhart filter, and your processing seems to be more of a single receiver/matched filter one - and Ekhart filters are often used in matched filtering (we studied Ekhart filters in one of the two-hydrophone GCC configurations).

At any rate, the processing can be tricky at times.  For instance, you have an obvious mistake in that you're not zero-padding your signals 'x' and 'y' (been there, done that).  It seems that I was constantly running into some problem with some of the equations or scaling or this or that (eg: how to compute certain variables needed by some of the more complicated GCC forms).

Since your SNR seems to be high enough, and you asked about reducing the noise � well, I suppose you could try some narrowband filtering on the front end.  Or you might use a single DFT bin tuned to the specific frequency that you're dealing with so as to get some processing gain (eg: see my answer at:

http://dsp.stackexchange.com/questions/11541/getting-an-specific-frequency-component-from-sampled-audio/11553#11553

I also posted a few references to GCC:

http://dsp.stackexchange.com/questions/8732/generalized-cross-correlation/8746#8746

I'm also sure I've posted about the same thing here at comp.dsp, but I don't recall off-hand which posts they were.

Kevin McGee