Timing Problem in Data Acquisition

[akash90]

Hello 🙂

I'm having a problem with my VI while doing data acquisition. I am trying to acquire data from a function generator for a specific interval of time (say 2 seconds) and writing it to an array. For a given sample rate of 2560 S/s and no. of samples = 256, I have a buffer of 0.1 seconds.

When I run this for 2 seconds, I should be getting 5120 samples (256 samples per 0.1 second, multiplied by 20). However, I get 4864 samples sometimes(which tells me that the data was read 19 times instead of 20) and 5120 at times.

There seems to be a basic mistake somewhere with the timing logic, can someone please help me out with that?

I'm attaching the VI and a sub VI of my program.

Thanks in advance 🙂

[Norbert_B · Accepted solution]

This is expected behavior. You are running into the issue that you seem to assume that you are working with an ideal system without jitter and code execution times.

During each iteration, you aquire samples (256 by the control default values which equals about 0.1 acquisition time). However, DAQmx read only stops the application as long as the requested number of samples is available in the driver data buffer. So here we can already have some delays (e.g. 110ms until you get the data).

Your "Waiting for Trigger" case sets a time reference in ms. The storage handling case compares the current time minus reference to the requested time. This comparison is equal or greater.

If you assume a jitter of +1 ms per iteration in average (so your loop runs at about 101ms iteration time), everything works as you expect and you get 20 iterations to fill your requested 2s time array.

If, for any reason, in 19 iterations the total time sums up to 2s already, you will not add the 20th iteration to your time array. So if each iteration in average jitters for +5.3 ms (could be a single iteration with e.g. 101ms delay) or more, you get 'only 19 values'.

I recommend you to change the code as such that you compute the number of iterations based on acquisition rate and number of samples in regard to requested acquisition time. Use this value instead of doing a time compare.

[akash90]

Thanks a lot Norbert for showing me where the problem was and for pointing me towards the right direction 🙂

I got the desired solution by changing my program to the counter-based logic as suggested by you.

[akash90]

Just out of curiosity, it'd be nice if someone else knows a Timing-based solution to the same problem other than the counter based approach.

Always nice to know more 🙂