Calculating delay b/w signals using correlation

[nauman]

Hi all
I am generating two signals of same frequency, i introduce a fixed delay in one of the signal and then try to find out the simulated delay using MATLAB 'gccphat' and 'finddelay' functions, but not able to measure correct delay. MATLAB Code script is given below:
[CODE lang="matlab" title="Delay b/w two signals using correlation"]clc
clear
close all%%%%=======================================================================
%%%%============================General Parameters=========================
%%%%=======================================================================
fo=8500;%frequency in Hz
samp_f=30*51.2e3;%Sampling frequency
samp_t=1/samp_f;
chunk_size=163840;
total_chunks=1;
chunk_time=chunk_size/samp_f;
chunk_t=0:samp_t:(samp_t*(chunk_size-1));%time vector calculated

delay_=0.0064;

H1(1:chunk_size,1)=sin(2*pi*fo*(chunk_t))+0*randn(1,chunk_size);%Sensor H1 signal
H2(1:chunk_size,1)=sin(2*pi*fo*(chunk_t+delay_))+0*randn(1,chunk_size);%Sensor H2 signal
figure,plot(H1(1:2000)),hold on,plot(H2(1:2000),'r')

format long
tau_a=gccphat(H1,H2,samp_f)
tau_b = finddelay(H1, H2) / samp_f[/CODE]

Output:
tau_a = 0
tau_b = 1.171875000000000e-05

Can any one kindly point out where i am doing wrong with such simple task? As per my understanding, both outputs should match with the delay i.e. 0.0064s?
Thanks

 

[jedishrfu]

You said you created two signals via sine function with one delayed behind the other.

It looks like you also added noise to the signals and plotted them. In your plot can you visually see the delay or does the noise obscure it?

 

[nauman]

Hi Jedishrfu
There is no noise added in both signals as i have multiply randn with 0 in both cases. Both signals are pure sinusoidal and delay can be seen visually.

 

[jedishrfu]

have you checked for example usage of the finddelay function?

https://www.mathworks.com/help/signal/ref/finddelay.html

Noticein their examples, they prepend zeros. You could try using h1 and make dh1 with prepended zeros to verify that the finddelay function works.

At the end of the article on finddelay, the author mentions that xcorr() is used and that sufficient correlation between the signals must be present so maybe that’s the issue.

 

[FactChecker]

My first recommendation is to try your code with some dirt-simple numbers that are easy to check. You might get some surprises.
1) Your code actually looks like an advance by delay_.
2) Is there a default limit on the correlation window size? Your "delay" (actually advance) is 9,830.4 samples. I didn't check how many samples it is as a true delay from the next cycle.
3) How does your delay compare to your frequency? It looks to me as though your delay is many cycles at that frequency. Is that what you meant to do? That delay at that frequency might be equivalent to a much smaller delay.

 

[nauman]

2) Is there a default limit on the correlation window size? Your "delay" (actually advance) is 9,830.4 samples. I didn't check how many samples it is as a true delay from the next cycle.
3) How does your delay compare to your frequency? It looks to me as though your delay is many cycles at that frequency. Is that what you meant to do? That delay at that frequency might be equivalent to a much smaller delay.

Hi

Thanks for help. With sampling frequency of approx. 1.53 MHz, one cycle of 8.5 KHz corresponds to 181 samples approx. It means 0.0064 second delay corresponds to approx (9830.4/181=53.4) 54 cycles delay at that particular frequency. This also means xcorr will never able to calculate true delay b/w two signals of same frequency if it is greater than one cycle delay. Am i right in my understanding?

Thanks

 

[nauman]

have you checked for example usage of the finddelay function?

https://www.mathworks.com/help/signal/ref/finddelay.html

Noticein their examples, they prepend zeros. You could try using h1 and make dh1 with prepended zeros to verify that the finddelay function works.

At the end of the article on finddelay, the author mentions that xcorr() is used and that sufficient correlation between the signals must be present so maybe that’s the issue.

Hi
I have also tried with appended zeros of same length as that of signal but results does not match with delay_.
Thanks

 

[FactChecker]

Hi

Thanks for help. With sampling frequency of approx. 1.53 MHz, one cycle of 8.5 KHz corresponds to 181 samples approx.

Ok.

It means 0.0064 second delay corresponds to approx (9830.4/181=53.4) 54 cycles delay at that particular frequency.

Right, except that it is not a delay. Since the values of H2 are appropriate for a later time, chunk_t+delay_ , it is actually ahead of H1 in time, not delayed.

This also means xcorr will never able to calculate true delay b/w two signals of same frequency if it is greater than one cycle delay.

I don't think that is right. The algorithm doesn't care that the frequencies are the same. The crosscorrelation should be perfect at 54 cycles advanced, but there may be smaller time shifts that come close enough to fool it. You are asking for crosscorrelations to be calculated for 181*54=9774 both forward and behind. I don't know how many crosscorrelations it does by default, but I would not be surprised if it stops for some reason before that.

Why don't you try some much fewer frames of time-shift and see if your code behaves as expected? Try a simple test case.

 

[nauman]

Why don't you try some much fewer frames of time-shift and see if your code behaves as expected? Try a simple test case.

I am simulating signals on two hydrophones H1 and H2 of linear array which are at a distance 'd' from each other. The geometry is shown below:

Assuming Plane Wave assumption, there will be some 'delay_' b/w 8.5KHz source signal arriving at H1 and H2 assuming zero noise and pure sinusoidal signals. MATLAB script given below:

[CODE lang="matlab" title="two sensor array"]%%%%============================================================
%%%%====================Two Sensor Array Parameters========================
%%%%=======================================================================
D=15;%separation b/w sensors in m
c=1500;%in m/s
Target_theta=40;%Source angle in deg
delay_=D*sind(Target_theta)/c[/CODE]

The delay_ value calculated is around 0.0064s. The literature says we can estimate source angle by calculating the delay b/w two sensors (i.e. H1 & H2) using cross correlation techniques.

 

[FactChecker]

I am simulating signals on two hydrophones H1 and H2 of linear array which are at a distance 'd' from each other. The geometry is shown below:

View attachment 322134
Assuming Plane Wave assumption, there will be some 'delay_' b/w 8.5KHz source signal arriving at H1 and H2 assuming zero noise and pure sinusoidal signals. MATLAB script given below:

[CODE lang="matlab" title="two sensor array"]%%%%============================================================
%%%%====================Two Sensor Array Parameters========================
%%%%=======================================================================
D=15;%separation b/w sensors in m
c=1500;%in m/s
Target_theta=40;%Source angle in deg
delay_=D*sind(Target_theta)/c[/CODE]

The delay_ value calculated is around 0.0064s. The literature says we can estimate source angle by calculating the delay b/w two sensors (i.e. H1 & H2) using cross correlation techniques.

Find, but it is premature to apply your code to the actual problem when it is not working as expected.
At this time, I wouldn't worry about your ultimate application. See if it works on some simple cases.
You also might want to run the xcorr() program that finddelay uses and see what it gives you. That might make it obvious what is going on.

 

[FactChecker]

Hi
I have also tried with appended zeros of same length as that of signal but results does not match with delay_.
Thanks

Notice that the simple test cases where zeros are prepended are somewhat "rigged". The leading zeros hurt any crosscorrelation for any delay that is smaller than the true delay. Small delays are trying to correlate a lot of zeros with the real signal. So those test cases are easier to get right than normal applications will be.