LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Checking if sample rate is correct

Hello,

 

I am creating a program that allows measurement of simple and choice reaction time. In my main loop is the DAQmx acquisition of 4 channels plus keyboard stroke input. In my secondary loop, I am controlling the display of an LED either at a random or fixed interval. This loop sends via Notifier, what stage the LED is in (wait, user input, complete) to the main loop. Out of curiosity, I added some code to determine elapsed time using the tick count vi. Looking at my written file, I noticed the written elapsed time was inconsistent with the sample rate input for the DAQmx vi's. Could someone explain to me why I am seeing this and if my written data is collected at the 1000 Hz specified? Does the notifier affect the sampling?

 

I am using a simple NI USB 6001 DAQ device.

 

Thanks in advance.

 

Anton

Download All
0 Kudos
Message 1 of 17
(3,735 Views)

Get rid of the delay in the acquisition loop.  Let your DAQmx task dictate your loop rate.  Since you have an acquisition rate of 1 sample in a ms, you are actually getting old data.  This will ensure the DAQ data is accurately clocked in without getting too far behind.  But anything timed by Windows will not be accurate.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 17
(3,713 Views)

Thanks for the prompt reply. So 1) I can get rid of the wait function and 2) can I also get rid of the calculated elapsed time? I added this in just to see if my sampling was affected by the notifier but based on your answer, my sampling rate is correct and this elapsed time is just misleading/inaccurate correct?

0 Kudos
Message 3 of 17
(3,707 Views)

The elapsed time will show if your loop is being slowed down by something else, such as saving the data to the TDMS file.  If that is the case, then you might want to look into a Producer/Consumer setup.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 17
(3,704 Views)

Okay so I have put the writing into a separate loop and that has reduced the variability but there is still some inconsistencies in sampling. Looking at the TDMS file, the initial difference between sample 1 and 2 is about 8 ms and then subsequent samples range from 0-2 ms. Again this time is from the elapsed time was put in just to examine timing and sampling (and will be removed later). Could my acquisition loop (middle) be affected by the notifier or build of string array? Am I truly sampling at the 1000 Hz? Future use of this program will be using rates up to ~2000 Hz so I want to make sure I am actually sampling correctly.

 

Thanks in advance

Download All
0 Kudos
Message 5 of 17
(3,682 Views)

Your DAQ should be able to sample that fast, but I don't think you are going to get your keyboard status that quickly.  Since you are using TDMS, I would save the DAQ data to one group and the keyboard status to another.  Just note that your keyboard status will never be consistently timed just because it is Windows polling, which is very non-deterministic.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 6 of 17
(3,662 Views)

Thanks for the advice. What would your suggestion be if I eventually wanted to merge those two TDMS files together? The keyboard data is being collected so we have temporal resolution of when a reaction (press space bar when LED flashes) occurs. I was hoping to extend this base code to other setups such as reading DAQ and Bluetooth IMUs simultaneously.

 

Thanks in advance

0 Kudos
Message 7 of 17
(3,656 Views)

@atrinh wrote:

Thanks for the advice. What would your suggestion be if I eventually wanted to merge those two TDMS files together?


No.  You use the same TDMS file.  You just write to different groups in the TDMS file.  So have different loops for each type of acquisition (a DAQ loop, a Keyboard loop, etc).  They all send their data to the logging loop through the same queue.  Make the queue type a cluster with a string and a variant.  With the string, you state which group you are writing to.  The variant can be any data.  So you just use Variant To Data to interpret the data however you need to.  Do not use strings to save your data to the TDMS file as that just limits the processing capabilities of the file type.  For the DAQ, I highly recommend using the Array of Waveforms output of the DAQmx Read and just use that when writing to the TDMS file.  It will take care of a lot of things for you that way.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 8 of 17
(3,650 Views)

Could you give me an example where two acquisition loops share the same queue? I am not sure I fully picture what that would look like.

0 Kudos
Message 9 of 17
(3,638 Views)

@atrinh wrote:

Could you give me an example where two acquisition loops share the same queue? I am not sure I fully picture what that would look like.


 


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 10 of 17
(3,630 Views)