too low values from analogRead()

Status
Not open for further replies.

AdmiralCrunch

Well-known member
hi

I have 8x switchbuttons, 32x potentiometers and 8x slide-potentiometers wired together with GND/3.3V .. and the outputs to a board with some 4051-multiplexers:

20180701_234344.jpg

something went wrong so I had to debug..

# first I unconnected everything and tested every 4051. one by one, with 8x switchbuttons.. everything workes fine
# then I went to testing the analog signals, one by one..
.. the potentiometer-values go only from ~25 to 1023 (?!)
.. the slide-pots values go only from ~100 to 395 (!?)

.. yesterday, after the values went from 0 to ~400, I restarted multiple times.. one time the values went correct from 0 to 1023.. but today I' sarted working and have this situation?

what could cause such behaviour?



edit:

what I just discovered and is really ackward:
.. I test only one of the slide-pots.. the values suck around from 100 to 400 .. then I pushed all the slide-pots, whom data-output is not connected anywhere, up to 100% .. and now my slide-pot which I am testing goes up to 1023 (!!) .. what is this? oO
 
Last edited:
After the Teensy outputs an address to change a multiplexer input, you should add a short delay before then reading the multiplexed signal on the analog input. The Teensy is so quick that if you read immediately after changing the multiplexer address, the multiplexer will not yet have fully switched from one input to the next and the reading will thus be wrong.
 
After the Teensy outputs an address to change a multiplexer input, you should add a short delay before then reading the multiplexed signal on the analog input. The Teensy is so quick that if you read immediately after changing the multiplexer address, the multiplexer will not yet have fully switched from one input to the next and the reading will thus be wrong.

hi,
I already have a
Code:
delayMicroseconds(40)
directly after switching the mux-addresses.
 
I'd go back to the individual testing and figure out why full expected range isn't being seen. Are they wired in series or some other error preventing each POT from presenting full value? With a DVM on the source is that value as expected and then coming out of the Mux when selected?

1023 is 10 bit resolution - does the unshown code set it higher if expected? Like :: analogReadResolution(12); { It defaults to 10 bits (returns values between 0-1023) }

Not stated but it looks like that is a T_3.6 since it seems to have the USB part on the PCB?

How many Mux's? Does it help to set them all to the new address select value - then delay() - then read them all … repeat. That would add time for settling making a shorter delay more effective without actually waiting as long on each.
 
I'd go back to the individual testing and figure out why full expected range isn't being seen. Are they wired in series or some other error preventing each POT from presenting full value? With a DVM on the source is that value as expected and then coming out of the Mux when selected?

they are wired in series like this:
faverstrom.png

I have tested all connections with a multimeter.. every pot gets Vcc and GND.. also all the data-wires seem to be ok.

I didn't measure exact values on the pots, but I think they will be as prompted by my code.. too low :)


1023 is 10 bit resolution - does the unshown code set it higher if expected? Like :: analogReadResolution(12); { It defaults to 10 bits (returns values between 0-1023) }

I am not using responsiveAnalogRead() for now..

this is the my testing code:

Code:
int analogPin = A14;
int val = 0;
int valOld[4]  = {
      0, 0, 0, 0
    };

void setup() {
  
  Serial.begin(9600);
  while ( !Serial && (millis() < 4000) ) {
    Serial.println("LOADING SERIAL PORT ...");
  }  
  Serial.println("SERIAL PORT INITIALIZED");
  
}




void loop() {
   val = analogRead(analogPin);      
  //val = 0.6 * val + 0.4 * map(h,0,1023,0,127); 
  
 if(val != valOld[0]) {
    Serial.println(val);
    valOld[0] = val;  
  }

}

for testing I am not using the muxes.. the outputs of the pots are connected to a breadboard.

Not stated but it looks like that is a T_3.6 since it seems to have the USB part on the PCB?
yes, it is a T_3.6
How many Mux's?
- there are 14x 4051
Does it help to set them all to the new address select value - then delay() - then read them all … repeat. That would add time for settling making a shorter delay more effective without actually waiting as long on each.
I already do it that way in my main-script .. but for now I wanted to debug so I try it out without the muxes.
 
