LabVIEW
FFTW on LabView
Q<UL wrote: ... I do not apply any window restriction of any sort to my data on LabView, but instead I only read the TXT files that contain the data and feed it to FFT.
Looking at the code you posted, I am pretty sure you're really applying a window before the FFT. Maybe things change if you wouldn't. 😮
(Of course it would be easier to see if the code were a bit cleaner. You have wires going in all direction! ;))
Message Edited by altenbach on 02-01-2007 05:10 PM
Also here (The "window" control is set to hanning by default, so that's what you would get unless you actively change it):
Message Edited by altenbach on 02-01-2007 05:59 PM
Looked quickly at the Python script, and it looks like the SetY() function is applying a cosine sqsuared weighting. YAV is the variable that is passed to the FFTW function shortly after the SetY function returns.
There will be some numerical differences between the LabVIEW FFT implementation and FFTW, if only because the order of the operations and algorithm may be different. However, the differences should not be in the first few significant digits but much farther out, and I would be surprised if the different FFT results were the cause of your problem. If you want additional verification write a simple Python script to generate a sequence of numbers, and compare the FFTW results to the same LabVIEW FFT of the identical sequence. Doing this should allow you to eliminate the FFT as the probable source of your problem, or not, in which case please do post your results so I can investigate further.
-Jim
for i in range(n):I wasn't overly careful in following the function calls, but it looks like this is the culprit. Because the python script is giving the results you expect I would suggest implementing this weighting function exactly in LabVIEW, then call the FFT without any additional windowing.
A = math.cos(i*math.pi/n) # Unity weighting on first point (ZPD)
Wt = A*A
YW.append(Wt)
YAV.append((YRAW[i] - Ymean)*Wt)
There will be some numerical differences between the LabVIEW FFT implementation and FFTW, if only because the order of the operations and algorithm may be different. However, the differences should not be in the first few significant digits but much farther out, and I would be surprised if the different FFT results were the cause of your problem. If you want additional verification write a simple Python script to generate a sequence of numbers, and compare the FFTW results to the same LabVIEW FFT of the identical sequence. Doing this should allow you to eliminate the FFT as the probable source of your problem, or not, in which case please do post your results so I can investigate further.
-Jim
range(n) means [0,1,2,...,n-1], so i iterates from 0 to n-1
A will take on values: cos(1*pi/n, cos(2*pi/n), cos(3*pi/n), ..., cos( (n-1)*pi/n
and Wt will be A*A
YW is an array containing each value of Wt.
I have attached a simple VI that just implements the following lines of the python script:
I didn't try to figure out the context of this weighting wrt the rest of the script; there may be some buffer manipulation (shift or rotate) that changes things. It seems odd to me to window with a cosine this way. The first and last points have the greatest weights, while the middle of YRAW is weighted the least. Normally the weighting is done as 1-cos(), so the endpoints are weighted least, with the middle of the buffer weighted the most.
Translating from one language to another can be tedious and problematic. Through much pain (banging my head on any available flat surface
), tribulation, and wasted time I have learned to break off manageable and verifiable pieces of the translation b y mapping function calls directly to VI calls. Your python script is already nicely broken into function calls; debugging the equivalent G code might be easier if you duplicated the functions as subVIs. Just a thought.
Anyway, maybe this will help get you closer.
-Jim
A will take on values: cos(1*pi/n, cos(2*pi/n), cos(3*pi/n), ..., cos( (n-1)*pi/n
and Wt will be A*A
YW is an array containing each value of Wt.
I have attached a simple VI that just implements the following lines of the python script:
Ymean = sum(YRAW)/len(YRAW)
n = len(YRAW)
YW=[]; YAV = []
# Use Cos-squared weighting.
for i in range(n):
A = math.cos(i*math.pi/n) # Unity weighting on first point (ZPD)
Wt = A*A
YW.append(Wt)
YAV.append((YRAW[i] - Ymean)*Wt)
I didn't try to figure out the context of this weighting wrt the rest of the script; there may be some buffer manipulation (shift or rotate) that changes things. It seems odd to me to window with a cosine this way. The first and last points have the greatest weights, while the middle of YRAW is weighted the least. Normally the weighting is done as 1-cos(), so the endpoints are weighted least, with the middle of the buffer weighted the most.
Translating from one language to another can be tedious and problematic. Through much pain (banging my head on any available flat surface
), tribulation, and wasted time I have learned to break off manageable and verifiable pieces of the translation b y mapping function calls directly to VI calls. Your python script is already nicely broken into function calls; debugging the equivalent G code might be easier if you duplicated the functions as subVIs. Just a thought.Anyway, maybe this will help get you closer.
-Jim
