10K trimpot outputs big threshold

Hi everyone,
I recently bought a number of 10K trimpots like this one Trimpot 10K Ohm with Knob - COM-09806 - SparkFun Electronics. I connected correctly from what I can gather: left pin to GND, right pin to 5V and the middle pin to A0 on my Arduino UNO. Everything seems to work fine. In my code, all I do is:

void setup() {
  Serial.begin(9600);
}

void loop() {
  int sensorValue = analogRead(A0);    
  Serial.println(sensorValue);             
}

It does read the values to the screen when I open the Serial Monitor, my problem though is that, even if the trimpot is in the same position all the time, the values printed will have a big threshold. For example, not touching the trimpot will still output values from 437 to 502, so the threshold is around 65?! That seems a lot to me, I need something much more precise as I am trying to move a robotic arm, and each 10th of the total value is pretty important.

Could anyone advise me on this? maybe I am doing something wrong?

Careful of long leads.

void loop()
 {
  int sensorValue = analogRead(A0);    
  Serial.println(sensorValue);             
  delay(100);
}

Even so, the output I get is this:

259
255
259
258
259
259
259
259
259
259
288
245
259
262
259
259
264
229
259
259
259
246
258
266
260
259
256
259
262
259
259
259
257
258
260
247
259
266
257
263

The minimum here is 245 and max is 288, threshold of 43? Is this something normal?

Sounds pretty normal. The arduino is a pretty high impedance input so will be sensitive to radio frequency interferance etc.. Take a whole bunch of readings and average them out. You could also put a capacitor between the wiper of the pot to ground.

Could anyone advise me on this? maybe I am doing something wrong?

For the trimpot, they specify contact resistance variation <= 3%
If we use ±3% of 10-bit (ADC), this gives ±32 count (64 count spread).
Not sure if this can be improved ... you effectively only have 32 steps of resolution.

This trimpot has adjustability of 0.05% for ±0.5 count (1 count spread).

argh... so basically i just bought a bunch of useless pots for this project :frowning:

dlloyd:
For the trimpot, they specify contact resistance variation <= 3%

I don't think that should cause variations between successive readings if the pot is not turned.

...R

What might cause such deviations then?

I noticed something else just now, if I turn the trimpot all the way to 0 (min value) or to 1023 (max value), then the readings will constantly show 0 or 1023 without any deviation.

KenF:
Sounds pretty normal. The arduino is a pretty high impedance input so will be sensitive to radio frequency interferance etc.. Take a whole bunch of readings and average them out. You could also put a capacitor between the wiper of the pot to ground.

I don't think that should cause variations between successive readings if the pot is not turned.

Well, its just a mechanical device with brush thats riding on a resistive element - easily influenced by signal noise, temperature, oxidation, vibration. It could be stable for a while, but it also could drift within the CRV tolerance.

I need something much more precise as I am trying to move a robotic arm, and each 10th of the total value is pretty important.

The pots you have should give 3% control (better than 10%). Perhaps they still can be used.

I noticed something else just now, if I turn the trimpot all the way to 0 (min value) or to 1023 (max value), then the readings will constantly show 0 or 1023 without any deviation.

This is normal. At max or min travel, the brush is pressed against or riding over the end contacts (the resistive element is not in the circuit).

KenF:

KenF:
Sounds pretty normal. The arduino is a pretty high impedance input so will be sensitive to radio frequency interferance etc.. Take a whole bunch of readings and average them out. You could also put a capacitor between the wiper of the pot to ground.

I did put a 330 Ohm resistor between the trimpot ground pin and the Arduino ground pin.

LastTemplar:
I did put a 330 Ohm resistor between the trimpot ground pin and the Arduino ground pin.

That will do absolutely nothing to prevent RF interferance. If anything it will make it worse. Have you tried averaging out your values?

KenF:

LastTemplar:
I did put a 330 Ohm resistor between the trimpot ground pin and the Arduino ground pin.

That will do absolutely nothing to prevent RF interferance. If anything it will make it worse. Have you tried averaging out your values?

Should I put the resistor between the middle pin of the trimpot and the analog pin on the Arduino?
Also, is there a special I need to use in the code in order to average the output?

This low-value resistor would go between +V and the pot or between Gnd and the pot, so that, either way, the pot and the resistor are in series.
Won't solve your big problem though.

I mentioned avoiding long leads. Did you catch that?

[What's a digital camera for? I wonder if that could help.]

As per KenF reply#3:

trimpot.png

Write a function that reads the value many times and then divides the value by the number of times it has read it.

Something like:

int AverageValue(int pin)
{
int n;
unsigned int v=0;
for(n=0;n<32;n++)
  v=v+analogRead(pin);
return v/32;
}

Then in your main program, instead of calling analogRead, call averageValue instead.

I don't have my phone at the moment to take a picture, but will take a picture as soon as possible. I do not use long leads, I am using Arduino prototyping male-to-male wires, they're around 10-20cm long maybe?

KenF:
Write a function that reads the value many times and then divides the value by the number of times it has read it.

Something like:

int AverageValue(int pin)

{
int n;
unsigned int v=0;
for(n=0;n<32;n++)
 v=v+analogRead(pin);
return v/32;
}




Then in your main program, instead of calling analogRead, call averageValue instead.

Wow, thanks for this solution, it outputs much more accurate readings now:

734
734
734
735
734
734
734
735
734
732
735
735
734
734
735
735
735
734
735
733
735
734
733
734
734
735

Guys, thank you all for your valuable input into solving this issue, you're great! :slight_smile:
I decided to go with KenF's solution, seems the most viable for me at the moment.