Spikes on analogRead but not on signal

I have a Nano that reads a number of potentiometers.

I have one pot that the analogRead produces random max or min values amongst the good stuff.

I replaced it with a simple voltage divider with two resistors and still had the same effect.

I have four other pots, an IR led, a couple of switches, an OLED on I2C and an NRF24 on SPI all plugged in and everything works just fine except the the pot (I have moved it between A6 and A7 and it doesn't change things).

I've looked for loose connections but couldn't find anything.

5v is supplied to the devices, pots etc from the 5v pin and the Nano is powered via the USB or a battery with voltage regulator going into the 5v pin. Voltage is stable.

I connect the AREF to the 5v and use analogReference(EXTERNAL) in the setup().

The most telling thing I can find is that I checked the signal on an oscilloscope and there is no spiking on the signal going in.

Any ideas where to look next for a cause/answer?

Thanks

acboother:
I connect the AREF to the 5v and use analogReference(EXTERNAL) in the setup().

Why.
Default Aref is already internally connected to 5volt.

So you only have problems with A6 and A7.
Can you try e.g. pin A0.

What is the value of the pot. Is it a lineair pot.
How many A/D values does it jump.
Do you use smoothing in your code.
Leo..

I believe Nano has a decoupling cap from AREF pin to GND, but try another 100nF ceramic to GND and see if it makes a diff.

Cause found. Solution not.

I didn't mention that the analogRead for this pot was in an interrupt callback function generated from Timer1 library code. I didn't mention it because I never imagined it would be an issue. However....

I took the analogRead out of the callback and put it into loop() and the problem goes away. Now have to come up with an alternative strategy for not being able to have it in the callback where I wanted it :expressionless: unless someone knows of a fix for this, this analogRead is going to have to be in the loop().

I did try caps on the pins and changing to the free pins but it didn't help. I even replaced the Nano. Have to try the extra decoupling from AREF to GND when I get back to the workbench later this morning.

I had the 5v connected to AREF and thought the same as you - don't need to do this. But after I removed it I found the pots would not give full 0 - 1023 values as the "5v" voltage seemed to vary as the USB was plugged in and out and the battery supply 'wobbled' a bit.

Perhaps the internal is controlled to 5v even if the external 5v pin isn't... just guessing. Anyhow the pot signals now range properly and consistently.

Analogue read is blocking so may be a bit slow for the ISR or you could be reading the pin to quickly after the analogue mux has changed pins and the sample and hold cap has not fully charged.

I'm surprised the other analogue reads are not affected if your mixing reading in main code and ISR code.

Maybe speeding up ADC readings by altering its prescaler and double reading the pin in the ISR?

Post code example of what your doing?

Wouldn't have wanted to fiddle with the pre-scaler and frequencies just to make the analogRead work as its changing the PWM/callback frequencies that are an important part of this project.

Here are the essential snippets of code

.
.
.
#include <TimerOne.h>
.
.
.
long lPeriod;
long lReading;
.
.
.
void setup(){
 .
 .
 .
 Timer1.initialize(lPeriod);         // initialize timer1
 Timer1.attachInterrupt(callback);  // attaches callback() as a timer overflow interrupt
 .
 .
 .
}
void callback(){
 .
 .
 .
 lReading = analogRead(A7);
 .
 .
 .
}

I checked the timings of the callback and functions and etc with a logic analyser and pin HIGH LOWs on a another digital pin just to make sure the other code, not shown, wasn't taking longer than the time I was leaving for the code to execute.

Typical frequencies in the range 50Hz to 250Hz and lPeriod calculated to suit.

Away for a few days so cannot check the AVR data sheets easily on a tablet but I'm sure the ADC pre scaler does not effect the PWM frequency.