-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nafflib problems #40
Comments
Tried the default example from calcnaff and got the same phases each time. Also tried it on some BPM data. I couldn't repeat the problem for AT2.0. nafflib.c revision date 25/7/2017. You can use it for just real signals and the phases be also be correct (taking only the positive frequencies). However for the amplitude you have to sum the positive and negative frequency amplitudes to get it right. Or you can simply multiply by a factor of 2 if the frequency is not zero or fs/2. |
Dear @carmignani, If you run the nafflib algorithm with a real signal, its works well for me.
The phase is stable and the amplitude of each harmonic is 0.5 as expected. |
Nevertheless, I suspect something wrong the in the c-library, since sometimes, the function returns NaNs for valid input signal. I need to run the code in debugger to understand. This is quite annoying and time consuming to debug. |
I get exactly the same output running the example you wrote, but if I run it many times sometimes I get nans. |
* Fixes bug producing infrequent NaN from calcnaff Fixes #40 * Update calcnaff.m The second test for NaN was wrong Y was replaced by Yp --------- Co-authored-by: Patrick Schreiber <patrick.schreiber@synchrotron-soleil.fr> Co-authored-by: Laurent S. Nadolski <nadolski@synchrotron-soleil.fr>
Hello,
I tried to use the calcnaff function that we have in the nafflib directory and I found some problems.
If I run the function to analyze the same signal two times I get the same frequencies, but the phases are every time different.
A second issue about the function is that it requires a complex signal, so it cannot be used with real bpm measurements. We could give a vector of zeros as imaginary part of the signal, but then I don't know if we can trust the results.
The text was updated successfully, but these errors were encountered: