Accurately reading a 50k pot

[yeahtuna]

Hi,

I'm writing to see if I can get some suggestions as to how I can improve the measuring accuracy of a 50k pot (analog guitar volume pedal). I've done some research on the matter and from what I can tell, the Atmel chips are optimized for reading 10k pots. What I have read seems to indicate 50k pots need to be sampled for a longer amount of time in order to charge up the sample and hold capacitor in the ADC input stage.

I already have very functional smoothing filters that smooth things out for the most part, however reading a 50k while it's being slowly turned still results in very noisy data.

Is there anything I can do to improve the accuracy? This page seems to have some information on the subject, but I think it's a bit over my head.

Would under-clocking the Teensy 2.0 help?

Any suggestions would be much appreciated.

Regards,
Rob

 

[PaulStoffregen]

You could try changing the ADC prescaler setting.

Underclocking the CPU won't matter, because the code will automatically adjust the prescaler setting.

If the 50K pot is connected through long wires, and especially if the ground wire also connects to other stuff, I'd first try a 50K pot connected close to the Teensy, using 3 dedicated wires. Even if that doesn't give good enough results, it can be a reference for comparison to measuring one connected via long wires.

 

[yeahtuna]

You could try changing the ADC prescaler setting.

Underclocking the CPU won't matter, because the code will automatically adjust the prescaler setting.

If the 50K pot is connected through long wires, and especially if the ground wire also connects to other stuff, I'd first try a 50K pot connected close to the Teensy, using 3 dedicated wires. Even if that doesn't give good enough results, it can be a reference for comparison to measuring one connected via long wires.

Thanks, Paul. I'll give that a try tonight. I've also read that disabling digital input buffers could help. Do you know how I could selectively disable them for given inputs?

 

[Tomek]

Thanks, Paul. I'll give that a try tonight. I've also read that disabling digital input buffers could help. Do you know how I could selectively disable them for given inputs?

Some of the analog pins already are not connect to the digital input buffers. A10 and A11 I know to be one pair, but there are more. These are NOT 5V TOLERANT to be a friendly reminder. They are just AREF tolerant and maybe Vin tolerant (I'm not sure if it's only to the AREF or the mcu voltage.) This would be the way you could test your theory. Also remember the analog pins not connected to the digital input buffers cannot work for the digitalRead function.

Edit: btw I just checked, it's A10,A11,A12,A13 and A14 which are not 5V tolerant as a consequence of not being connected to the digital input buffer, or somehow related to that fact.

It's important to note you haven't mentioned what sort of filtering you have. Do you mean software filtering, or hardware filtering?

If you do not need a fast response, *It is my understanding but ought to be verified by someone else!!* that a 200-300pF capacitor between the analog pin and Agnd, would buffer the high impedance signal.

But it would also slow down your response. For example, to go from 1V to 2V, it would take 6.9315mS according to http://ladyada.net/library/rccalc.html (within some accuracy, I am not sure I just skimmed that calculator. Usually it's something like with 99.9% or 99.999%).

 

[yeahtuna]

Some of the analog pins already are not connect to the digital input buffers. A10 and A11 I know to be one pair, but there are more. These are NOT 5V TOLERANT to be a friendly reminder. They are just AREF tolerant and maybe Vin tolerant (I'm not sure if it's only to the AREF or the mcu voltage.) This would be the way you could test your theory. Also remember the analog pins not connected to the digital input buffers cannot work for the digitalRead function.

Edit: btw I just checked, it's A10,A11,A12,A13 and A14 which are not 5V tolerant as a consequence of not being connected to the digital input buffer, or somehow related to that fact.

You must be referring to the Teensy 3.1? I'm using the Teensy 2.0. I poked around looking for how to adjust the ADC prescaler. I'm guessing I can't simply do this on a per sketch basis. I assume I need to modify the value in wiring_private.h? Here's the relavant code.

#if F_CPU == 16000000L
#define ADC_PRESCALER 0x07
#define CPU_PRESCALER 0x00
#elif F_CPU == 8000000L
#define ADC_PRESCALER 0x06
#define CPU_PRESCALER 0x01
#elif F_CPU == 4000000L
#define ADC_PRESCALER 0x05
#define CPU_PRESCALER 0x02
#elif F_CPU == 2000000L
#define ADC_PRESCALER 0x04
#define CPU_PRESCALER 0x03
#elif F_CPU == 1000000L
#define ADC_PRESCALER 0x03
#define CPU_PRESCALER 0x04
#else
#error "Teensyduino only supports 16, 8, 4, 2, 1 MHz.  Please edit boards.txt"
#endif

The pins that I would like to turn off the digital input buffers on are pins A0, A2 A4, and A6. Pins A1, A3, A5, and A7 are also only used for analog read, so if they were affected, that would not be a problem. The problem is that I'm not really sure where or how I should be turning them off.

It's important to note you haven't mentioned what sort of filtering you have. Do you mean software filtering, or hardware filtering?

I'm using software filtering. It's my own algorithm which I'll share below. The response of this filter is such that small changes are heavily filtered, but larger changes are not, allowing this filter to still be quite responsive.

class Smoothing
{
public:
	Smoothing() {a = 0.95f; z = 0; s = 0; }


	float Process(float in) {
		s = a - abs(in - z);
		z = (in * (1-s)) + (z *s); 
		return z; 
	}

private:

	float a, s, z;

};

If you do not need a fast response, *It is my understanding but ought to be verified by someone else!!* that a 200-300pF capacitor between the analog pin and Agnd, would buffer the high impedance signal.

I need a software only solution as this will be part of a firmware update to a product that is already in the wild. Thanks for your input thus far.

Regards,
Rob

 

[Tomek]

ok, good luck. Sorry about my input, I was completely off-base to not realize it was teensy 2.0. Yes, I was referring to teensy 3.1