Analog input errors when using multiple channels with different ranges

[Chris90265]

I have a NI 6341 USB-OEM board, trying to sample multiple analog inputs at different ranges.

ai0 is set to a range of 1V

ai1 is set to a range of 10V

ai2 is set to a range of 1V

Each channel is measuring a test 4Hz cosine waveform with ~3kOhm impedence, going from 0 to 0.8V on channels 0/2 and 0 to 8V on channel 1. The waveform is defined from the same board, on output AO1.

Measurements on ai0/2 are always good. When configured above, the measurement on ai1 exhibits what I can only describe as momentary clipping. The smooth cosine waveform looks more like a stair-step, where the voltage, when it enters one of about 10 voltage ranges (~30-100mV), becomes clamped to a specific value. All of these ranges are above 7V. When clamped, the value has zero noise and reads the exact same value down to the single bit, as if it were a software bug.

If I set ai0 to a range of 10V, the problem still persists. If I set ai2 to a range of 10V, the measurement on ai1 good. I can reproduce the problem with any analog input channel preceeding a channel where the sample range is lower.

I have reproduced this problem on 3 different 6341 boards, using both Labview, and Matlab (daq toolbox). My operating system is 64-bit windows 7 SP1.

Attached is a screenshot showing the output of channels ai0 and ai1, set up as initially described. The clipping seems to get worse as the voltage nears the upper end of the range.

[AirFrantz]

Because this DAQ card has a single ADC which is multiplexed to the channels, this could be the affect of ghosting.  Generally, you should not arrange the channels in this way.  You should keep similar voltage ranges on adjacent channels, and if there are unused channels separate the different voltage ranges.  If you slow your sample rate, does this distortion get better?

[johnsold]

Your source impedance is also a problem.  Look at the Settling time graph on page 2 of the NI 634x Specifications document.  It appears that the settling time with 3000 ohms source impedance may be 1000 times larger than the "specified" settling time on page 1.  If it is that much larger, very noticeable errors seem likely. Those specifications are based on step response so it is difficult to predict precisely what the effect will be with sinusoidal inputs.

It is clear that the performance degrades substantially with a large source impedance.

Lynn

[Henrik_Volkers]

---

@Chris90265 wrote:

....

...The smooth cosine waveform looks more like a stair-step, where the voltage, when it enters one of about 10 voltage ranges (~30-100mV), becomes clamped to a specific value. All of these ranges are above 7V. When clamped, the value has zero noise and reads the exact same value down to the single bit, as if it were a software bug.

If I set ai0 to a range of 10V, the problem still persists. If I set ai2 to a range of 10V, the measurement on ai1 good. I can reproduce the problem with any analog input channel preceeding a channel where the sample voltage (edit by Henrik) range is lower.

I have reproduced this problem on 3 different 6341 boards, using both Labview, and Matlab (daq toolbox). My operating system is 64-bit windows 7 SP1.

...

---

not so nice finding... what takes my attention:

can you please provide the vi you used.... and a coarse schematic of the source ( I assume a voltage divider 😉 )

I also expected a settle error ( due to missing buffer amplifier/ high source impedance), however it should be somehow related to the amplitude and the former channel amplitude. 

And it's not holding an old value

[_kb]

Hello all,

We recently became aware of this behavior and have been able to reproduce it.  We are actively investigating the cause of this issue, and finding a solution is a top priority.  Unfortunately, the only immediate workaround is to sacrifice vertical sensitivity and set all channels to use the larger input range.

Chris, in what version of DAQmx are you working?

[Chris90265]

Sorry, I have been too busy with other things to further troubleshoot the problem. I'm glad that it has been identified as a bug, at least.

The DAQMX version used to generate the plots above is 9.8.0. I saw the same behavior with a previous version, 9.7.5f1.

I have been tracking down this bug for a few months now, so I can immediately answer a few of the other questions from users:

AirFranz: The problem seems to be independent of sample rate. I have tried rates from 1 to 50khz.

johnsold: I agree that my impedence could be lower. It is correct to treat the response as a step input, as the multiplexer is switching between channels with large variations in voltage. However, I think your issue is a couple of orders of magnitude smaller than the errors I'm talking about. In my example, with 2 channels and 10khz sample rate, my sample time per channel is around 50us. According to that graph, this is still well into the safe range for error < 100ppm. the error I'm seeing is on the order of 10000ppm, or 0.1V of a 10V signal.

I have attached a simple diagram of my circuit. I've been testing a constant current driver that pulls down from 20V, so I need to run my signals through a divider to bring them in range. AO0 is set to 100mV range, AO1 is set to 10V. For my application, both of these measurements need to be accurate. Because I have several dividers in parallel on a low impedence circuit, their effective resistance is down to something more like 3k instead of 10k.

[Henrik_Volkers]

thanks Kyle for that information.

CAR??

[_kb]

We've identified the root cause of the behavior and are working on a fix.  CAR #483646

For a better workaround, include one 'dummy' channel in the scanlist after each input range is used.  For example, if you have 4 channels using the 10V range and 2 channels using the 1V range, your scanlist should run through the 4 10V channels, then an unused 10V channel, the 2 1V channels, and an unused 1V channel.  Only the channel prior to a range change is affected.

[John_P1]

What hardware does this affect?

Best Regards,

[_kb]

Hey John,

We're still looking into it -- obviously the USB-6341.  For now, that's all I can say for sure.