Sampling and FFTs

[AliasAlreadyOnFile]

Hi all,

I'm having problems with FFTs. I'm using a USB-6008 DAQ device to collect acceleration data. No combination of inputs responds properly, however, and I think my understanding of the fundamentals is bad, or just wrong.

Here is what I think is right (and what isn’t right in the VI):

According to the Nyquist theorem I need to have a sampling rate (in samples per channel per second) that is equal to or greater than 2x the maximum frequency I want to observe to counter aliasing. In my VI I want it to be completely flexible, hence the multiplier and Fmax controls.

Example: With Fmax at 500Hz and a multiplier of 5.12 my sample rate is 2560 samples/second per channel. For three channels it’s 7680 samples/second. The time taken for one sample is 1/2560 = 39ms.

I created a control for the number of samples and set it to 1024. I’m a little hazy on exactly what the number of samples is but it sets the observation period: T(obs) = Number of samples / Sample rate. For the above example this would be 1024/2560 = 0.4s. We expect a bandwidth (frequency resolution) of 1/0.4 = 2.5s in the FFT. Exporting the data to excel from the FFT shows this is right.

All good so far…

The FFT shows a maximum frequency of half the sample rate, which is 1280Hz. I don’t know why? In the data file we can see this is equal to the number of lines x frequency resolution = 512 x 2.5. The number of lines is the number of samples / 2. I don’t know why?

I’m collecting FFT peak frequency and amplitude data also. The FFT plot consistently shows a peak at 50Hz, but the actual frequency it’s recorded at is wrong. This value is 50 / frequency resolution = 20Hz.

Ok, now to the main problem…

I reduce the number of samples to 512 and the frequency resolution updates to 5Hz, as expected. All other settings remain the same. I go back to the FFT and nothing has changed. The exported data has not changed either.

I changed the multiplier to 1.28 so the bandwidth is 1.25Hz and the sample rate is 640 Hz. Again nothing has changed. The max frequency the FFT shows should be half the sample rate at 320Hz but it’s still 1280Hz. Data exported from the FFT (and the FFT itself) shows max frequency of 1280Hz, a bandwidth of 2.5 and the 50Hz peak at 20Hz!

So now I restart LabVIEW and set the multiplier at 1.28, number of samples at 512 and Fmax (observed) at 500 and run the VI:

Now the frequency resolution is 1.25Hz, number of lines is 256 and the max frequency is 320Hz, half the sampling rate. All is as it should be, except for the frequency of the peaks, which need to be multiplied by the frequency resolution to get the correct values.

What’s going on?!

The DAQ Assistant is set up to read voltages between ±0.5V to increase resolution. Collection is set to N Samples but continuous samples produces the same results.

Feel free to comment on any other part of my VI too. I know it’s a bit of a mess, I’ve only been using LabVIEW for 3-4 weeks so consider it (and my understanding) a work in progress.

[johnsold]

---

With Fmax at 500Hz and a multiplier of 5.12 my sample rate is 2560 samples/second per channel. For three channels it’s 7680 samples/second. The time taken for one sample is 1/2560 = 39ms.

---

When you set the sample rate, it applies to all channels. So if you are sampling at 2560 S/s, then all channels are sampled at 2560 S/s. Many DAQ devices , including the USB-6008, have just one A/D converter which is multiplexed across all the channels. The A/D converter will of course do 7680 conversions per second.  They may not be equally spaced in time.  Some devices convert the three channels as fast as possible and then wait 1/fs before starting the next batch of conversions.  I do not know which method the 6008 uses.

1/2560 = 0.39 milliseconds = 390 microseconds.  Each of the three channels will be sampled once every 390 us.

---

I created a control for the number of samples and set it to 1024. I’m a little hazy on exactly what the number of samples is but it sets the observation period: T(obs) = Number of samples / Sample rate. For the above example this would be 1024/2560 = 0.4s.

---

The number of samples set the number of samples (for each channel) to be returned each time the DAQ Read VI is called.  You are correct that it will take 0.4 seconds to get that much data.

---

We expect a bandwidth (frequency resolution) of 1/0.4 = 2.5s in the FFT.

---

From the detailed help file for the FFT VI (which is used internally in all the spectrum VIs) the frequency resolution, df = fs/N = 2560/1024 = 2.5 Hz.  This is NOT the bandwidth.  There are several ways to define bandwidth.  The Nyquist bandwidth is < fs/2 = 1280 Hz.

---

The FFT shows a maximum frequency of half the sample rate, which is 1280Hz. I don’t know why?

---

That is the Nyquist frequency. The signal fed to the FFT must not have any energy at frequencies above the Nyquist frequency for the output of the FFT to be meaningful.

---

