DSPRelated.com
Forums

fft phase in matlab

Started by ganesh August 24, 2011
hi,
  If I do an FFT of a signal in matlab, and extract the phase/angle,
it is very noisy. It does not seem to reflect the true phase of the
signal. Is there any way by which the actual phase can be extracted?


thanks
Ganesh
On Aug 24, 12:05&#4294967295;pm, ganesh <ganeshs...@gmail.com> wrote:
> hi, > &#4294967295; If I do an FFT of a signal in matlab, and extract the phase/angle, > it is very noisy. It does not seem to reflect the true phase of the > signal. Is there any way by which the actual phase can be extracted? > > thanks > Ganesh
You need to compensate for the start time of your FFT window. The FFT results are relative to this, NOT time zero.
Hi,

I'm guessing here, but most likely you're looking also at bins where signal
energy is low, and / or it wraps around periodically.

You can find one solution to unwrap the phase across "gaps" in the power
spectrum here:
http://www.dsprelated.com/showcode/207.php

On Aug 24, 4:35&#4294967295;pm, davew <david.wo...@gmail.com> wrote:
> On Aug 24, 12:05&#4294967295;pm, ganesh <ganeshs...@gmail.com> wrote: > > > hi, > > &#4294967295; If I do an FFT of a signal in matlab, and extract the phase/angle, > > it is very noisy. It does not seem to reflect the true phase of the > > signal. Is there any way by which the actual phase can be extracted? > > > thanks > > Ganesh > > You need to compensate for the start time of your FFT window. &#4294967295;The FFT > results are relative to this, NOT time zero.
I'm actually taking the difference in angle of two signals (angle of cross spectrum). Hence in this case, the start time should cancel out right?
On Aug 24, 10:09&#4294967295;am, ganesh <ganeshs...@gmail.com> wrote:
> On Aug 24, 4:35&#4294967295;pm, davew <david.wo...@gmail.com> wrote: > > > On Aug 24, 12:05&#4294967295;pm, ganesh <ganeshs...@gmail.com> wrote: > > > > hi, > > > &#4294967295; If I do an FFT of a signal in matlab, and extract the phase/angle, > > > it is very noisy. It does not seem to reflect the true phase of the > > > signal. Is there any way by which the actual phase can be extracted? > > > > thanks > > > Ganesh > > > You need to compensate for the start time of your FFT window. &#4294967295;The FFT > > results are relative to this, NOT time zero. > > I'm actually taking the difference in angle of two signals (angle of > cross spectrum). Hence in this case, the start time should cancel out > right?
Part of your results will depend on the bandwidth of the signals. If they are pure sinusoids then only a couple of FFT bins contain relevant phase information. As the signals increase in bandwidth more and more FFT bins will be relevant. The start times won't matter until (too much) until the delay between them becomes significant with respect to the size of the FFT. David
On Wed, 24 Aug 2011 07:09:42 -0700, ganesh wrote:

