Re: ADC mux charge injection on commercial DAQ boards

Robert Adsett wrote:
In article <fdomqc01oaq@xxxxxxxxxxxxxxxxx>, CC says...
The programmer also stated that for every job he does, his goal is to do the absolute minimum work to get something working. And if 90% of the time there aren't problems which come back to him, then he has done too much. The consequence of this is that the expensive lab time and the time of scientists get expended in finding and solving problems. But he takes credit for getting jobs done (which really aren't "done" at all) very quickly and efficiently.

I have the opposite philosophy. I spend a large amount of time in my workshop designing things to be nearly perfect before delivery to the lab, because I believe it is my job to use my time to find and resolve the problems before installation so that precious lab time isn't wasted. I have never received a complaint that it took too long, only compliments that my stuff works perfectly.

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.

Well said.

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.

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.

This difference of view has now led to quite a bitter state of conflict between us, which is unfortunate. I'm not sure how it will play out. I am pissed because now I fear this guy has bad-mouthed my work in the past as taking too long to complete and over-engineered. So he makes himself look like he's prolific and I'm not. But I'm the one who winds up with the job to make his partially functional work reach full functionality. And I get put down for doing it "too well."

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

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

I maintain my position that the DT3010-268 is "broken." Would you agree or disagree?

Sympathise, but disagree.

Should it be the job of the customer of a commercial DAQ board to have to build analog input buffers on every channel before the board can be used to specification for any other than "battery" voltage sources located a few inches from it's inputs?

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.

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:

http://www.datx.com/images/specs/DT3010Specs.pdf

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!


--
_____________________
Christopher R. Carlen
crobc@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
SuSE 9.1 Linux 2.6.5
.

Relevant Pages