The number of lines is the number of samples / 2. I don’t know why?

---

The FFT VI produces an output with the same number of elements as the number of samples in the input. Half of those represent negative frequencies which come from the wat the FFT is defined mathematically. The single-sided spectrum VIs combine the positive and negative frequency elements to create a spectrum with only positive frequency components. So it has only half as many elements as the input.

---

The FFT plot consistently shows a peak at 50Hz, but the actual frequency it’s recorded at is wrong. This value is 50 / frequency resolution = 20Hz.

---

You did not save any data in the VI so I cannot see what is actually happening.  The Spectral Measurements VI should scale things correctly and the graph is set to austoscale.  What you see should be correct.

The Dynamic Data Type used by the Express VIs tends to obscure the structure of the data it contains.  That makes it more difficult to determine whether there is an error.

---

Ok, now to the main problem…

I reduce the number of samples to 512 and the frequency resolution updates to 5Hz, as expected. All other settings remain the same. I go back to the FFT and nothing has changed. The exported data has not changed either.  .....

I restart LabVIEW and set the multiplier at 1.28, number of samples at 512 and Fmax (observed) at 500 and run the VI:

Now the frequency resolution is 1.25Hz, number of lines is 256 and the max frequency is 320Hz, half the sampling rate.

---

Here I am guessing because I do not have the DAQ Assistant.  My guess is that it tries to be "smart" and not reconfigure each time through the loop.  When you restart the VI, it reads the controls and reconfigures the acquisition.

General comment: It is recommended to keep the size of the block diagram to one screen.  Yours is about four.  Duplicating code can become a maintenance nightmare. You need to make any required changes in several places.  Miss one and you have a problem.  Your X, Y, and Z code could be made into a subVI. Then three copies of it placed on your block diagram handle the three axies, take much less space, and only need to be changed one place if a bug is found or requirements change.

The sequence structure in the case structure at the right is not needed. Data flow will make it work the same way without the sequence.

Build Path is preferred over concatenating strings for creating the file paths.

Lynn

[AliasAlreadyOnFile]

Great response, Lynn! It's really helped me a lot, your advice prompted me to look for info in the right places and I've now dealt with a number of problems. To update:

The FFT plot consistently shows a peak at 50Hz, but the actual frequency it’s recorded at is wrong. This value is 50 / frequency resolution = 20Hz.

---

Solved the problem! The peak recorded should be the location output from the peak detect VI x df + f0, where f0 and df are the unbundled values from the FFT. The peak locations are correct in all cases now. 

I reduce the number of samples to 512 and the frequency resolution updates to 5Hz, as expected. All other settings remain the same. I go back to the FFT and nothing has changed. The exported data has not changed either.  .....

I restart LabVIEW and set the multiplier at 1.28, number of samples at 512 and Fmax (observed) at 500 and run the VI:

Now the frequency resolution is 1.25Hz, number of lines is 256 and the max frequency is 320Hz, half the sampling rate.

---

I thought previously that my settings and/or calculations were the cause of this problem but on looking at updating DAQ Assistant settings during running a VI (http://forums.ni.com/t5/LabVIEW/Why-doesn-t-the-graph-and-array-update-from-DAQ-Assistant-when/m-p/1...) it appears I'm wrong again 

General comment: It is recommended to keep the size of the block diagram to one screen.  Yours is about four.  Duplicating code can become a maintenance nightmare. You need to make any required changes in several places.  Miss one and you have a problem.  Your X, Y, and Z code could be made into a subVI. Then three copies of it placed on your block diagram handle the three axies, take much less space, and only need to be changed one place if a bug is found or requirements change.

 - It is getting a bit unwieldy, but I have a large monitor at work so it's just two screens  I'll make some subVIs nevertheless.

The sequence structure in the case structure at the right is not needed. Data flow will make it work the same way without the sequence.

 - I did it this way because both of the messages were being displayed before the file select prompts when I tested it. I wanted 'choose data file' message then choose the data file, then 'choose background file'  then I choose the file.

Build Path is preferred over concatenating strings for creating the file paths.

 - I'm not sure how Build Path would provide an improvement over how it's done now. Most of the concatenated string is for the filename and most of it is done in a few chunks using concatenation. Build Path has one path and one string input so I'd have to concatenate the filename anyway then wire it to the string input. Do I understand correctly?

Thanks!

[johnsold]

Sequence structure: That is one of the disadvantages of the Write to Spreadsheet FIle.vi. It does not have a file prompt input. If you use one of the file dialog VIs, you can set the prompt to indicate which file you want. Then wire the path out from that to the write VI.

I had not looked that closely at your VI as far as how you were building the filename. Build Path does some validation of characters allowed in paths.

Lynn