LVM file time stamps - time stamps are not uniform

[hprd]

My LVM files do not have evenly separated time stamps.  Is this by design?  I want to record data from multiple channels at say 100S/s and see this in my LVM file.  Ideally each of the 100 data points would be separated by 0.01s.  This is not what I get.

I have tried changing the samples per second and the samples per channel inputs on my timing and read VIs but I don't get even spacing.  I have figured out that the DAQmx Read VI always cuts the number of samples in the file in half.  So sampling at 100S/s gives me 50 data points per second in my LVM file.  Given that it cuts the points in half, I would like the spacing to be .00, .02, .04 etc., but I get this:  .00, .01, .02, .03, .08, .09, .10, .11, .16, .17, .18, .19... 

Is this normal or am I missing something?

HP

[DFGray]

Please post a sample of your code so we can do proper debugging.  However, if you are not using the hardware timing of your DAQ board, and a non-real-time system, this is expected behavior.  WinXP, for example, is very non-deterministic, especially at the millisecond time level.  Do you know that your data is, in fact, being taken at regular intervals?

[hprd]

I am using hardware timing and Windows XP.  The only knowledge I have of the timing is from the file.  I realize that there is only one adc so nothing is truly being measured at the same time, but I thought it could do better.  I currently have my adc running at 20kS/s (ai.convert.rate) which suggests each channel should only be 50us apart.  That's 200 channel scans before the next 100S/s interval.  In my mind, there should be plenty of time for it all to fit.

Are you familiar with the DAQmx Read chopping the samples per second in half, or could this be happening just in the file write?

I know some people on the forums suggest using write to spreadsheet instead of lvm, but now I am wary of the timing.  If I assume a time stamp/delta t for a spreadsheet file, I could be drastically wrong.

Your thoughts?

[DFGray]

Unfortunately, I am not a DAQ user (the last time I really used DAQ was 7 years ago, before DAQmx was created). So, I have never seen your DAQ read issue.

LVM, on the other hand, I am intimately familiar with.  Using the write to spreadsheet will almost always be faster than the LVM write.  Under the hood, LVM write uses write to spreadsheet, but also handles a lot of other bookkeeping (you can look yourself by converting an LVM Express VI to a normal VI and diving into it).  Your biggest issue will be saving the timestamps correctly.  If you are using the waveform datatype from the DAQ read, the timestamp is included, so getting it right is not an issue.  Formatting it in a text format for save is.

Precisely what are you trying to do?  From you earlier post, it appeared you were taking one set of several channels of data every 10ms and writing to disk.  Depending on how you use the LVM write, you may be attempting to open the file and close it at every write.  This would be very slow and could account for your jitter.  Saving at every data point is also very inefficient.  You can stream at disk rate limited speeds (~10 - 60 MBytes/sec, depending on your hardware) if you optimize your buffer and disk write sizes. Optimum disk write size is about 65,000 bytes for Windows XP.  Your data is probably far less than that.

Please post more details and code and I will try to help you more.

[hprd]

Here is an example of what I am doing.

[hprd]

I've solved the problem.  After posting my example code, I realized my example code doesn't fully reflect what I am doing.  I actually have 2 DAQmx Read VIs on the same task.  One reads a waveform, the other a 2D DBL.  I believe having 2 Read VIs on the same task screws up the timing for both.  By disabling the second Read VI I was able to record data as expected.

Thanks for your help as I learn what, and what not to do in LabView.

HP