If the scales are AC powered, the 0V in the scales maybe connected back to the AC earth and you are experiencing some problems there. Alternatively, when you measure the 5V on the scales, you might be connecting to -5V and 0V and convincing yourself it is +5V and 0V - this will work fine when the arduino powers it but give nonesense when you use the power from the scales.
What you should do is connect a common ground (0V) between the scales and the arduino and measure what the voltages on the scale are again. If they read negative values or are not how you expected them to be there is likely a mismatch in power supplies. Check also that you still measure about 2.5V on the midpoints.
It's a bit hit-and-miss doing stuff like this and you may get different values but if they are different to what you expect (with the common 0V) then there is a mismatch.
Another possibility is how the scales (when connected to loadcell) do their measurement. You can't rule out that they are doing an AC measurment with dc superimposed - you measure 5V but in fact there maybe a significant AC signal (probabaly between 100Hz and 10kHz) superimposed that your meter is oblivious to.
Interesting.
I don't think I've ever seen this anomaly before.
It's often convenient to think of a SAR ADC as if it samples the input analog voltage at some instant in time.
In practice, there is a narrow window of time where changes in the input analog voltage --
or noise on the analog voltage reference, or noise on the GND or other power pins of the ADC --
can affect the output digital value.
If the input voltage is slowly rising during that window, then the less-significant bits of the SAR output will be all-ones.
If the input voltage is slowly falling during that window, then the less-significant bits of the SAR output will be all-zeros.
A very narrow noise pulse at the "wrong" time during conversion can have a similar effect.
Right now my best guess is that you're using some sort of analog switches or op amps that don't work quite as well (higher resistance or something) near the high and low power rails as they do near mid-scale, somehow letting in one of the above kinds of noise, which causes the less-significant bits to be all-ones or all-zeros.
I've seen some sigma-delta ADCs and sigma-delta DACs that have good resolution at mid-scale, but worse resolution near the rails -- but the effect looks different than what you show.
The "plot of the difference between one sample and the next sample over the entire full scale range" is fascinating.
If I were you, I would make a similar plot that, instead making the X value the difference between one sample and the next, make the X value the least-significant 6 bits of the raw ADC output sample.
That would quickly show if the "stuck" values are mostly lots of 1s in the least-significant bits (maybe input is slowly rising?) or lots of 0s in the least-significant bits (maybe input is slowly falling?).
I am sampling "pulsed" DC voltages. That means that for each
measurement I put a voltage on the DAC, let it settle for at least 100
times it's settle time, then tell the ADC to convert - and when
conversion is finished, I put the DAC back to 0 V.
My understanding is that when ADC manufacturers say "no missing codes",
the test they use involves several capacitors adding up to a huge capacitance directly connected to the ADC input,
and some system driving a large resistor connected to that capacitance that very slowly charged or discharged that capacitor,
slowly enough that the ADC is expected to see exactly "the same" voltage (within 1/2 LSB) for several conversion cycles before it sees "the next" voltage (incremented by 1 going up, decremented by 1 going down).
If I were you, I would see if such a "continuous slope" test gives the same weird "stuck code" symptoms as the "pulsed test".
Perhaps that would give more clues as to exactly what component(s) are causing this problem.
Please tell us if you ever figure out what caused these symptoms.
Best Answer
DAC error? : You say the scope trace is displaying the Arduino's ADC input values BUT you are apparently displaying an analog signal. I assume there is a DAC of some sort in the process to convert the ADC readings back to analog.
The trace gives the appearance of a DAC with a massive error in a mid level bit. eg address bit A2 of the DAC may have a resistor value that is say 10 times too small.
Test: Turn the pot VERY slowly, do the gross steps vanish?
ie do you get a smoothly descending level.
If the level steps down like that at any sweep speed you probably have a bit based error post ADC.
Or, just possibly a microcontroller with a bit error in the IC's DAC hardware (less likely) .
ADC speed: Failing the above -
General web feel is that you can do better than what you are seeing.
If that pot sweep is in say 0.1 second then your gross step rate is about 10 mS.
HOWEVER- there seem to be small declining steps on your waveform - perhaops 10 per gross step, for a ministep of say 1 mS.
Even that is longer than you'd reasonably expect.
This discussion suggests 10's f kHz. - 77 kHz is mentioned.
Arduino based scope gives an idea of speed expected.
Energy monitor using ADC again, a guide.
Useful