# What is the minimum number of time points recommended for accurate instantaneous phase estimates using the Hilbert transform

I have two time series. The two series look like they follow the same function, but one appears to lag slightly behind the other. I would like to determine if there are phase differences between the points in these time series, but each time series is only 4 points long. Is this enough data to get accurate phase differences using the Hilbert transform?

• Can you elaborate or link to a picture? What properties suggest to you they follow the same function or lag slightly, 4 points seems to small to say this. – geometrikal Aug 19 '15 at 6:46
• Define "accurate" quantitatively. Also if you know whether the signals are bandlimited or not? And within what band? – hotpaw2 Mar 9 '16 at 21:35

Forgive me for not having a numerical answer to the question. But here are a few things to think about. The answer depends on how the Hilbert transform (HT) is implemented. If the HT is implemented using an $N$-point tapped-delay line filter-like block diagram the first and last $N$-1 output samples are incorrect. So in this situation four input times samples is definitely not enough samples to produce useful results.

If HT is implemented by way of a forward FFT, zero the neg-frequency spectral components, and inverse FFT (as is done in Matlab) you have a better chance of computing meaning results. However, in this second implementation the input time sequence must be long enough to contain at least one cycle of all the spectral components of your input signal in order to compute somewhat meaningful results. It seems to me that four times samples is too short to reliably estimate any signal parameters of most real-world (information-carrying) signals.

• Because the Hilbert transform has an infinite impulse response, If you implement the Hilbert transform using the FFT you will introduce time-domain wrap around effects, so in essence all your time domain samples will be corrupted due to the periodic wrapping of the infinite impulse response. Essentially it's the same reason you don't implement a brickwall filter in the frequency domain. – David Dec 17 '15 at 16:15
• Implementing an HT in the freq domain does not involve any kind of freq-domain multiplication to implement time-domain convolution. Implementing an HT in the freq domain is performed as follows: (1) perform an FFT on a real-valued input sequence; (2) setting the negative-frequency spectral magnitude and phase samples to zero; (3) performing an inverse FFT on the modified spectral samples to produce the desired analytic signal in time domain. No "time-domain wraparound" problems occur in this case. – Richard Lyons Dec 18 '15 at 19:38
• Setting one side to zero and leaving the other side is the same as multiplying it by a filter that has zeros in the negative frequency portion and is unity in the positive frequency - the impulse response that corresponds to this filter is infinite - therefore time domain wrap around will occur. The advantage in the frequency domain is you don't have to deal with the group delay. – David Dec 18 '15 at 22:41
• David: I'm thinking of the scenario where in software, for example, we generate a 32-sample cosine sequence containing exactly two sinusoidal cycles. Then we perform a 32-FFT on that sequence and set the 31st spectral sample to zero. Finally, we perform a 32-point inverse FFT on the modified spectral samples. That will produce a complex (analytic) 32-sample time-domain sequence whose real part is a two-cycle cosine sequence and whose imaginary part, a two-cycle sine wave, is the HT of the real part. The final time sequence is not infinite in length and no wrap-around error occurs. – Richard Lyons Dec 19 '15 at 18:54
• The Sinc function impulse response is sampled as zero in the time domain wrap around distortion only for exactly integer periodic in aperture waveforms. Otherwise, the Sinc is offset, and thus samples as non-zero, wrapping around. So an exactly 2 cycle sinusoid is a special case. Zeroing bins in an FFT produces the exact same problems/artifacts for both attempted brick-wall filtering and for trying to create a Hilbert transform. See: dsp.stackexchange.com/questions/6220/… – hotpaw2 Feb 15 '16 at 21:08

The answer depends on the signal to noise ratio and whether the signal is a single sinusoid that is integer periodic in a window that number of samples in length. Or perhaps a number of pure integer periodic sinusoids that is low enough compared to N/2.

The a-priori bandwidth of the signal would also need to be small enough with respect to the number of samples, otherwise aliasing ambiguity leads to phase ambiguity.

A Hilbert transform doesn't magically add information to frequency estimation methods. And frequency estimation errors lead to phase estimation errors.

I would not recommend that, because, 4 points may not describe your signal really well. These 4 points can be coming from anywhere. To experiment with that I wrote the following extremely simple code:

% generate a signal
x = cos(pi/4*(0:99));
y = hilbert(x);
sigphase = (unwrap(angle(y)))';
X = ones(length(sigphase),2);
X(:,2) = (1:length(sigphase))';
beta = X\sigphase;
beta(2)


beta(2) will be very close to the frequency. If you generate x using:

x = cos(pi/4*(0:3));


you will immediately see that the frequencies do not match. This is of course a tough one due to the cosine signal, but there might be ambiguous cases, similar to that one.

Why don't you use a running correlation analysis instead?