Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

AnalogInput Repeatability


  • Please log in to reply
10 replies to this topic

#1 drischar

drischar

    Member

  • Members
  • PipPip
  • 13 posts

Posted 30 March 2012 - 05:16 AM

By how much should I expect an analog input value to change over multiple reads due to innacuracy on the Netduino itself?

I'm using a number of analog sensors with the Netduino and I'm running into an issue with accuracy.

To remove the possibility that the sensor isn't stable, I've hooked a trimpot up to the analog input between gnd and 3.3V. I also have the netduino hooked up to a 9V wall wart (from Sparkfun, they say it's very stable, my multimeter agrees but I don't think it samples fast enough to really tell).

My code is incredibly simple:
public class Program
    {
        public static void Main()
        {
            AnalogInput trimpot = new AnalogInput(Pins.GPIO_PIN_A0);
            int lastValue = 0;
            while (true)
            {
                int reading = trimpot.Read();
                Debug.Print(reading + " (" + (reading- lastValue) + " change)"); 
                lastValue = reading;

                Thread.Sleep(1000);
            }
        }
    }
The output from this code looks like:
232 (232 change)
230 (-2 change)
233 (3 change)
232 (-1 change)
231 (-1 change)
232 (1 change)
231 (-1 change)
234 (3 change)
230 (-4 change)
226 (-4 change)
230 (4 change)
233 (3 change)
231 (-2 change)
231 (0 change)
As you can see, a difference between consecutive reads can be 4 or more steps, and this is with a guaranteed constant voltage from the trimpot. The difference between the value pf 234 and 226 2seconds later corresponds to a different of nearly 26mV which I would imagine is way outside of tolerance for a usable ADC.

Am I doing something wrong here? I could fix this by using an external ADC over SPI, but before I go down that route (ordering parts, etc) I'd like to know if I can change something to get better results or whether the external ADC (which is also 10 bits) will have the same issue.

I can also always just do multiple reads and average them, but I'm still a little confused about why they vary so largely.

#2 Magpie

Magpie

    Advanced Member

  • Members
  • PipPipPip
  • 279 posts
  • LocationAustralia (south island)

Posted 30 March 2012 - 05:43 AM

I suspect its is noise on your voltage reference. I have got best results using a dedicated Voltage regulator into Aref. Use Vin as your input and ARef on your output. You also need a load resistor so that the voltage regulator's minimum drive is satisfied. (around 1k?) If you have a 7805 you could pad the output down to 3.3v using resistors before putting into AREF. ps. You will need a line of code to use ARef as well. Sorry gotto go. It's beer o'clock.
STEFF Shield High Powered Led Driver shield.

#3 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 30 March 2012 - 06:56 AM

I agree with Magpie. Major problems around the ADC are coming out from the noise over the supply and/or the Aref. Your wall adapter could be a good supply, but if it's a high-efficiency adapter (i.e. switch-mode) it generates *ton* of noise. Exactly the same issue is when you plug the Ethernet cable to the Plus: the noise is getting much higher, and the ADC gets crazy as well. Please, try to perform the *same* test as above, by using a normal 9V battery. Don't connect any thing else (i.e. the USB cable): just the 9V and, if you want, the multimeter. Finally, bear in mind that the ADC embedded in the MCUs are not generally much reliable. They're fine for rough readings, let's say to discard one-two LSBs out of the 10 available. In our high-end devices we *always* use an external ADC (which it costs as much as half at the whole MCU), and a dedicated, well designed Aref generator. That's not coming for free, though! Hope it helps. Cheers
Biggest fault of Netduino? It runs by electricity.

#4 drischar

drischar

    Member

  • Members
  • PipPip
  • 13 posts

Posted 30 March 2012 - 07:03 AM

I suspect its is noise on your voltage reference.

I have got best results using a dedicated Voltage regulator into Aref.
Use Vin as your input and ARef on your output. You also need a load resistor so that the voltage regulator's minimum drive is satisfied. (around 1k?)
If you have a 7805 you could pad the output down to 3.3v using resistors before putting into AREF.

ps. You will need a line of code to use ARef as well.

Sorry gotto go. It's beer o'clock.

Interesting. I should have a 3.3v regulator around here somewhere but I'm not sure why it would be unsteady if the power supply wasn't having issues. Just on a whim I connected A0 to Aref to make sure I would get a steady value. Theoretically, even if the voltage were to waver, shouldn't I expect it would still result in 1023 every time? After all, if the voltage from the 3.3V pin were to drop to say 3.1, then I'd be comparing 3.1V to 3.1V which would still yield 1023.

This does seem to bear out. I still get some 4 step changes, but I imagine that's unrelated. I see way more 0s here thant before, but then again, that's probably because its impossible to return a value > 1023. I'll try using an external aref and see if it helps.
1023 (0 change)
1023 (0 change)
1023 (0 change)
1023 (0 change)
1022 (-1 change)
1023 (1 change)
1019 (-4 change)
1023 (4 change)
1023 (0 change)
1023 (0 change)
1023 (0 change)
1023 (0 change)
1021 (-2 change)
1023 (2 change)
1023 (0 change)
1023 (0 change)
1023 (0 change)


#5 drischar

drischar

    Member

  • Members
  • PipPip
  • 13 posts

