09-18-2009 10:57 AM
Solved! Go to Solution.
09-18-2009 12:05 PM
Mr. rock,
To get an accurate measure of the frequency of your signal, yes, you would sample greater than 2x its frequency, so 50 KHz would be sufficient. On the other hand, for an accurate depiction of what the signal looks like, you'd want to sample roughly 10x the expected frequency.
Each channel on the 6111 can sample at 5M/s, so you're well within its spec.
09-18-2009 12:27 PM
09-18-2009 12:38 PM
Hi rocksolidsr,
50 kHz would be the bare minimum to pick out the frequency components of your 25 kHz signal, but I'd recommend sampling at least at 250 kHz to better characterize the waveform. This is actually a relatively slow sample rate since the 6111 is capable of up to 5 MHz per channel.
At these rates we can transfer data across the PCI bus while the acquisition is taking place so we never overflow the device's on-board memory (the driver handles this for you). The data is stored in a DMA buffer until it is brought into LabVIEW memory with a DAQmx Read call.
I suggest looking in the following folder for examples:
Help >> Find Examples... >> Hardware Input and Output >> DAQmx >> Analog Measurements >> Voltage >> ...
The exact example to start with will depend on how you intend to trigger the signal. I suggest trying Acq&Graph Voltage-Int Clk-Analog Start w Hyst.vi so you can trigger off of the analog input signal. You might want to use a reference trigger instead of a start trigger--this would allow you to retrieve samples from before the trigger actually takes place. If you are triggering off of a digital edge there are examples for this as well.
Not that you necessarily need to, but you could actually acquire continuously up to the full rate of the card on the 6111 (2 channels * 5 MHz per channel * 2 Bytes per Sample = 20 MB/sec of data). You can typically sustain ~80 MB/sec across the PCI bus.
09-21-2009 08:41 AM
09-23-2009 11:10 AM
Hi rocksolidsr,
The easiest way to scroll through the data/zoom in on certain parts would be to use the Graph Palette. Just right-click on the waveform graph and select Visible Items >> Graph Palette. This will give you a toolbox that provides zoom/scroll functionality.
As far as measuring the frequency at a certain point, this gets a little bit trickier. Here's one way to do it:
Calculate Frequency of Signal Displayed on Waveform Graph
You can use the above function as a sub-vi (put it in a loop like in the example on the community page) to calculate frequency based on the visible signal on your waveform graph. The resolution of the frequency measurement is going to be based off of your sample clock rate--it counts the number of samples between zero crossings and inverts to determine frequency. With this in mind, you might want to go with a higher sample rate (play around with it until you get the resolution you need).
Also, are you using the on-board counters of the 6111? If not, another option would be to implement something similar in hardware using a counter. The counters on the 6111 have a 20 MHz timebase and would yield a more accurate frequency measurement. I haven't tested this out yet, but what I would try if you want to go this route would be to set up an Analog trigger (like the original shipping example we mentioned), then take a buffered frequency measurement of the Analog Comparison Event.
There are shipping examples for the counters that show how to configure a frequency measurement, you might want to take a look at a few of the examples in the DAQmx >> Digital Frequency--I can help you out if you run into any issues. The hard part would be correlating the array of frequency measurements to the region of the graph that you are zoomed in on. It may not be worth the trouble to look into this if you are satisfied with the results of the software method.
Best Regards,
John
09-23-2009 02:55 PM
I tried that example you sent me but when I wire the "Measurement" to the Calculate frequency it says that the two data types don't match and I can't figure out why. Any ideas here is my code
09-23-2009 03:54 PM
Oops, sorry about that. I actually developed the code in LabVIEW 2009 then noticed after the fact that you were using 7.1 and had to downconvert. It looks like there is a discrepancy with the datatypes in the new version of the code.
I'll post a version of the sub-vi for both LabVIEW 7.x and LabVIEW 8.x.
-John
09-23-2009 04:10 PM
The community site seems to be not allowing me to upload new code at the moment--in the meantime try this VI:
09-24-2009 07:35 AM