From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

fft consistency

Hi,

I'm working on a program to measure the frequency of the specular beam in a diffraction pattern with a small cmos camera and labview.  The problem I'm having is with repeatability of the measurement.  For testing purposes I'm using an LED and a function generator at 500 mHz nominal.  The primary frequency in my FFTs, though, range from 450 mHz to 560 mHz (i.e. ~10% error).  I've tried to eliminate mechanical variation by not moving the camera between runs and by using some code to analyze the same pixels each time but still get the variation.  Has anyone else ever had similar consistency issues?  I've tried playing with the interpolation and FFT window a bit, but things still keep drifting around (the best combination so far seems to be cubic hermite interpolation with a Hanning window).  From my basic understanding of FFT's the window should really only be changing the shape of the peak, not its position, but I'm not really sure how much the different type of interpolation would affect subsequent frequency measurements.  Just for some more background, I'm using the FFT power spectrum vi and the interpolate 1D vi.  Thanks,

 

John

0 Kudos
Message 1 of 7
(2,825 Views)

Hi drummerguy,

 

If I understand correctly, you want to detect the prime frequency of the signal. So maybe you could try this VI: Extract Single Tone Information VI, it will return more precise result than FFT spectrum VI. 

0 Kudos
Message 2 of 7
(2,812 Views)

John,

 

Please post your code.  I can think of several things which might cause something like what you have described.  But without the code I and everyone else is guessing.  Please run your VI and Make Current Values Default.  Save the VI and then post it.  That way it includes data so we can check it without a camera.

 

What is your sampling rate?  How many samples are you analyzing at a time? Those things determine your frequency resolution and range.  Have you tried simulating the pixels and checking the FFT of that?

 

Lynn

0 Kudos
Message 3 of 7
(2,793 Views)

Thanks for the responses guys.  Here's the vi - I tried to include a few comments to make it easier to follow.  I finished my mount for the camera and put a box over the whole thing, so there isn't any stray light or mechanical motion that is getting into the system.  You can also see from the cursors on the intensity data that the frequency is clearly .5Hz, but the FFT is still having problems.  What is strange is that I do what I believe is the same interpolation and use the same window in Origin and get much closer to .5Hz every time (in this case I get .496Hz).  So I guess my conclusion is that there is a problem somewhere in my code, but I'm not really sure what it might be.


John

0 Kudos
Message 4 of 7
(2,772 Views)

Hi John,

 

Do you have a more accurate way of getting the time of the image acquisition other than the Tick Count.vi.  This VI relies on the Windows system clock, which doesn't always have the finest grain of accuracy.  There is also going to be slight variation in the amount of time it takes to get from the acquisition to the Tick Count.vi, which will also cause some inaccuracy in timing.  This could be the cause of the variation in your FFT.

Jared S.
Applications Engineering
National Instruments
Message 5 of 7
(2,747 Views)

Hi Jared,

I'm not sure I completely follow you - are you talking about using some external time signal, or is there a more reliable timing vi to use?  Because it is my understanding that all of the timing vi's use the Windows clock, and regardless of the vi there will always be a lag between when the acquisition vi runs and the tick count vi runs.  This amount of lag shouldn't be a big deal for my application because the frequency I am going to be detecting ultimately will usually be around 1Hz or sometimes around .5Hz - so there are a whole bunch of data points taken in each period, so the lag errors should be comparatively tiny.  What I have found so far is that the interpolation makes a big difference in where the FFT peak shows up - say I use the same dataset and go from using 2 interpolated points for each raw data point to using 3 interpolated points, the frequency peak can sometimes shift from say .45Hz to .55 Hz - unfortunately it does so rather randomly so I haven't been able to pick an optimal number of interpolated points.

0 Kudos
Message 6 of 7
(2,734 Views)

So I think I found a slightly different solution that gives me good accuracy (my error is typically less than 1%), that is slightly more complicated  - I thought I would post it here for anyone having similar troubles in the future.  Since my FFT's were always better in Origin (I'm using OriginPro 8.0 SR6 - make sure to get all the updates if you use Origin - there are a lot of serious bugs), I just decided to use Labview to send the raw data to origin and autoupdate an Origin project that I set up to interpolate the raw data with a cubic spline interpolation, do an FFT with a Blackman window, and then do an interpolation on the amplitude vs. frequency data (with a bunch of points) to smooth out the signal peak (without the interpolation I typically only had two or three data points around the peak so it was hard to consistently decide where the center was).  I attached my final VI and the Origin workbook in case anyone ends up trying to do something similar.

 

John

0 Kudos
Message 7 of 7
(2,725 Views)