ADC mux charge injection on commercial DAQ boards

All CMOS multiplexers kick out charge when they switch, plus whatever signal is loaded onto whatever downstream capacitance there is, in the ADC front end, gets switched between channels, too. So the inputs are hardly simple, passive loads.

Lots of opamps go nuts when hit by a mux spike, and can take a long time to recover. They may rectify the spike somehow, and then a high sample rate winds up creating a big DC offset.

The easiest fix is a series R-C just ahead of the mux; something like

100 ohms, which most opamps can drive, and as much C as the signal bandwidth can stand, some number of nF at least. The charge injection can be treated as an average DC current, which produces an offset error into the 100 ohm resistor, so this can have problems, too, especially at very low signal levels.

Another trick is to select a dummy channel, grounded or Vcc/2, between active channels. That keeps channel-channel crosstalk down.

People who design data acquisition boards should at least use very low charge-injection mux's (as opposed to very cheap ones) and buffer properly downstream, to keep the crosstalk capacitance low.

Nowadays, you might almost as easily go with an ADC per channel.

John

This is more than just a design philosophy difference. It's driven by some fundament real and percieved difference between software and hardware.

Software is a lot more malleable and flexible (especially over time) than hardware. As a result software jobs often never finish, there is always one more small feature to add or a 'simple' way to have the SW work around a HW limitation. In addition because of the perceived simplicity of changing the SW, the specifications for SW are often fuzzy, incompletely thought out and more grandiose than is necessary to do the required job. These characteristics of SW specifications make it a good idea to complete SW that does the most useful and important fraction of the job and have used before attempting to finish. Often the rest of the specified functionality is unnecessary or completely different functionality will be more useful.

This should be a lot less true for a well established product area, but I would expect it to be true in spades for a laboratory environment.

Now what he does deliver should have the goal of being bug free, but there are a lot of advantages to delivering short of being functionaly complete. A good design will be done with an eye to exapnding capabilities in the future, an excellent design will succed in having a sufficiently general base that future modifications fit in cleanly, an exceptional design will be so simple and clean that it doesn't require changes since additional functionality can be built out of the existing functionality.

Working in hardware you don't have the same luxury of incrementally adding feature ad-infinitum and you will usually have a more solid specification to start from.

That is unfortunate. The forces driving one disciple should not be imported into another.

Sympathise, but disagree.

Their job is to specify what the inputs are including frequency capability and drive requirements. Yours is to determine how to translate from your source characteristics to their input characteristics.

Robert

Well said.

Yes. In my case the specs are rarely quantitatively stated when I'm initially told what the job is. I then work with the PIs to pin it down or else make some reasonable guesses based on understanding what they are up to. I tend to err on the side of making it somewhat better than necessary. But more pertinent is that since their very frequent tendency is to make substantial changes to the requirements after 50-90% of the work has been done, this forces me to try to anticipate these changes and to plan hardware that can easily be adapted to a range of unforseen modes of operation. This can be very time consuming. But I have more experiences where this paid off than ones where I have regrets.

So yes, this is much easier to do with software which is why I am trying to employ uCs and PLDs in everything I do except for the absolutely essential analog stuff.

Well you've provided an interesting insight into the situation. Much appreciated.

Fair enough. When you put it that way I don't think it's that much of a disagreement. Looking at the specs of the DT3010:

indicates that the inputs are spec-ed as 100Mohm, 10pF off/100pF on. That doesn't explicitly state what will happen in use, that actually the

100pF on is not at the same voltage as the 10pF off, which means charge injection will occur.

I would be very disinclined (based on my philosophy) to make a board for market like this, without input buffers. I know it would add cost, but

16-32 extra op amps on a $2000 board would be a fair price to pay for the benefit of being able to advertize the product as such and to write a white paper about how your signals won't be read correctly when you connect a competitor's board to real-world sources without spending a several $1000s in time/materials to have an electronics tech. or engineer make you an analog buffer amp for each channel.

I have at least one board which is built more like I would expect, a

16-channel simultaneous sampling DAQ from Innovative Integrations (a DSP solutions vendor). That one has almost exactly the same input conditioning on each channel as I am going to be sticking on my DT3010s.

Oh well,

Good day!

Hi Chris, Welcome to the real world. A decade ago, I was on a 'big' project that was broken into a Hardware side, and a Software Side. On the hardware side there were four of us: Our boss, who know project management (and management in general) better than anyone else I have ever seen; An engineer who was officially labled as Documentation; another engineer who was labled as QA; and me, labled as Senior Hardware Engineer. The Software side had at least 15 programmers and system administrators, of which 8 of them came and went during the time I was there, not to mention the 8 documentation clerks.

During the nine months I was on the project (it was a virtual company - only the managers and about three software guys were actual employees, the rest of us were contractors) the hardware group was always on time, never had any problems (at least that upper management ever saw) and we were on budget. The software group was always 30 to 60 days behind schedule, was way over budget, and complained at every meeting to management about their troubles.

I left because they 'fired' the entire hardware group, and spent the next year 'persuading' the hardware manager to quit. (They finally had to fire him, big severence and all...) They felt that he must have been padding his budget and schedule too much since he never had any problems!

They promoted the software manager...

Charlie