Counters in DAQmx

[Ashwin98]

Is there a way to read the value of the counter on board any cDAQ chassis along with sampling from other modules on the chassis? I want to try to use this as sort of timestamps for the acquired samples. Thanks in advance! 

[Kevin_Price]

Well yes, a simple counter task can certainly read count values from one of the chassis' on-board counters.

This *can* be a kind of timestamp for, say, AI samples, but you *will* also have to configure & wire things appropriately.

The counter only counts what you tell it to.  It only correlates to AI samples if you configure it to.

-Kevin P

[Ashwin98]

Thanks for the reply Kevin.

Pardon me if I sound too oblivious, but can these be used as free running timers that increment at a fixed rate? Maybe count the number of edges of the 20 MHz timebase. Then during each round of acquisition, I could read the count value as many times as the number of samples. This would allow to compute the time difference between acquisition of 2 samples and measure the frequency of acquisition. 

Thanks!

[cbutcher]

I'd guess that Kevin's point might be that if the following happens (in your description, without specific synchronisation):

• Counter ticks
• Sample acquired
• Counter ticks
• Counter ticks
• Counter read

then the value isn't necessarily related (I'd guess it isn't at all related) to the sampling time.

So your timing accuracy becomes dependent on the polling of the counter.

Perhaps with your description you'd believe that there is some approximately constant but non-zero offset - that might be sufficient for your need.

I don't know if that would be true, but I'd be moderately doubtful.

Of course, it might be that the clock is still close enough for your application.

[mcduff]

---

@Ashwin98 wrote:

Thanks for the reply Kevin.

Pardon me if I sound too oblivious, but can these be used as free running timers that increment at a fixed rate? Maybe count the number of edges of the 20 MHz timebase. Then during each round of acquisition, I could read the count value as many times as the number of samples. This would allow to compute the time difference between acquisition of 2 samples and measure the frequency of acquisition. 

Thanks!

---

Maybe I am not understanding exactly what you are trying to accomplish, but your accuracy is only as good as your 20 MHz clock, which is 50 ppm for most DAQs. I know for continuously sampled data the first t0 is determined from the system time and every other timestamp, (in a file or indicator), is subsequently determined by the sampling rate, which is based off the 20 MHz clock. 

mcduff

[Kevin_Price]

Can you describe what you're looking for in more explicit detail?  I think all of us responders are all of generally the same mindset here, but your endgame isn't entirely clear.   Counters can count lots of things, you just have to configure them to count what you care about.   Similarly, a counter can be used to *drive* (i.e., control) system timing when you choose.

Detailed advice depends on detailed problem description...

-Kevin P

[Ashwin98]

Thanks to everyone for your quick responses.

I do apologize for being vague in the way I have presented by doubt. I will try to explain what exactly it is that I am trying to achieve.

To keeps things generic, say I have a cDAQ chassis with an analog input module. If I were to use this to acquire samples at a relatively low rate, say a few hundred hertz, I can use the waveform output to get timestamps. If I have understood correctly, timestamps would be calculated using "t0" and multiplying the sample number with "dt". This is done by the host computer and can be relied upon to be accurate up to the millisecond scale.

The thing that is bugging me is that if I wanted higher sampling rates (say 10s or 100s of KHz, ignoring hardware limitations), these timestamps might not be accurate enough. I was thinking of alternatives when this thought occurred to me. If there is a free running counter that I can poll each time a sample is acquired by my module, this would give me the actual time distribution of the samples acquired. Hence I was wondering about the on board counters.

Thanks again in advance!

[BertMcMahan]

The samples are acquired using the same hardware clock you're using to get your timestamps, so if you're acquiring at 100 kHz you can know that the time between each sample is exactly as accurate as the base 20 MHz clock. The starting timestamp will be accurate to the system time, but the delta between each will be extremely accurate. Getting the 20 MHz counter value at each point will be redundant, and will in fact be worse than the actual sample clock because it takes a finite time to read the counter after each sample!

One thing to note: make sure to not just use your "set" sample clock. Set it then read it back (see the DAQmx examples) to get the actual sample clock rate used. Sometimes the desired sample clock won't divide evenly into the 20 MHz base clock so it coerces to a slightly different value.

[mcduff]

Excuse my stupidity but I still do not understand.

In our work, we sometimes collect data 24/7 at a 1 - 2 MHz rate. This data is continuously collected. So at times we wonder whether the small frequency shifts we see or the signals that occur at a specific time are correct.

For example, 50 ppm of 1kHz is 0.05Hz, so frequencies between 999.95-1000.05Hz can be considered within range. We have actually measured slightly different frequency shifts based on different equipment.

The sample clock is based off the 20MHz master timebase, thus whether you are determining via counter or sample rate the inaccuracy is the same.

mcduff

[Kevin_Price · Accepted solution]

I'm basically repeating what others have said, just expanding on a couple things using different wording.

Unless you go out of your way to configure otherwise, your AI task will sample at a *very* constant rate based on a clock in your cDAQ chassis.  Any further timing info you try to get with a counter will be based on that same clock in the chassis, i.e., there will *not* be any new or better information available that way.

If you were running your AI sample timing off some unknown *external* signal, then yes, timestamping those pulses with a counter *could* be useful.

The t0 value of a waveform is a timestamp with sub-nanosecond *precision*.  You can sample at 100 kHz, then iteration over a bunch of calls to DAQmx Read, and you'll see that the subsequent t0 values will *exactly* track and correspond to the dt value & the # samples previously read.  The t0 value does *not* lose you any timing precision in your data.

*Accuracy* is a different and trickier issue, but it's also usually not a significant consideration.  Most data acq tasks don't *really* need to know if they started 2.24 seconds after 1:17 pm or 2.27 seconds after.

Over the course of *very* long acquisitions, let's say 24 hours, you will probably see up to a few seconds timing skew between your PC's date and time clock and your DAQmx waveform timing info.   Many data acq boards' clocks are spec'ed to be accurate to something like 50 parts per million.  This works out to 1 part in 20 thousand.  A 24 hour day has 86400 seconds in it, so one can expect an *inaccuracy* of up to 4+ seconds per day of continuous acquisition (or similarly, 1 second per 6 hours).

    But again, time-of-day accuracy usually won't matter, while the resolution & precision are far more than good enough for any sample rate a data acq device will support.

-Kevin P