LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Inverse FFT's

I am using Fourier Transforms to filter a signal I have. I noticed that for one perticular waveform the waveform returned after the inverse transform was performed was messed up. In the course of finding the problem I step up the filter so it would not filter the signal at all. The waveform returned is still wrong. ie has real and imaginary part. I have used this program on a number of waveforms and never encountered this problem before. Anybody have similar experience?
0 Kudos
Message 1 of 9
(4,483 Views)
The IFFT in LabVIEW 7.0 requires you to enter the complete complex input array, that is also including the complex conjugate "mirrored" array. Earlier versions of LabVIEW were assuming your array to be complex conjugated so this was optional.

So if you want your N samples to be real, you have to make sure your complex input array also contains N samples and that H(n) = H*(N-n) and that H(0) and H(N/2) are real.

See for example the following exchange and associated examples on how to implement this correctly.

http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=506500000008000000F9BD0000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0
0 Kudos
Message 2 of 9
(4,483 Views)
I am using LabVIEW6.1 and making my real set of data complex by adding an imaginary part equal to zero. This works for every other sample waveform I have tested. I.e Take the data, make it complex, perform FFT and then perform IFFT. The waveform at the end is the same as the start. Which is why I believed that the fourier transform operation was working. But this set of data gets altered at some point so when the IFFT is performed it returns a complex array.
0 Kudos
Message 3 of 9
(4,483 Views)
You don't have to make your time data complex by adding an imaginary part that is zero, just use the Real FFT.vi. This VI takes your real time domain data and returns the complex spectrum. Likewise the Real IFFT.vi will take your complex spectrum in and return a real time signal that is equal your original signal.

The attached VI is doing this on a random input signal and it seems to work fine.

If you are using the Complex IFFT.vi the output data will be complex, but the imaginary part very small compared to your real data (typically a ratio of 1E-15 to 1E-16). Is this what your see?
0 Kudos
Message 4 of 9
(4,483 Views)
Thanks for the vi. I ran two waveforms threw your vi. The one that I'm have problems with and one of the normal ones. The error still occurs for the problem waveform. I got an error of around .2 to 1.5 between before and after. The standard waveform gives an error of about 1E-16 like you said.
I have attached the waveform data incase there is something obvious I am missing.
0 Kudos
Message 5 of 9
(4,483 Views)
You are right, there is a problem. The problem is caused by a bug in the FFT VI in LabVIEW 6.1. It does not compute correctly when the number of input samples is a "big" prime number (in your case 59981 samples).

The work around is to add a "dummy" sample at the end of your time signal before you perform the FFT and remove that last sample at the output of the IFFT.
0 Kudos
Message 6 of 9
(4,483 Views)
I just ran your problem waveform through REAL FFT and INVERSE REAL FFT, subtracted the difference and got an error of 7 e-11 on the DC term, and all other errors are on the order of e-14.

LabVIEW 7 Mac OS X
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 7 of 9
(4,483 Views)
making my real set of data complex by adding an imaginary part equal to zero.

Not sure why you're doing that instead of usinig REAL FFT and INVERSE REAL FFT.

Are you sure you're generating the imaginary array the same length as the real array?
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 8 of 9
(4,483 Views)
That solved the problem. It was just a coincidences that the number of data points was a prime. Adding another data point resolved the problem.
Thanks
0 Kudos
Message 9 of 9
(4,483 Views)