measurement glitches on analog input using NI USB-6341 with DAQmx

[francesco_etach]

Hi

I have been using with success an NI USB-6341 with the DAQmx C++ interface for some measurements using:

- two or more analog inputs (one with a small range, 0.02 V and one with 6V range)

- one analog output using a custom generated pattern (bipolar signal between -3V and 3V)

Here a sketch of the system I am using:

For the analog inputs, that I use in differential mode, I use an acquisition frequency of 50 kHz. All the input channels are grouped in a single task. Here a small sample of the code:

const int kBatchSize = 1000;

const float64 rate = 50.0e3;

DAQmxErrChk (DAQmxCreateTask("", &taskHandle));
for (int k = 0; k < int(device_list.size()); k++) {
    DAQmxErrChk (DAQmxCreateAIVoltageChan(taskHandle, device_list[k].c_str(), "", DAQmx_Val_Diff, range[k].min, range[k].max, DAQmx_Val_Volts, NULL));
}
DAQmxErrChk (DAQmxCfgSampClkTiming(taskHandle, "", rate, DAQmx_Val_Rising, DAQmx_Val_ContSamps, kBatchSize));

DAQmxErrChk (DAQmxRegisterEveryNSamplesEvent(taskHandle, DAQmx_Val_Acquired_Into_Buffer, kBatchSize, 0, EveryNCallback, (void *) my_user_data));
DAQmxErrChk (DAQmxStartTask(taskHandle));

For the analog output I use a custom sampling frequency of 1 / (61 µs). Here a sample code:

const float sampling_freq = 1 / 61.0625e-6;
const int n_period = 200;
const float64 *data; /* a buffer with AO data sampled at 61 us */
DAQmxErrChk (DAQmxCreateTask("",&taskHandle));
DAQmxErrChk (DAQmxCreateAOVoltageChan(taskHandle,channel_name,"",-range_max,range_max,DAQmx_Val_Volts,NULL));
DAQmxErrChk (DAQmxCfgSampClkTiming(taskHandle,"",sampling_freq,DAQmx_Val_Rising,DAQmx_Val_ContSamps,2*n_period));
DAQmxErrChk (DAQmxWriteAnalogF64(taskHandle,2*n_period,0,10.0,DAQmx_Val_GroupByChannel,data,&written,NULL));
DAQmxErrChk (DAQmxStartTask(taskHandle));

 
Now we are using my application since some time and everything works nicely except we get some measurement glitches on the input channel AI0, the one with a small measurement range. The glitches are always close to the rising ramps of the signal we send in AO0 and we read in AI1.

Here a screenshoot of what the glitches look like, in the blue curve plotted in the graph above:

We observe these glitches systematically. I changed NI card and they are still there. They appear randomly with a number of occurrence for impulsion between zero and two.

I would appreciate any suggestion about the possible source of this problem and an eventual solution or workaround.

Many thanks in advance.

[santo_13]

Have you considered the accuracy specifications of the AI and AO?

[francesco_etach]

Thank you for you reply.

I have not yet checked the accuracy of the AI channel but I will have a look at the manual. That's always useful to know in any case.

However the problem I described looks to me like a glitch with the NI electronic sampling system and not a general accuracy problem.

[santo_13]

Some best practices,

1. When capturing data, always read in chunks of 100ms worth of samples or more, this gives time for the application enough interval between data transfer from the driver. In your case, if you're capturing at 50kS/s, read in chunks of 5k samples.
2. When generating data, if it is known ahead, provide the whole set of samples to the driver and let it take care of generating it at the right rate.

You were requesting a 1/61us sampling rate, but the actual sampling rate will be coerced to what is possible based on available divisors. Always read back the actual sampling rate after creating and committing the task.

What kind of waveform are you generating? it is not evident from your code, is it the rectangular pulse shown in your graph?

[francesco_etach]

Hi,

thank you for your suggestions, I appreciate.

For the analog inputs I tried to increase the batch size to 10 000 samples so that at 50 kS/s I have a batch of 200 ms worth of data but the glitches are still there, always in the channel measuring on the shunt resistance, the one with a small measurement range.

As for the analog output signal, what I am sending is a signal with a period of, let's say one second. In the task I use DAQmx_Val_ContSamps to repeat the signal. For the first 0.5 seconds I output a square wave signal during just 5 ms then the signal is zero. For the following 0.5 seconds the signal is the same but just with negative polarity. I provide the whole signal for the whole period of one second, all at once.

As for your suggestion to retrieve the actual sampling frequency used by the NI card instead of 61 µs I did not find any mention in the documentation for DAQmxCfgSampClkTiming about a sampling clock that may differ from the value actually requested. I guess that at worst the NI card will use a frequency slightly different from the exact one I specified but that may not be a real problem in my case.

[Kevin_Price]

I'd recommend a classic app note on "Field Wiring and Noise Considerations...".  In particular, your diagram doesn't show the pair of bias resistors recommended for differential measurements, so I'd suggest you give that a try first.

Another experiment you might try is to generate a channel list for your task that duplicates your measurement channels 3 times each, such as "ai0,ai0,ai0, ai1,ai1,ai1".   Then see whether the glitch is only present on the first instance and not on the other two.

[Caveat: this channel duplication was a longstanding technique that *might* no longer be supported on some devices.  I think I recall a thread in the last couple years where some device and/or version of DAQmx didn't allow it.  But I also recall lots of longer-ago years when it worked just fine across many different DAQ devices.]

-Kevin P

[francesco_etach]

Thank you for sharing the article 'Field Wiring and Noise Considerations for Analog Signals.' I have read it carefully.

In your discussion, you mention the use of additional bias resistors. Referring to the article, I found a section titled Measuring Floating (Nonreferenced) Sources that discusses the use of bias resistors. My understanding is that these resistors are necessary when the signal source is grounded to a different ground than the measurement system, as illustrated in the image below from the article:

However, in my scenario, the signal source is the AO channel of the NI card itself, where the AO GND is connected to the AI GND as shown in the circuit in my original post. Additionally, my measurements on the AI channels are conducted in differential mode. In this context, it appears that the use of bias resistors may not be necessary.

The article also discusses CMRR and the attention it requires. In my case, for the channel measuring the shunt resistance, the common mode signal is a square-like pattern with an amplitude between 1.5 and 2.8V, while the differential signal on the shunt resistance is in the range of 5 - 10 mV. I acknowledge that this could pose a challenge, yet I am currently unsure of a solution. While I am not certain that a high CMRR is the source of the issue, it remains a possibility. I welcome advice from experts in this field.

I appreciate any insights or recommendations on this matter. Thank you for your valuable input.

[Kevin_Price]

Caveat: I do not have an EE background to consider myself an expert in the field.  But I've found that references to "grounding" often tend to have some gray area.  For example, phenomena like ground loops seem to arise around these gray areas as different probe points that are *theoretically* connected to a ground or common may have slightly different impedance paths to the actual common connection.

With that as background, even in situations where the "Field Guide..." doesn't call the use of those bias resistors, I've sometimes improved my multiplexing ADC conversions by adding a bias resistor or two (depending on whether measuring single ended or differential).  Providing a path to bleed off charge between multiplexed channels reduces the influence of a larger signal on a neighboring smaller one.

I'd suggest at least giving it a try.  If it doesn't help, hopefully someone with more expertise will step in with more thorough advice.

-Kevin P