> On Aug 24, 4:35&nbsp;pm, davew <david.wo...@gmail.com> wrote: >> On Aug 24, 12:05&nbsp;pm, ganesh <ganeshs...@gmail.com> wrote: >> >> > hi, >> > &nbsp; If I do an FFT of a signal in matlab, and extract the phase/angle, >> > it is very noisy. It does not seem to reflect the true phase of the >> > signal. Is there any way by which the actual phase can be extracted? >> >> > thanks >> > Ganesh >> >> You need to compensate for the start time of your FFT window. &nbsp;The FFT >> results are relative to this, NOT time zero. > > I'm actually taking the difference in angle of two signals (angle of > cross spectrum). Hence in this case, the start time should cancel out > right?
Not necessarily. Only if your window is synchronous with some external reference event. Consider a pair of signals, one with frequency 3/N and the other with frequency 7/N, where N is the number of points in the FFT. Every time you advance your window by one sample, the relative phase of the two signals will advance by 2 * pi * 4 / N radians. So if you're starting your data collection randomly, then that relative phase will appear to be random also. -- www.wescottdesign.com
On Aug 24, 6:08&#4294967295;pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Wed, 24 Aug 2011 07:09:42 -0700, ganesh wrote: > > On Aug 24, 4:35&#4294967295;pm, davew <david.wo...@gmail.com> wrote: > >> On Aug 24, 12:05&#4294967295;pm, ganesh <ganeshs...@gmail.com> wrote: > > >> > hi, > >> > &#4294967295; If I do an FFT of a signal in matlab, and extract the phase/angle, > >> > it is very noisy. It does not seem to reflect the true phase of the > >> > signal. Is there any way by which the actual phase can be extracted? > > >> > thanks > >> > Ganesh > > >> You need to compensate for the start time of your FFT window. &#4294967295;The FFT > >> results are relative to this, NOT time zero. > > > I'm actually taking the difference in angle of two signals (angle of > > cross spectrum). Hence in this case, the start time should cancel out > > right? > > Not necessarily. &#4294967295;Only if your window is synchronous with some external > reference event. > > Consider a pair of signals, one with frequency 3/N and the other with > frequency 7/N, where N is the number of points in the FFT. &#4294967295;Every time > you advance your window by one sample, the relative phase of the two > signals will advance by 2 * pi * 4 / N radians. &#4294967295;So if you're starting > your data collection randomly, then that relative phase will appear to be > random also. > > --www.wescottdesign.com- Hide quoted text - > > - Show quoted text -
I think the other major problem here is that all this rather depends on your signal fitting neatly into an FFT bin. If it doesn't (most likely I would have thought) then this method of taking phase directly from the frequency-phase bin is likely to be error-prone.
On Wed, 24 Aug 2011 10:22:49 -0700, davew wrote:

> On Aug 24, 6:08&nbsp;pm, Tim Wescott <t...@seemywebsite.com> wrote: >> On Wed, 24 Aug 2011 07:09:42 -0700, ganesh wrote: >> > On Aug 24, 4:35&nbsp;pm, davew <david.wo...@gmail.com> wrote: >> >> On Aug 24, 12:05&nbsp;pm, ganesh <ganeshs...@gmail.com> wrote: >> >> >> > hi, >> >> > &nbsp; If I do an FFT of a signal in matlab, and extract the >> >> > &nbsp; phase/angle, >> >> > it is very noisy. It does not seem to reflect the true phase of >> >> > the signal. Is there any way by which the actual phase can be >> >> > extracted? >> >> >> > thanks >> >> > Ganesh >> >> >> You need to compensate for the start time of your FFT window. &nbsp;The >> >> FFT results are relative to this, NOT time zero. >> >> > I'm actually taking the difference in angle of two signals (angle of >> > cross spectrum). Hence in this case, the start time should cancel out >> > right? >> >> Not necessarily. &nbsp;Only if your window is synchronous with some external >> reference event. >> >> Consider a pair of signals, one with frequency 3/N and the other with >> frequency 7/N, where N is the number of points in the FFT. &nbsp;Every time >> you advance your window by one sample, the relative phase of the two >> signals will advance by 2 * pi * 4 / N radians. &nbsp;So if you're starting >> your data collection randomly, then that relative phase will appear to >> be random also. >> >> --www.wescottdesign.com- Hide quoted text - >> >> - Show quoted text - > > I think the other major problem here is that all this rather depends on > your signal fitting neatly into an FFT bin. If it doesn't (most likely > I would have thought) then this method of taking phase directly from the > frequency-phase bin is likely to be error-prone.
There is a whole lot of detail lacking, isn't there? I'm not sure the "must fit into an FFT bin" is required, though. I _do_ think you'd need some sort of overall synchronization, and if the results didn't fit neatly into FFT bins then you'd have some head-scratching to do to figure out just what the phases _meant_. -- www.wescottdesign.com
>> I'm actually taking the difference in angle of two signals
Hello, one way to handle this is to multiply the spectrum of one signal with the conjugate of the other signal's spectrum. Effectively, this rotates each bin backwards by the angle of its counterpart. Then take the IFFT and look for the peak. Looked at in the time domain, multiplication becomes convolution, conjugation becomes time reversal and the whole procedure turns into matched filtering. Simply look for the peak, and that's where your signals are best aligned within one sample duration. To get closer than one sample, zero-pad arbitrarily before taking the spectrum. Or use the method from the link I sent earlier, if it needs to be accurate (in the noise-free example, it hits the spot within a billionth of a sample).