Taking time measurements when measuring frequency

[Schafbo]

I am needing to read the frequency of a TTL signal as part of a data acquisition program that also records analog voltage (at 6 kHz). I've looked at the shipping examples for Counter - Read Frequency... etc. but none of them provide a waveform output that would give me time measurements. I'm wondering if it is possible to do this? The only way I can see to do this is to run in "On-demand" mode and take a time measurement when writing to a TDMS file, but this is too slow for my application. I would like to be able to run in "Continuous" mode and obtain time values for all the elements that are read in that "block" of samples. I'm using a 9402 module and generating input TTL signals with a USB-6341.

[Kevin_Price]

X-series and other STC3-based newer devices support a unique frequency measurement mode based on a constant sample rate.  I haven't used this mode personally and don't know if your cDAQ device supports it.  However exactly it works, it will necessarily have some built-in compromises because the constant sample rate will not generally be in sync with the signal's own frequency intervals.

More traditionally, frequency measurement is typically at odds with the assumptions needed for a waveform datatype.  Specifically, a waveform is assumed to have a constant time interval dt between samples.  Any frequency worth measuring will have a somewhat variable interval, else why measure it?

I would tend to approach this by constructing an array of time data that's derived from the array of frequency measurements.  A cumulative sum of 1/f will tell you the relative time at the end of each measured interval.

What's likely to remain is the question of correlating these times to the AI sample times.  Unfortunately, NI made what I consider a poor design decision when introducing the newer STC3 counters by making them behave differently than their past 3 generations of counters (STC2, TIO, STC).  As a result, your ability to correlate your frequency data to your AI data depends on you doing your frequency measurements with a "legacy" device.  A lot of the newer hardware makes it borderline impossible.

-Kevin P

[Schafbo]

Thanks for your response. My device supports using a constant sample clock with an external clock, if that is what you're referring to.

---

@Kevin_Price

 More traditionally, frequency measurement is typically at odds with the assumptions needed for a waveform datatype.  Specifically, a waveform is assumed to have a constant time interval dt between samples.  Any frequency worth measuring will have a somewhat variable interval, else why measure it?.

It makes sense that waveform is not the default datatype if dt is not constant. If I am using constant sample rate though, that should be possible?

---

@Kevin_Price

I would tend to approach this by constructing an array of time data that's derived from the array of frequency measurements.  A cumulative sum of 1/f will tell you the relative time at the end of each measured interval.

---

That was my initial approach, to divide the elements in the "block" of samples based on the time between blocks. I just wasn't sure if that was an accurate assumption.

If analog inputs and frequency counter input samples are not sync'd at the same time, that may not be such an issue for my application as long as they are somewhat close. Having time measurements is crucial however. I am still not sure what is the purpose of continuous sampling with implicit timing (then reading n samples per loop) if there is no time measurement. I understand a frequency measurement is also a time period measurement with an implicit clock, but recording time after each frequency reading seems like a useful function.

[Kevin_Price]

Are you using the cDAQ 9174 chassis you mentioned in another thread?  If so, then yes it has the STC3 timer chip and will support constant-rate sampling of frequency.  I read about that measurement mode briefly and it seems to work exactly as I would want it to.  It even supports an averaging option I wouldn't have dared expect.

Given that, it'll probably make the most sense to run both tasks off the constant-rate AI sample clock.  If you start the counter task before AI, that'll guarantee that all the samples will be sync'ed in time.

As to the wish for DAQmx to return both frequencies *and* times when using implicit timing, I hear ya, but I can also understand why NI might have opted not to.   This would then be the one weird exception case where DAQmx Read returned something other than a scalar value, a waveform datatype, or an array of one of those.  There'd probably be quite a lot of ripple effect from such a change.

It might be handy sometimes, but I wouldn't rank it very high on the list of things NI should spend time fixing or improving.

-Kevin P

[Schafbo]

---

@Kevin_Price wrote:

Given that, it'll probably make the most sense to run both tasks off the constant-rate AI sample clock.  If you start the counter task before AI, that'll guarantee that all the samples will be sync'ed in time.

---

That should work. I'm new to working with digital modules, how would I route the AI sample clock so that it becomes the source of the Sample Clock for the Counter Input?

[Schafbo]

Nevermind, wiring to ai/SampleClock seems to work. Thanks!