Archived Forum

Read the Atmel Data Sheet. On Page 253: "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." I cannot see a delay in your sketch, so that is the first thing to look at.

right! i had added a delay (it's inside the if statement that checks the temperature) but it was BEFORE changing the reference voltage. duh!.

I'm going to change that to see if it helps.

Thanks

I'm not sure that will actually help.  If you read the source code for analogReference() you'll see it doesn't go anywhere near the ADC hardware, but rather remembers the setting and programs it up during the next call to analogRead(). So even if you shift your delay() to after you call analogReference(), it'll still be happening too early.

There's a comment in the code to explain why they have to do that.  They're trying to be safe in the case where someone is providing an external Vref.

I think you have two options:

1. break away from using the Arduino calls, and bang directly on the ADC registers yourself    OR

2. instead of spending your delay() doing nothing, sit in a tight loop calling analogRead() and discard the result.

#2 relies on the observation (or hope?) that re-programming ADMUX with its current value doesn't count with regards the need for setting time, which is probably safe.

Assuming your Arduino has a decoupling cap on AREF (as recommended) then you'll probably also need a delay as you change back to the default reference voltage (AVCC) for power monitoring.  While selecting AVCC as your reference isn't strictly a bandgap reference (so strictly speaking isn't included in Robert's datasheet reference above), whatever reference you choose gets sent out to that decoupling cap, so you don't want to be doing any conversions until it's reached steady state.  Given you're measuring an AC signal after you set it back to AVCC you wouldn't necessarily notice problems with that reading, unless you were collecting and plotting the results.

you were right. it didn't help.. i had another error spike a few hours ago..

i half understand what you're saying so i guess option #1 is off the board for now :S

in simple words, the delay only counts as long as i'm reading the analog pin?

is it possible my arduino board already has a decoupling cap? if not, i just need to add a capacitor between the aref and ground pin (even though my new analog reference is an internal 1.1v source and not the aref pin)?

for the power part, you're right, i think i get steady values; the voltage does varies, but the mains are never constant (and even less so in my town!).. power is more stable though but i'll make some dummy readings on it for the sake of doing things right.

i'll try to add the following lines instead of the delay:

started_at = millis();

while(millis()-started_at<1000)

int tmp = analog.read(%pins%);

in simple words, the delay only counts as long as i'm reading the analog pin?

Almost.  It's more that the new reference isn't selected until you read an analog pin.

is it possible my arduino board already has a decoupling cap?

Definitely.  You'd need to check the schematic for your particular Arduino board.  It's also possible that it may get decoupled on shields too.

if not, i just need to add a capacitor between the aref and ground pin (even though my new analog reference is an internal 1.1v source and not the aref pin)?

Correct.  The AREF pin is dual-purpose.  You can feed it an external Vref of any voltage you want (between 1V and Vcc), or when you're using an internal reference (like you are in both cases)  the internal Vref runs out to that pin and they ask that you decouple it for them, with a cap to ground.

for the power part, you're right, i think i get steady values; the voltage does varies, but the mains are never constant (and even less so in my town!)

Actually, you're reading a sine wave there, so you should be getting anything but steady values.  After you've grabbed lots of samples, and calculated the RMS, you may or may not get steady values depending on your local grid.  AREF settling errors in the early samples wouldn't necessarily show up as a varying RMS reading, but it might make calibration tricky.

Your suggested loop should work.  I suspect 1 second is a major overkill, so you could look at paring that right back once you've confirmed it fixes it.  You could probably even lose the timer and just make it count based if you prefer.  Each call to analogRead() takes about 110 usecs from memory, so just as do as many as required to get consistent readings, plus some for an extra safety margin.

I'm still not entirely sure this is the cause of your problem. The cap behaviour is quite deterministic, so I would have expected it to be fairly consistent rather than spiky like you're finding(*).  But it's worth eliminating before investigating further.

(*) I'm assuming your board already has a decoupling cap.  If it doesn't, then it could well be noise that might get fixed by adding the cap.

Definitely.  You'd need to check the schematic for your particular Arduino board.  It's also possible that it may get decoupled on shields too.

yes, it's an Arduino Uno Rev3 board. This schematic shows a 100nF cap on the AREF pin :)

Your suggested loop should work.  I suspect 1 second is a major overkill, so you could look at paring that right back once you've confirmed it fixes it.

So far, it's been 12 hours without an accident, but it's too soon to claim victory.

Actually, you're reading a sine wave there, so you should be getting anything but steady values.

 I use emonlib, which handles all the calculations and returns the Vrms, Irms, and power numbers.. i was talking about those calculated values, not the raw data from the analog pin.

I'm still not entirely sure this is the cause of your problem. The cap behaviour is quite deterministic, so I would have expected it to be fairly consistent rather than spiky like you're finding(*).  But it's worth eliminating before investigating further.

Let's hope this solves the issue.. i'll report back in 12 hours.

Thanks for the help! I'm in debt with you :)

Welp.. despite the loop, i still have some spikes in TempErr :(
however, i've already learned something from this thread so it's not all lost..

I hope this thread helps someone else.

for now, i'll blame the poor quality of my sensor..

It's hard to know what causes your spikes.  Do they happen at a fairly regular time, or coincide with some nearby equipment switching on/off?

Even if you're prepared to live with them, I think you'll get more accurate results (both temperature and power) if you waste the first x readings after you change the reference, where x needs to be determined, but I'm guessing in the order of about 20 to 100 readings, which would take about 2 to 11 msecs.

It's pretty easy to test if you need to do that.  After you select the 1.1V reference, take 100 readings of the temperature input as fast as you can, into an array.  After(*) you've collected all 100, print out the raw readings and I suspect you'll see them ramp up as AREF slowly decays down to 1.1V.   Hopefully they'll stabilise well before the end of the array, and that'll give you an idea of how many you need to waste.  You really don't want to be including those early numbers in your average as they're completely bogus.    

Ditto in the other direction after you've selected Vcc as the reference, you don't want to be including the early voltage/current samples in the emonlib calculations.   All that averaging, and RMSing does a good job at hiding issues like this but the bogus values can't help but mess with your overall accuracy/calibration.  You won't be able to do the "sample into an array" technique in this direction because what you are sampling is a fast moving target in any case.  But whatever 'x' you determine you need in the Vcc -> 1.1V direction will hopefully suffice in the 1.1V -> Vcc direction as well.

(*) You can't print them out as you read them because the print takes so long it will act as a delay.

ok, thanks for the advice. i'll calibrate it at another time, for now i'll stick with half a second. 

I thought about that too (maybe the current sensor was screwing my measurement) but when i plot the temperr and power together i get no correlation, at least with the high consuming parts.. and it looks pretty random.. maybe later on it will show a pattern (bear in mind that those prolonged periods of error were due to me measuring wrong, which got better at the end of the graph due to me adding some delays here and there).

edit: is it a coincidence that it failed at noon the last two days? hmm...

Actually, I just looked at your code again.  I think you're already doing what I suggested.....

        analogReference(INTERNAL);
   
        for(i=0;i<(DATASIZE2+50);i++) {
          sensorValue = analogRead(sensorPin);
          if(i>49){
            TempSample[i-50]=sensorValue/9.31;
          }
        }

That looks to me like it's doing 50 extra reads up front that get ignored, then it gets on with doing DATASIZE2 reads on top of that.  It looks like whoever wrote that code knew about letting AREF settle.    Probably worth doing something similar when you switch back to Vcc as your reference and then you're done.

that's my code! i had forgot already about that.

it's just that i started working on this a year ago but dropped it for lack of time, and i had read about the decoupling stuff then (albeit very superficially).

sadly, the error keeps spiking. just today i had 4 separate spikes and two of them when i wasn't even at home, so i guess that failure due to a certain equipment turning on is off the table (particularly because i couldn't find any correlation with the fridge/water heater which are the only two things in my house that turn on/off automatically).

and i can't see any correlation with the temperature neither :(

i'll try buying another sensor (i can buy them really cheap ~3$ since they use them all over town for the big clock/thermometers in the streets) and rule out a bad sensor, but for the price tag i would believe if you told me it's a normal thing to happen every now and then.

in case it's useful for anyone, here's my final code for the project.

I've cleaned it up a bit and added some comments.

I've had similar issues with two LM35's on my system. I made a big improvement by adding a pull-down resistor of 1K on the outputs. I also put a diode in series with the LM35 gnd pin to introduce a 'sort of' negative voltage. This adds a significant error in the temperature reading but this is easily corrected in software. This way the LM35s can cope with negative temperatures. A 1.2v zener would be better still, I may add that at a later stage.

Geo

bugthebees.blogspot.com

Hi,

Have you consider using screened cable, when connecting LM 35 to main board ? 

Probably there is some environment noise that is interfering to LM 35.

Hopefully, this will help