First thing I would do is to check the resistance of the pots/sliders. I know a long time ago when I was making my own remote control, that some of the sliders and the like had built in inline resistors. So I would do simple check of seeing what the resistance is from each end (VCC/GND) to signal pin when all the way one direction and all the way the other direction and maybe something like half way, and see if your pot/slider goes to 0 on the ends for one of the sides...
 
I found something ..

I have two blocks of 4x slide-pots like in the image posted before.. so slidepot1- slidepot8 .. The GND/3.3V comes from a breadboard (at the moment) and is wired to slidepot5, then everything is wired in series, also like in the image

now slidepot5 affects all the other slidepots!!! oO ..

when slidepot5 is up to 100%, all sliders can go from 20 to 1023
when slidpot5 is down to 0%, all sliders go from 0 to 115.. or the teensy dies and you have to reboot a thousand times.. (i don't know if i'm schizophrenic, but when I pushed slidepot5 a up, teensy started to work again.. oO )

what could cause this? oO
 
Wiring error. You most probably wired +3.3V to the wiper of pot5. When you pull it down, you partially or fully shorten the 3.3V to GND and then the voltage drops so that the other pots do not longer have full range and the Teensy stops either from under voltage or overload of the 3.3V regulator.
 
you are correct sir :D

I just discovered it.. somehow managed to solder it wrong.

I corrected this now, and all the pots go now from 6 to 1023 .. how would I get it back to 0 now? capacitors?
 
Depends. Adding wildly capacitors is not the way to go. Before symptoms can be successfully treated, the cause has to be found. Check the wiper voltages and the analog input voltage with an oscilloscope when all pots are down to GND to find if this reading of 6 digits is a DC bias/offset because of too high wiring resistance somewhere (or another wiring error, GND being soldered to a wiper instead of the pot‘s GND pin) or if it‘s AC noise due to the multiplexers switching.
But you might also find that everything is fine and that little offset is due to the multiplexers themselves not being ideal switches but resistors which are about 400R in on state and 4MegOhm in off state. In the latter case, I’d try to “fix” that in software by rescaling the readings.
 
all the pots go now from 6 to 1023 .. how would I get it back to 0 now? capacitors?

The map() function or just subtracting 6 (and check for 5 or less and set to zero) might be the simplest way.

If you really are getting a small DC voltage difference in grounds, the hardware fix could involve a lot of work changing wires.
 
The map() function or just subtracting 6 (and check for 5 or less and set to zero) might be the simplest way.

If you really are getting a small DC voltage difference in grounds, the hardware fix could involve a lot of work changing wires.

you mean, changing the wires to something more thicker or something could help?
 
Maybe. Thicker ground wires, directly from the pots to AGND might help. But if you have any other stuff consuming power along the analog ground lines, separating it from the wires that go to AGND would probably also be needed.

Looks like you're using those very thin breadboard wires with the little metal pins on the ends. Some of those wires are so thin you can measure their resistance on the low range of an ordinary multimeter (without special 4-wire measurement normally needed to measure low resistance). I know those wires are very cheap and convenient, but they're not nearly as good as using regular #22 solid core wire, which breadboards were designed to use.

I can just barely see the breadboard in your photo, but it looks like the type where the power lines span only half of the breadboard length. Those are a common problem.
 
Maybe. Thicker ground wires, directly from the pots to AGND might help. But if you have any other stuff consuming power along the analog ground lines, separating it from the wires that go to AGND would probably also be needed.

Hi,
thank you :) I now finally got some thicker cables with solid-core and it seems to solve the most of problem. But now somehow the whole thing seems to be unstable.. the SerialMonitor often stops (but is not dead) and also the serial-port is still beeing recognized. I then have to boot the teensy or re-plug the USB.

Can it have something to do with it? Or maybe too much data? Should I use the thicker cables for the connection between Pot-Data-Pin <-> 4051-In, too?

I can just barely see the breadboard in your photo, but it looks like the type where the power lines span only half of the breadboard length. Those are a common problem.

Yes, you are right, this is one of those breadboards with the GND-Lane broken in the middle.
 
Status
Not open for further replies.
Back
Top