Wait a second...

Several posts back, you posted code with a call to selftest() in the setup routine. And you stated that the measurements in loop() were correct.

That is how the ATMega328 is SUPPOSED to work!

So what is the remaining question?

From my point of view you had working code. You coded it exactly as you were supposed to. It was returning valid results...

My link said that processor required an initial read, whose value MUST be ignored. It’s how I’ve always done it.

I’m confused...

 

Wait a second...

Several posts back, you posted code with a call to selftest() in the setup routine. And you stated that the measurements in loop() were correct.

That is how the ATMega328 is SUPPOSED to work!

So what is the remaining question?

From my point of view you had working code. You coded it exactly as you were supposed to. It was returning valid results...

My link said that processor required an initial read, whose value MUST be ignored.

I’m confused...

Ok Ok... There is no problem with this. I know now that I have to do a couple of dummy analogreads during setup and then the measured values will be reliable. Then I can perform a couple of consecutive analogreads everytime and average the values to achieve more consistent results.

 

JUST FOR ILLUSTRATION:

Do you have a pull-down R as you see here as R2? [from Gammon.com] I realize that you have not shown the schematic for your driver, but a missing R2 could, conceivably to me, cause such "possession".

Devil removed from the circuit! Thank you very much...

 

Thanks to all contributors again... This thread has been really awesome for me. I have learned so much...

 

================================================
The thread has basically finished and positively so. I have a brief addendum for my own edification.

I simply can not reproduce a first read error and I have tried to, using an UNO, with or without the internal reference set. I did read the thread that @djsfantasi linked. It's a fine thread and there are some "rules" and generalities and stuff pertaining to switching channels and so on. Nevertheless I simply can not get that error and I don't know why.

I was looking at this to try to determine whether it is a "reading" or "waiting" issue. I get that the easiest and low-cost solution in either case may simply be two do an initial throw-away read, it just bothers me that I can't see it in action.

Looking at the datasheet http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf
Section 24.4:

When the bandgap reference voltage is used as input to the ADC, it will take a certain time for the voltage to stabilize. If not stabilized, the first value read after the first conversion may be wrong.

So, I am not doubting it at all, I just can't get it to do that - even if I set the internal reference (which should incur the delay above) and do an immediate read. Maybe more recent Arduino versions mitigate the effect behind the scenes. I don't know.

Remember, the TS is using a standalone AT328. Does anyone have an example with an UNO that can illustrate the error?

 

@sumeryamaner In one of your first posts you stated "I have tried to call checkvolt() a couple of times in the setup() as a kind of initialisation but there was no change." If clearing the first read after power up is required then why didn't this fix your problem?

@Raymond Genovese I can understand your problem if you can't reproduce his problem. He is using a standalone chip not an Arduino. Could that have something to do with it? Also, are you looking at the first read "after power up"? That is suggested in the forum link provided by djifantasi.

 

@sumeryamaner In one of your first posts you stated "I have tried to call checkvolt() a couple of times in the setup() as a kind of initialisation but there was no change." If clearing the first read after power up is required then why didn't this fix your problem?

I think, if I do consecutive reads without a significant delay it does not work but if there is some code (and some delay) between the reads, the results are acceptable.

 

@Raymond Genovese I can understand your problem if you can't reproduce his problem. He is using a standalone chip not an Arduino. Could that have something to do with it? Also, are you looking at the first read "after power up"? That is suggested in the forum link provided by djifantasi.

I just want to acknowledge first that the TS, as far as I can tell, has found his solution and that I am going off on a tangent.

I have looked at the first read after power up and immediately after setting the bandgap reference to the internal reference. At least, I think I am. Here is the UNO code.

This first read issue is an old one and it was even included in the "rules" in a previous thread, i.e., toss the first read. I am going out of my way to try and see the first read problem as described in the quoted section of the data sheet. I can't do it and I do not know why.

As an aside, I just received some ATMEGA4809 boards (they were on sale for $6). I may look at this issue again, just for the heck of it using that board (assuming that the datasheet mentions the same for ADC).

//AT328AinTest

#define AinPin A0

int x,Raw[3];
float V[3];
void setup ()
{
  analogReference(INTERNAL);
  Raw[0] = analogRead(AinPin);
  delay(100);
  Raw[1] = analogRead(AinPin);
  delay(100);
  Raw[2] = analogRead(AinPin);
}
void loop()
{
  Serial.begin(9600);
  delay(3000);
  for(x=0;x<3;x++){
  V[x]=( (Raw[x]*1.1)/1024);
  Serial.print("Reading:");
  Serial.print(x+1);
  Serial.print(" =");
  Serial.print(V[x]);
  Serial.println(" volts");
  }
here: goto here;
}

 

Hi sumeryamaner, I might have completely lost the plot here but.. have you taken account of this:

i.e. if you are getting multiple consecutive results, you set the ADC channel, then take the ADC reading which will actually responds to the previous ADC channel selection.

 

Hi sumeryamaner, I might have completely lost the plot here but.. have you taken account of this:
View attachment 172411
i.e. if you are getting multiple consecutive results, you set the ADC channel, then take the ADC reading which will actually responds to the previous ADC channel selection.

I have seen that, but as you can see, he was never switching channels [or using free-running mode]. In the example code that I just posted, I tried incurring a bad read by modifying it to be switching channels and still could not do it. Sure, it is possible that a delay is somewhere in Arduino "system" code, but I don't know where or if it has been documented as such.