PCIe-6353 Analog Input Channels...Leaking???

[MrMattPayne]

I've been noticing something strange on one of our testers that, after doing a lot of unplugging and probing, seems to me to be internal to the 4x PCIe-6353 cards (yes, this appears to be consistent across all 4 of the same devices). It seems like signal voltage is somehow "leaking" from one channel to the next as the task performs a read. Order is paramount. A channel only appears, at least for the most part, to affect only the channel read immediately after it, pretty much regardless of wiring. For example, if the task is to read channels AI2:11, if AI2 is excited, AI3 rises by a small percentage (~0.5-1.5%). If AI3 is excited, AI4 rises. Excite AI5, AI6 rises, etc. etc. 

Some additional notes about the system:

• Physical wiring varies, with some channels being wired to devices on very different paths.
• All AI GND terminals wired to the same ground source as the analog devices (pressure transducers).
• Devices wired and configured as RSE.
• Input voltage is ±5V.

Some additional observations:

• Task read order seems to be the determining factor of which channel gets influenced. Channels were rewired and reconfigured in various combinations including mismatches (e.g. leave excited channel wired to AI2 but reconfigure DAQmx to read it from AI14 (unwired), AI3 still rises as it is next in the read order).
• Unwiring the affected (unexcited, next in read order) channel from its device results in almost 99% of the reading of the excited channel.
• Actual AI channel used has some(?) effect? If excited channel is wired to and configured as either AI1 or AI2, AI3 (next channel in read) rises ~1.5%. If excited channel is wired and assigned to AI14, AI3 (still next in read) rises only ~0.7%.
• HOWEVER, if excited channel is wired to AI2, but configured as AI1 (actually unwired), AI3 rises ~0.7%.
• Unwiring the excited channel completely results in 0 change.
• Exciting AI7 causes a rise on both AI8 (device with a very different wiring path) and AI2 (device sharing some common wiring as AI7). By common wiring I mean terminal blocks, multi-conductor cables, similar physical paths back to the NI board, not necessarily electrical paths. Almost no devices share common wiring except for power supply and opposite leg of a capacitor (all grounded to same AI ground source) for noise reduction right before the NI board.

Not sure what else to say. I'm obviously not an electrical engineer, but the fact that the most important factor seems to be the order of the channels as specified in the DAQmx task, and that physical proximity of the wiring seems to be completely irrelevant, makes me feel like this has to be something to do with the cards themselves. Additionally, despite all AI GND terminals being wired, if the unexcited channel is completely unplugged, it will read almost 100% of the excited channel's signal.

I just don't know what's normal. Maybe all of this is normal, especially for 10-year-old cards. Maybe because it's reading so fast, the card does not return to 0 completely between channel reads of greatly different values (I believe they actually only read one channel at a time, right?). Maybe it is just electrical noise, and I just don't understand the source because I don't fully understand the system. If we built this machine again, we'd definitely do it in differential since we have the channels available and the connection lengths are certainly >10ft with several connections between the device and the NI breakout board.

[crossrulz · Accepted solution]

What you are seeing is called ghosting. It is usually caused by using a high impedance source. Adding buffer circuits can fix that.

Eliminate Ghosting on Adjacent Input Channels by Decreasing Source Impedance 

[MrMattPayne]

Oh my goodness, this sounds spot on! Thank you!

Looking at how one might implement a buffer circuit, comparing to our schematic, we do indeed have an op-amp after the transducer, but not at all configured as a unity buffer. It does indeed look like we are lacking any consideration for sensor impedance, something I don't recall ever coming up in my several years making test equipment here. It looks like we learned something new today. Thanks again!

Though as a quick solution, since this is a monster of a tester and rarely gets downtime, I'm going to try simply reducing the sample rate as it's most likely excessive for the application.

[Henrik_Volkers]

Jepp, that is a common problem with unbuffered multiplexed (multichannel) AI cards.

Usually the fist figure in the (NI) specifiaction of such devices is showing the settle time error (in log scale!) vs source impedance.

I try to avoid them. 

[MrMattPayne]

So the long-standing read was 2000 samples at 20000 S/s, averaged into a single data point (unless it was a triggered read, then we took the whole curve). I decided to leave triggered reads alone since we're typically only reading one channel at a time in that case, and just made a separate sample count and rate to be used for continuous averaged reads. First I divided by 10 for 200 samples at 2000 S/s. It reduced the "ghosting" quite a bit, though not entirely. Taking it down another order of magnitude to 20 samples at 200 S/s almost completely eliminated ghosting, with the latter read only rising about 0.02% of the read before it, down from nearly 2% in some cases. A surprisingly linear reduction! Not sure how exactly it matches the settling time vs impedance graph on the 6353 specs since I'm not sure what impedance the card actually sees between the sensor itself and the op-amp between it and the NI card.

I'll be testing to see if this is a good solution for this application, hoping to avoid having to make wiring modifications. Either way, thanks for helping me learn something new, and I'll be sure to consider source impedance in the future!