NI-DAQmx C API: Controller seems to set the wrong sampling rate for NI-9215 and NI-9232

[niko_g]

Hi,

I have a question about programmatically setting sampling rates with module types NI9215 and NI9232 in a NI cDAQ-9189.

I am trying to create a set of channels in a task and then set different sampling rates using "DAQmxCfgSampClkTiming(...)". For the NI9232 e.g. with the following code:

// setup task and channels
DAQmxErrChk(DAQmxCreateTask(taskName, &hTask));
for (auto c : channels) {
    DAQmxErrChk(DAQmxCreateAIVoltageChan(hTask, c.name, c.label, DAQmx_Val_PseudoDiff, -30., 30., DAQmx_Val_Volts, ""));
}

// set sampling rate
printf("%s: set samplingRate = %f\n", taskName, samplingRate);
DAQmxErrChk(DAQmxCfgSampClkTiming(hTask, NULL, samplingRate, DAQmx_Val_Rising, DAQmx_Val_ContSamps, 5000));

// check clock frequency and sampling rate
float64 clockFrequencySet = 0.;
float64 samplingRateSet = 0.;
DAQmxErrChk(DAQmxGetSampClkTimebaseRate(hTask, &clockFrequencySet));
DAQmxErrChk(DAQmxGetSampClkRate(hTask, &samplingRateSet));
printf("%s: get samplingRate = %f (clockFrequencySet = %f)\n\n", taskName, samplingRateSet, clockFrequencySet);

In a similar way I repeat this for the NI9215 module. In each case I test with the sampling rates 102.4kHz and 51.2kHz. I get the following output:

ni9215_task: set samplingRate = 102400.000000
ni9215_task: get samplingRate = 102432.778489 (clockFrequencySet = 80000000.000000)

ni9215_task: set samplingRate = 50000.000000
ni9215_task: get samplingRate = 50000.000000 (clockFrequencySet = 80000000.000000)

ni9232_task: set samplingRate = 102400.000000
ni9232_task: get samplingRate = 102400.000000 (clockFrequencySet = 13107200.000000)

ni9232_task: set samplingRate = 50000.000000
ni9232_task: get samplingRate = 51200.000000 (clockFrequencySet = 13107200.000000)

My problem now is that - for some cases - I don't get an exact sample rate for the values I pass to the driver.

My understanding is that the device driver itself should choose a suitable timebase, which it apparently does not do for my example. I also already tried to get an accurate sample rate using "DAQmxSetSampClkTimebaseRate(hTask, a_better_timebase_for_my_samplerate)", but this returns an error message. Apparently this function call is not allowed.

How can I set the correct sampling rate? In NI MAX this seems to work for a manually created task.

It would be great if we could get a solution here.

Kind regards

[Kevin_Price · Accepted solution]

You are up against inherent limits of your devices.  Most of the common modules I'm familiar with will have one master timebase clock.  All other constant frequency clocks are derived from it through integer division.  It's a consequence of the digital nature of the clock and logic circuitry -- it's the transitions that initiate reactions.  So you can react every 90, 91, 92 transitions but there's no way to react at the point corresponding to 91.4.   There's no *edge* there.

