lvanlys.dll Real IFT function change from version 6.1 to version 7

[rdanell]

I am aware that the dll file "lvanalys.dll" changed from LabVIEW version 6.1 to 7. Specifically I have found that the inverse real FFT function not only changed name but _seems_ to have changed in operation.

The version 6.1 function is called "ReInvFFTCx", the version 7 function is called "InvReNIFFTH". Due to the difficulty in building VIs that use the two different functions from the dll's, I have attached pictures of the output that is obtained from each function. I put the same magnitude and phase vectors into each IFT function and as shown the time domain signals as well as the power spectra are very different. I am hoping that someone that knows about these changes can verify that th
ere were some functionality changes made and furthermore can shed some light on what was done to test the new function that is included in version 7. The output from the version 6.1 function seems to be much more reasonable to me, especially considering the power spectra vs. the input magnitude spectra.

Any help on this issue would be greatly appreciated, but for now I am resorting to building my own VIs that use the old function, but this is certainly not convenient considering you have to keep track of he dll, etc.

[yrao]

From the input spectrum data (magnitude and phase), I can tell the complex input data to the inverse FFT is not "DFT Symmetric". In order to compute correct Real Inverse FFT, the input complex vector must be even symmetric on the real part and odd symetric on the imaginary part ( it is in the "DFT Symmetric" sense, please refer to any text boot regarding the FFT properties). For performance reason, the real inverse FFT will not check the symmetry of the input data. If the input data does not comply with the requirement for real inverse FFT, the result is not defined. Different Inverse FFT implementations may output different results in this case.

[rdanell]

I appreciate your response. The symmetry of the input data is clearly an issue that I was not aware of and overlooked. I have done some reading and modified the input signals so that the real portion has even symmetry and the imaginary part has odd symmetry. However, the time domain output is still different between the versions of the dll file and furthermore the power spectrum is still much worse with the version 7 dll than the version 6.1 dll as compared to the input frequency domain signal (see new PDF file attached below).

I can not be sure that there not something else wrong with my input, but I have to say that it seems like something is very wrong with the version 7 implementation of the Real IFT. I don't understand how NI could have mis
sed this, but if they did, I would think they would care a great deal about finding it as the FT is so instrumental in so many VIs within LabVIEW.

[LocalDSP]

Could you please post your actual benchmark VI with your input test data saved as default (or optionally embedded as constants on the block diagram) and we will of course take a closer look at the issues.

Thank you

[rdanell]

Thank you for taking a look at this issue. I am attaching the VI that I have built for testing this problem. The input data is saved as default in front panel arrays. This VI uses the standard FT algorithms in lvanlys.dll, for me this is the version 7 dll and so the output is "poor". I am assuming you have access to the version 6.1 dll to test its performance by inserting the proper subVI. Let me know if you need more information.

[LocalDSP]

I looked at your VI and found the mistake. As Yong mentions in his original answer, the two halves of your spectrum need to be complex conjugated, but you have to be careful in the management of the indices. The first bin at index 0 (dc) is not to be "duplicated". In other words if your half spectrum is composed of 4 points [a0, a1, a2, a3] all being complex values, the entire spectrum will be [a0, a1,a2,a3, 0, a3*, a2*, a1*] (where * represents the complex conjugate operation). The "zero" at Nyquist is added since your original half-spectrum was missing that point, but if it is available in your application use that value (that also has to be a real value).

I have corrected your VI to follow these rules and the result is now identical to your LabVIEW
6.1 result.

[rdanell]

Well that certainly did it. Thank you very much for your time in looking at this so quickly. This is definitely a point that I missed. It is interesting that LabVIEW 6.1 handled this error "okay", but I am happy to know the correct way to build the input waveform.

Thanks again.