Why doesn't my sample rate match the timestamps output in the waveform?

[CFJ]

Hi there,

I'm running a simple application to read data from two pressure sensors outputting 0-5V signals to an NI9215 module, and a load cell connected to the 9237 module. These are housed in the 9172 chassis.

I'm new to DAQ and labview, and I'm having difficulty reconciling the sampling rate that I set in the sample clock and the apparent rate that the data is collected (as per the time stamps in the waveform that I output to a text file). For example, if I request 100 Hz rate (and 10 samples to read ), the data appears to be sampled at 1612.9 Hz. If I request sample rate 1000Hz, data out is at 1612.9 Hz,  for 20kHz, data is output at 25kHz.

Can anyone advise me on whether to trust the time stamps given in the waveform written to the text file, and if there is a way to check this?  If this time stamp is correct, how do I force the application to sample data at the requested rate?

As a secondary question, in my attached VI you will see that I have a shift register attached to a build array. I cannot figure out how to initialise the array outside the loop such that it clears the array before the next time I run the program.Any advice?

My VI is attached.

Thanks, 

Claire.

[MarkGrot]

Your sample rate is being coerced to the next highest valid sample rate.  This happens all of the time but normally it doesn't matter because of the number of valid sample rates.  However, the 9237 does not use the chassis timebase and has a small set of valid divisors.  It restricts valid sample rates to 50kHz/1..31.  With only 31 valid sample rates, your desired sample rate will be coerced.  The slowest the 9237 can sample is 50kHz/31 or 1,612.9Hz as you've seen.  This is also why 20kHz gets coerced up to 25kHz (divisor of 2).

After you commit or start your task, read back the sample clock rate using a timing property node (SampClk.Rate).  This will tell you what rate your task is actually using.

Message Edited by MarkGrot on 02-06-2009 06:01 PM

[CFJ · Accepted solution]

Hi Mark, thanks for the quick reply and the good explanation. It's all alot clearer now.

Have a great weekend, 

Claire.

[hygeia44]

Hi Mark,

Could you please give a screen shot how to use timing property node to get the actually time stamp ? I have trouble for the time stamp for the waveform data. I have a  load cell, NI-9172 and NI-9237. I used 'dt' components from the waveform as the time stamp, but it just repeated from 1 to 31 as you said. What I need is the time stamp in millisecond begin from 0. I also tried the 'Tick Count', but it begins with a very large number. Unfortunately, my Labview version is 8.5 and I can not open the file above. Please help.

Thank you!

Melody

[MarkGrot]

Hi Melody,

I think you're asking a different question.  If you want an expanded version of how to read back your actual sample rate, we can do it in this thread, otherwise it might best to start a new one.

I think you're asking how to timestamp your samples.  The waveform datatype has a t0 and dt so you can roughly figure out your timestamps.  I say roughly because the waveform datatype has some drawbacks, especially with the 9237.  If you need better timestamps, I can go over another method of generating them.

[hygeia44]

Hi Mark,

I do need more accurate time stamp rather than t0 and dt. Please help.

Thanks!

Melody

[MarkGrot]

I'm still not exactly sure what you're asking for.  Maybe you could post a vi or screenshot of what you're doing.

If you're doing a simple AI acquisition with an internal clock, your waveform timing information will be pretty accurate.  The waveform dt is the correct coerced value.  For example, if I create a task with a 9237 and set my sample rate to 1kHz and then look at my waveform's dt, it is 0.00062.  The inverse of that is 1612.9, my coerced sample rate.  If you want the timestamp that corresponds to each sample, that's as simple as t0 + dt * n where n is your sample index.

The only thing that's a little shakey in the above is the t0--it's not exact.  Your cDAQ-9172 chassis doesn't have any way to translate its clocks into a meaningful time for you.  If you're trying to correlate your task to some other activity, you could use aiStart or the first aiSampleClock to indicate your t0 and go from there.

That might not answer your question.  If it doesn't, could you explain your situation in more detail?

[hygeia44]

Hi Mark,

I tried the t0 + dt, not t0+ n*dt, but it seems works well now.

Thank you!

Melody