Analog Cross-talk within atmega

Where to begin...

I have been working on a project and one part is to control a DC motor so on and so forth... not the problem.

I have one pot for feedback from the motor and one pot for control. My problem is as one pot changes, it influences the values of the other pot. Ive tried adding more pots and one always affects the other reading. Ive checked all voltages going in and they are constant even as the values change.

We did find a Mcgyverish solution to it.

Suppose I am reading two pots. I must attach one to A1, and one to A3. A0 and A2 must be grounded... and that's not all I need to read A0 and A2, but just ignore the values and then read the values of A1 and A3 I actually want. If this is done, one pot does not affect another. Due to this I am fairly confident it is internal to the Atmega

This works, but I can only use half of my analog pins, but ill need more than that in the end (Im already using a mega).

Does anyone know how this is happening/ how to fix it.

I would be happy to post more information if this isn't enough.

-Nick

What value pots are you using. The arduino analog input pins like to 'see' 10k ohms or lower of source impedance for best results.

Lefty

Both are 10K linear taper

There can be several problems.

First, if some ADC channels are floating, they will read spurious values which are related to
the fact the sampling cap is still holding some remnant of the value from the previous channel
read.

Secondly, if the source-impedances to the ADC are > 10K or so, you don't get accurate readings,
as the sampling cap does not have time for full-settling.

Thirdly, you might try doing 2 ADC reads in a row on a channel, and see if the 2nd read is more
accurate.

Fourthly, if you have a signal coming from a motor, you might want to low-pass filter it with a
cap, and smooth out any motor noise. Eg, if you have a current-sensing R in the motor line,
you can tap off of it with a 10K, 0.1uF RC filter, etc.

I agree with that:

Thirdly, you might try doing 2 ADC reads in a row on a channel, and see if the 2nd read is more
accurate.

You may increase accuracy taking more readings, than take average:

  uint16_t summ = 0;
  
   for( uint8_t k = 0; k < 64; k++ )
   {
    summ += analogRead(adc_InPin);
   }
   summ /= 64;
   adc_Input = summ;

oric_dan:
First, if some ADC channels are floating, they will read spurious values which are related to
the fact the sampling cap is still holding some remnant of the value from the previous channel
read.

Then why does grounding the channels near it and reading them fix that?

N314:

oric_dan:
First, if some ADC channels are floating, they will read spurious values which are related to
the fact the sampling cap is still holding some remnant of the value from the previous channel
read.

Then why does grounding the channels near it and reading them fix that?

Because now you have a hard voltage [0V] on the grounded pins, and a firm ADC reading.

Then why does grounding the channels near it and reading them fix that?

Because the zero volts discharges the sample and hold capacitor.

If you are using 10K pots and get this effect you have something else wrong, maybe the pot value is not what you think, maybe the wiring is wrong, like a ground is not connected correctly.

So if I were to read a pot, then read a grounded pin, another pot, and then the same grounded pin, [so on and so forth] would that discharge the cap each time?

-Nick

N314:
So if I were to read a pot, then read a grounded pin, another pot, and then the same grounded pin, [so on and so forth] would that discharge the cap each time?

-Nick

Yes

If you have a hard voltage on the pin, then the sampling cap will charge to that value. If the
pin is floating, then the charge on the sampling cap will not change, or will change in some
indeterminate way, and the reading will be irrelevant. Take a look at the ADC input cktry in
the ATmega datasheet.

There are at least three simple solutions for avoiding crosstalk between analog inputs:

  1. Patch wiring_analog.c to insert a few microseconds delay in the analogRead code between setting the multiplexer to the desired channel and starting a conversion. The delay you need is about 1us per 10K of source resistance.

  2. Equivalent to (1) but less invasive, write your own function to set the multiplexer to the correct channel, delay a few microseconds then then call analogRead. Use this as a replacement for analogRead.

  3. Connect a 0.01uF or 0.1uF capacitor between each analog input and ground.

Taking multiple readings from the same pin and discarding all but the last one works in a similar way to solutions (1) and (2) but is slower and less effective, especially when the source resistance is high.

However, you should not be getting crosstalk between analog inputs if they are all fed directly from 10K pots, since the source resistance will be 2.5K at worst. Are you certain the pots are 10K? Do you see the same problem when the motors are disconnected?

Something a bit odd is happening - do you have a schematic of your circuit? You are running a standard Arduino setup
with a standard Arduino board? Using Vcc as the reference for analogRead(). You shouldn't see more than a fraction of 1LSB
cross-channel interference in those circumstances as I understand it (unless you tinker with the ADC clock settings).

How big an effect is it?

Normal arduino board.

No shift at the edges, but up to 100 on a 10 bit read at its worst.

Ive had someone else check the circuit and pots and they're fine.

-Nick

Normal arduino board.

No shift at the edges, but up to 100 on a 10 bit read at its worst.

Ive had someone else check the circuit and pots and they're fine.

-Nick

Yeah but there's no such thing as magic either and that is next...

Bob

Ive had someone else check the circuit and pots and they're fine.

All that means is that they have failed to find the problem.
As you see from multiple people this is not the way this circuit behaves.
You need to post both a schematic and a good photograph of your setup.

Grumpy_Mike:

Ive had someone else check the circuit and pots and they're fine.

All that means is that they have failed to find the problem.
As you see from multiple people this is not the way this circuit behaves.
You need to post both a schematic and a good photograph of your setup.

The other person who checked it is an electrical engineer. We monitored voltages going in, supply, ground, and checked the pots. We spent 3 hours on it and TRUST ME... It is contained within the chip, the external circuit is good.

But Ill try to sketch a schematic next time I have a chance to look at it.

-Nick

A0 and A2 must be grounded... and that's not all I need to read A0 and A2

I don't quite follow this statement, I didn't think these were the pins you were reading? I thought you were reading 1 and 3? You haven't connected the ground pin of each pot to A0 and A2 respectively have you, with the other pin going to 5v?

I find it strange that you think you've found an issue with the microcontroller, with such a simple circuit... Like you say, post up the schematic - there must be something wrong. :slight_smile:

jtw11:
I didn't think these were the pins you were reading? I thought you were reading 1 and 3?

This behaviour and why this seems to work, has been explained.
Reading those inputs that are grounded, clears the sample capacitor.
OP says however he has to read the ones which are grounded, and then read the ones he actually wants to read.
That suggests he's reading A0, A2, A1, A3 in that order.
If that is actually true, the previous explanation doesn't make sense, but if the order is A0, A1, A2, A3 is read, it absolutely makes sense.

There seems to be nothing to keep OP from trying this by changing the sketch to read A0, A1, A0, A3.
If that also works, OP will know that clearing the capacitor is needed.
Or waiting for it to have discharged on its own.
By the way, i have seen comments in the examples, telling that you have to wait a bit between 2 consecutive analog reads, this thread explained me why.

One possibility is that the microcontroller is damaged - has this been ruled out?