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?
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’:
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).
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
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.
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.
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.