# Multiplexer output is unstable and inaccurate - what am I doing wrong?

I have an Arduino project which takes three variable voltage inputs (in the range 0.43V to 0.63V) to a 4051 multiplexer (FAIRCHILD SEMICONDUCTOR CD4051BCN). Each input is selected sequentially and passed through an OpAmp to the Arduino and on to the PC for logging and analysis. DC5V is taken from the Arduino.

I can control the multiplexer input voltages fairly accurately for testing purposes with a variable resistance and multimeter, also I can test the OpAmp is working ok and stable.

My problem is that the output from the multiplexer is hopelessly unstable and varies by +/- 20% or more from the input voltage and does not stabilise over time.

I have tried change the sampling rate and allowing more time for the output to settle before reading it - but no good!

As an electronics newbie I may have picked the wrong multiplexer - there seems to be a load of products available but not clear to me which is best for my application.

Any insight or guidance appreciated.

-
Does the mux go straight into the op amp? Is there anything else loading the line, like a big capacitor? Is this on a breadboard or soldered to protoboard? –  ajs410 May 20 '11 at 17:57

This is just a general technique that might apply here. One thing that beginners often do is to try to start and end a conversion in a single pass. For example,

start the conversion
kill some time
use the data


The problem with this is that you need to wait long enough for the inputs to become stable, but you don't want to wait too long because doing so eats into your periodic's time slice. The usual solution is to turn things around, like so -

read the input
use the data
start a conversion


it looks backwards, but what it does is let the hardware do its thing for the entire length of the periodic. For example, let's say a conversion takes 50 usec (for argument's sake, combine the time to select an input and the ADC time), and you're trying to read the device every 1 msec. The first way, assuming you wait the bare minimum 50 usec, then 5% of every 1 msec interval is wasted, and the hardware has only the minimal allowable settling time. Done the second way, by the time you read the input, the hardware has had a full millisecond to do its thing, the data is available immediately at the start of the periodic, and the processor can get back to doing whatever it does between times with no cycle wasting delay loops.

Of course you do take a latency hit this way; in the example, all your data is 1 msec old, but usually the latency incurred this way is acceptable. In return you tend to get more stable input and more efficient cpu usage.

-