And so, the sampling rates that are actually available to you must be based on dividing the master timebase by an integer.  (There can be further restrictions that only *certain* integer divisors are allowed, but it'll always be restricted to integers.)

Apparently your 2 devices have different master timebase frequencies and so the specific actual sampling rates they can derive won't match up.

I'd recommend looking into the use of "channel expansion" where DAQmx might do the dirty work to have one device derive a sample clock from the other device's timebase and also use the same integer divisor.  That would keep them sync'ed and in phase.   It might also set up triggering to get them to start up in sync.

    Sorry for being vague, I haven't really much occasion to use the feature myself.  Note that it's also usually possible to set it up such things manually, but I don't know the C API to give specific guidance.

There *are* devices that allow for a clock to have almost any arbitrary frequency, the kind I bumped into refer to this as Direct Digital Synthesis.  I think these are usually high cost specialty devices.

-Kevin P

[niko_g]

Hello and thank you for the quick reply.

I think I understand the context somewhat better now. Our users need to control the measurement samplingrate, which I am able to set up: i.e. all channels within one task and one sampling rate, or each module in a different but synchronized task and different sampling rates.

But I have difficulties to understand, how the system decides on which master timebase to set for a certain module or module combination. For example, I get these results for the following system setups when trying to set the target sampling rate to 102.4kHz:

A/ NI-9232 : samplingRate = 102400.000000 (clockFrequencySet = 13107200.000000)
B/ NI-9232, NI-9215: ditto
C/ NI-9215 : samplingRate = 102432.778489 (clockFrequencySet = 80000000.000000)

According to its datasheet, the NI-9232 uses 13.1072Mhz as internal master timebase. Thus, A/ and B/ are no surprise - except that I don't find anything about supported master timebases for the NI-9215 in its datasheet. But it obviously does support different timebases. Am I missing something there? Can you point me in a direction where to find an overview of supported master timebases for different module types? 

As for the case C/, where only the NI-9215 is used: Why does the controller decide to set the "imprecise" value (with the max. possible timebase) and does not provide the exact requested sample rate? Does it always use the max. possible timebase for a given module combination?

Thanks in advance

[ZYOng]

Everything is explained in Signal-based Synchronization of Analog Input C Series Modules with NI-DAQmx in LabVIEW.

For your case of NI-9215 (reference clocked) and NI-9232 (Delta-Sigma), under Multidevice Task >> Reference Clocked Module and Delta Sigma Module

In a time-aware chassis (cDAQ-9185 or cDAQ-9189), the Reference Clocked Module’s reference clock is not shared with the Delta Sigma Module’s master timebase rather the chassis routes a reference clock to the Reference Clocked Module and a master timebase to the Delta Sigma Module. Both modules receive a synchronization pulse from the chassis/controller that resets their respective ADCs and share a start trigger, and each module’s reset time is adjusted.

[niko_g]

Thanks a lot for the help. I will take a closer look at the information in the document.

[Kevin_Price]

I can answer your question from a couple msgs back to help you understand the *reason* for the problem you're facing.  But the link from ZYOng is gonna get you farther along toward a solution.   

Let me extract a quote from you to re-establish context.

---

@niko_g wrote:

But I have difficulties to understand, how the system decides on which master timebase to set for a certain module or module combination. For example, I get these results for the following system setups when trying to set the target sampling rate to 102.4kHz:

A/ NI-9232 : samplingRate = 102400.000000 (clockFrequencySet = 13107200.000000)
B/ NI-9232, NI-9215: ditto
C/ NI-9215 : samplingRate = 102432.778489 (clockFrequencySet = 80000000.000000)

According to its datasheet, the NI-9232 uses 13.1072Mhz as internal master timebase. Thus, A/ and B/ are no surprise - except that I don't find anything about supported master timebases for the NI-9215 in its datasheet. But it obviously does support different timebases. Am I missing something there? Can you point me in a direction where to find an overview of supported master timebases for different module types?

Agreed.  The 9215 spec sheet I found gives no info about the device's master timebase.  I'm much more accustomed to the datasheets for NI's MIO desktop boards where these specs are identified.  After looking one up again, I see that it's categorized under the Counter/Timer section called "internal base clocks."

    One likely reason is that many cDAQ modules don't have their own internal clock source -- they count on their chassis to provide a clock.  And this is a feature, not a bug, because it helps make sure that multiple modules, all driven from a common timing source, will remain in sync.

    But devices with Delta-Sigma style converters are exceptions to this rule.  They *do* have their own internal clock and they *cannot* directly use an external clock to set their sample timing.  So any time a DSA device needs to be sync'ed with an SAR device, things get more involved.

As for the case C/, where only the NI-9215 is used: Why does the controller decide to set the "imprecise" value (with the max. possible timebase) and does not provide the exact requested sample rate? Does it always use the max. possible timebase for a given module combination?

This simply goes back to the things I said earlier in msg #2 about integer divisors.  The 102432.778... frequency you call "imprecise" comes about from an integer 781 divisor.  The next lower *available* sample rate would result from an integer 782 divisor, and result in a sample rate of 102301.790...   You simply *cannot* divide down a 80 MHz clock to produce an exact sample rate of 102400.000 Hz.

The sync document ZYOng linked has a ton of good info and some of it will be very important for you.  But as a practical matter, I suggest thinking carefully about the degree of sync you need.  I've personally only very rarely needed to do any mucking about with reference clocks or sync pulses.  I haven't generally needed to control or characterize the exact phase difference between the sample clocks used by different devices.  Where phasing between signals really mattered, I would feed them into the same device where it would be controlled or defined, and quite possibly 0.  Going across devices, my own personal experience is that I've rarely needed to do more than prevent timing drift. 

    My data acq has usually been for something mechanical (strain, force, ...), electromechanical (motor, LVDT, encoder,...), or a physical process (flow, temperature, ...).  Post-processing of data has not generally been sensitive to nano-second level phasing concerns.

    The point is to keep your engineering judgment intact.  It can be complicated to pursue theoretical perfection.  And complication tends to bring costs and risks.  Be sure to think carefully about where the pursuit is and isn't worth it.

-Kevin P

[niko_g]

Thanks for the detailed answer.

In my above post I spoke of "imprecise" sample rate, as I would have expected to get the exact sample rate. For this, however, the controller would have to automatically select a time base other than 80 MHz. My problem lies not in understanding the mechanism of dividing the timebase in order to get the list of corresponding sampling rates.

See case B/ from above: Here you can see that the NI-9214 supports the desired sampling rate in principle. Precondition for this is that the time base 13.1072 MHz is used and thus a divisor of 128 to the sample rate 102.4 kHz would result.

My question therefore was, whether the used time base _always_ falls back to the maximum value (for my controller 80 MHz), if this is not forced to a different value (as seen in B/).

[Kevin_Price]

This is not an *official* answer, but an educated guess from experience.

I think the default timebase will be the max timebase from the "most natural" or "most direct" source.  In the case of a DSA modules, it'll be the timebase internal to the device.  In the case of SAR modules, it'll typically be the max timebase from the chassis.

Your case B/ looks like an exception -- I'm guessing you set up a single task including both devices, something NI sometimes refers to as either "channel expansion", or (more descriptively) a "multi-device task".  This was what I referenced back in msg #2.  DAQmx was doing the dirty work of configuring timing signals for you such that the 9215 used the 9232's timebase to derive a matching sample clock rate.

ZYOng gave a link to a more thorough article for mixed module types which may help you understand how to do that kind of config manually (if you actually need to).  I made a brief attempt to explore with simulated devices in MAX, but didn't find what I was looking for in the Device Routes tab.

-Kevin P