FFT - real phase shift degree

1

Hello,
When I calculate from FFT the phase shift like that:
atan2(fft.imag(),fft.real()) * 180 / M_Pi

It always gives me the value between -180° and +180°. And when phase is shifted further, for example +181°, it suddenly becomes -179°. Which is untrue - phase was not shifted back.

Of course that results are understand for me, I just use pure atan2() so I can’t expect anything else. I need to update it. I think it should be something like that:
(atan2(fft.imag(),fft.real()) * 180 / M_Pi) + (n * 180)

But the question is, how can I find n from my FFT calculations?

2

If you want to get a phase without any jumps, you have to unwrap it. That’s what my google bubble came up with when I searched for ‘phase unwrapping’:

https://www.ljmu.ac.uk/~/media/files/ljmu/about-us/faculties-and-schools/tae/geri/onedimensionalphaseunwrapping_finalpdf

Btw: a phase of +181 is equal to -179°, nothing untrue about that. However, those jumps could lead to an a-causal group delay, so you have to first unwrap the phase before calculating it (in case you want to do that).

3

OK, great thanks.

4

Ok, I tried to find what does mean in Matlab x[i:end] but can’t find
Does it make a loop in place from i to the last member of x?

5

Just follow the steps starting on the bottom of page 2 to implement it, it’s quite simple.
That Matlab operator is indexing, it selects a range of that array: from the i-th element to the end of the array.

6

OK, I found out it, thanks. But unfortunately that algorithm works only for for higher (next) frequencies. For example if my first freq bin is shifted backward -190°, the algorithm doesn’t know that, so it prints +170°. So for high pass filters it works crazy. Or I do something wrong. But for higher frequencies it works perfect for me.

7

Hmm, I think I’ve found the idea. I will just count all iterations of 2*M_PI add/sub, and then I just move whole graph up or down about that number * height of screen.