Posted 30 March 2012 - 07:17 AM

I agree with Magpie.
Major problems around the ADC are coming out from the noise over the supply and/or the Aref. Your wall adapter could be a good supply, but if it's a high-efficiency adapter (i.e. switch-mode) it generates *ton* of noise.
Exactly the same issue is when you plug the Ethernet cable to the Plus: the noise is getting much higher, and the ADC gets crazy as well.
Please, try to perform the *same* test as above, by using a normal 9V battery. Don't connect any thing else (i.e. the USB cable): just the 9V and, if you want, the multimeter.

Finally, bear in mind that the ADC embedded in the MCUs are not generally much reliable. They're fine for rough readings, let's say to discard one-two LSBs out of the 10 available.
In our high-end devices we *always* use an external ADC (which it costs as much as half at the whole MCU), and a dedicated, well designed Aref generator. That's not coming for free, though!

Hope it helps.
Cheers

I hooked Aref and the trimpot up to my benchtop power supply with a multimeter running as well. I'm not seeing so much as a millivolt change, and I do seem to be getting slightly more accurate results:
784 (0 change)
785 (1 change)
785 (0 change)
784 (-1 change)
786 (2 change)
785 (-1 change)
785 (0 change)
785 (0 change)
785 (0 change)
784 (-1 change)
784 (0 change)
784 (0 change)
784 (0 change)
785 (1 change)
786 (1 change)
785 (-1 change)
785 (0 change)
785 (0 change)
785 (0 change)
It's a major shame that the 3.3V is so bouncy. When I hook my meter up to the 3.3V supply on the board it looks stable (this is using the Neetduino's 3.3v regulator), but I don't have the ability to see changes of short duration.

#6 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 30 March 2012 - 08:21 AM

It's a major shame that the 3.3V is so bouncy. When I hook my meter up to the 3.3V supply on the board it looks stable (this is using the Neetduino's 3.3v regulator), but I don't have the ability to see changes of short duration.



Only apparently.
Your multimeter gets you 3-4 readings per second, thus its filtering on the input is *very* effective. The Netduino is able to sample its analog input at 1k/sec.

Suppose having a ripple sine wave of the mains entering in the wires (50 or 60Hz). Let's say 100 mV of amplitude out of 120 or 230VAC (I don't know your mains voltage). The multimeter filters so much the input that a similar frequency is totally irrelevant. At contrary, the Netduino could shape the sine wave almost perfectly, yielding you the "real" noise on the input.

That was just an example to make you understanding how the things could be.
Cheers
Biggest fault of Netduino? It runs by electricity.

#7 drischar

drischar

    Member

  • Members
  • PipPip
  • 13 posts

Posted 30 March 2012 - 08:34 AM



Only apparently.
Your multimeter gets you 3-4 readings per second, thus its filtering on the input is *very* effective. The Netduino is able to sample its analog input at 1k/sec.

Suppose having a ripple sine wave of the mains entering in the wires (50 or 60Hz). Let's say 100 mV of amplitude out of 120 or 230VAC (I don't know your mains voltage). The multimeter filters so much the input that a similar frequency is totally irrelevant. At contrary, the Netduino could shape the sine wave almost perfectly, yielding you the "real" noise on the input.

That was just an example to make you understanding how the things could be.
Cheers

That was what I meant by "but I don't have the ability to see changes of short duration."

#8 Stefan W.

Stefan W.

    Advanced Member

  • Members
  • PipPipPip
  • 153 posts

Posted 30 March 2012 - 08:35 AM

It's a major shame that the 3.3V is so bouncy. When I hook my meter up to the 3.3V supply on the board it looks stable (this is using the Neetduino's 3.3v regulator), but I don't have the ability to see changes of short duration.


Yes, to see power supply noise you need an oscilloscope, not a multimeter. And the values you see now are "normal" - the last bits of the measurement are usually "noise".
I believe that no discovery of fact, however trivial, can be wholly useless to the race, and that no trumpeting of falsehood, however virtuous in intent, can be anything but vicious.
-- H.L. Mencken, "What I Believe"

#9 emg

emg

    Advanced Member

  • Members
  • PipPipPip
  • 129 posts

Posted 30 March 2012 - 10:05 AM

If you have a low sampling frequency requirement, I solved this by taking about 30 samples over a second and calculating a median value to use. Any use?

#10 drischar

drischar

    Member

  • Members
  • PipPip
  • 13 posts

Posted 31 March 2012 - 01:54 AM

If you have a low sampling frequency requirement, I solved this by taking about 30 samples over a second and calculating a median value to use. Any use?

Definitely, I've decided to poll the value a dozen times or so, toss out the max and min, and take the average. This is yielding great results, and it doesn't seem to take an inordinate amount of time to do it.

I just call AnalogInput.Read() in a for loop, do you find it's usefull to put a delay in as well to space out the readings?

#11 emg

emg

    Advanced Member

  • Members
  • PipPipPip
  • 129 posts

Posted 31 March 2012 - 06:58 AM

I just call AnalogInput.Read() in a for loop, do you find it's usefull to put a delay in as well to space out the readings?


I do both. Not so much for accuracy but to avoid tight loops. I tend to be over cautious with the very limited resources. Plenty of thread sleeps everywhere.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.