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?

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."

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.

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)

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.

The pressure sensor that I am using is a Freescale MPX4250GP. Freescale has other sensors, but none that quite meet my requiremnts for pressure range. The idea is that the sensor reads CO2 pressure on a keg of beer which can range from 0 to 30psi (this sensor supports 0 to 36psi). Normally, I would have just about any beer at around 10-15psi which puts the output of the sensor within the 3.3V range (should be... I need to check with a multimeter but my CO2 tank is empty), but in the end it would be best to support the full range, which will require an external ADC. I'll just let the ADC communicate with the Netduino at 5V.

I'm still looking at the MCP3002 (it's the only standalone ADC I can find at Sparkfun). I've never done SPI before, but I'm always up for something new.

Alright, I finally picked up the hardware to convert the tubing on my tank down to the 1/8" inside diameter tubing to connect to the pressure sensor. My tank wasn't quite empty (no liquid, but stil enough gas to run a test). I hooked up the sensor, and then eyeballed the values from the guage and I'm pretty accurate according to what the datasheet says I should be getting.

The bottom line is, I don't hit the 3.3V limit until I reach nearly 24psi. At a temperature of 37*F that allows me to put 3.75 volumes of CO2 into a beer and still be able to handle the value on the Netduino ADC. That covers just about any style of beer I will put in there. If I were to put homemade soda, I'd want to raise it to 4volumes, which puts me at 30psi but that would be such a rare occasion I probably dont need to design for it (I can remove the sensor when that happens).

So thanks for all the help. It looks like I'll just be connecting the sensor directly to the arduino, and never raising the guage above 24 while it is connected. To be honest, I'd be afraid of >24psi on that thing anyhow.

There's no need of extra hardware to connect the Netduino SPI to the ADC. The ADC chip is able to recognize an high level when the voltage is at least 3.5V: the Netduino gives it at 3.3V, so it's pretty close to the limit...but it should work. On the other side, any discrete input of the Netduino is +5V-tolerant, which means that you can apply a voltage above the nominal +3.3V.

Anyway, before starting to write code and glue various chips, I'd dig a bit deeper around your sensors. It's much like purchasing a box without actually knowing what's inside.
From what I see, the only doubt is about the pressure sensor. Could you get some additional info? Is it a low pressure (e.g. atmospheric), or high pressure (e.g. weight)? Is it possible for you to simulate a "worst case" pressure, and measure the output voltage with a multimeter?
I guess that you can glue any of your devices to the Netduino with a very small effort.
Cheers

The pressure sensor that I am using is a Freescale MPX4250GP. Freescale has other sensors, but none that quite meet my requiremnts for pressure range. The idea is that the sensor reads CO2 pressure on a keg of beer which can range from 0 to 30psi (this sensor supports 0 to 36psi). Normally, I would have just about any beer at around 10-15psi which puts the output of the sensor within the 3.3V range (should be... I need to check with a multimeter but my CO2 tank is empty), but in the end it would be best to support the full range, which will require an external ADC. I'll just let the ADC communicate with the Netduino at 5V.

I'm still looking at the MCP3002 (it's the only standalone ADC I can find at Sparkfun). I've never done SPI before, but I'm always up for something new.

Alright. I'm pretty set on making this work on the Netduino, so I've been looking into using external ADCs for the pressure sensors and communicating with SPI. For the temperature sensors (which would have worked on 3.3v), I may switch to 1wire DS18B20 and get rid of using analog sensors for temperature completely which makes it s little easier since I don't have to worry about switching the analog pin and sleeping to let it settle.

In looking at external ADC chips (say, MCP3002), I'm a little confused on how I can make the analog comparison get done at a 5V reference whil the SPI communication takes place at 3.3V. That is, unless I can just run it on the 5V and let is go. If the digital pins (10-13 for SPI) allow 5V in, then this could work, as long as 3.3V out will be good enough for the ADC. It still feels a little kludgy though. A really elegant solution would be a ADC that has two voltage inputs one for the data communication (3.3v) and one for the Vref (5V). Does such a thing exist or will the MCP3002 work out just fine?

To be a little more clear, I relaize I can use a transistor or something to make the 5V communication 3.3v instead, but I've never done something like that with data transmission and I have no idea whether it would work or be worthwhile.

Alright. I'm pretty set on making this work on the Netduino, so I've been looking into using external ADCs for the pressure sensors and communicating with SPI. For the temperature sensors (which would have worked on 3.3v), I may switch to 1wire DS18B20 and get rid of using analog sensors for temperature completely which makes it s little easier since I don't have to worry about switching the analog pin and sleeping to let it settle. In looking at external ADC chips (say, MCP3002), I'm a little confused on how I can make the analog comparison get done at a 5V reference whil the SPI communication takes place at 3.3V. That is, unless I can just run it on the 5V and let is go. If the digital pins (10-13 for SPI) allow 5V in, then this could work, as long as 3.3V out will be good enough for the ADC. It still feels a little kludgy though. A really elegant solution would be a ADC that has two voltage inputs one for the data communication (3.3v) and one for the Vref (5V). Does such a thing exist or will the MCP3002 work out just fine?

Hi drischar,

If you know that your analogue sensor output will not be above 3.3V, then there is not a problem. (I am using some 5V range sensors whose analogue output is always below 3.3V.)
If you have others that do generate above 3.3V, then the first thing to try is a voltage divider.
Yes, resistors are not 100% accurate, 5% is typical. You can get round this by calibration of the readings, or buying a batch of resistors and selecting ones that are a good match.
e.g. choose a pair that are both +5%, rather than one that is +4% and one that is -3%. That way you get an accurate ratio with inaccurate resistors.

As for digital sensors, 5V input levels to the Netduino are OK.
But, you might have some issues driving devices with the 3.3V outputs.
There are some shields that will convert digital voltages.

Its a lot to take in, but I'll think you will get on with the Neduino.

Hope this helps - Paul

Given that I can use 5V inputs (I have a few digital sensors that will output 5v), this may still be doable. In total I have:
- 2 analog temperature sensors (TMP36, designed for 3.3v so no problem there)
- 3 analog pressure sensors (from freescale, don't recall model but they require 5v)
- 3 swissflow SF800 flow sensors, no input but will output (input on the Netduino) 5v pulses at about 100-300/second.
- BlueSmirf bluetooth modem, which works fine on 3.3v
- 5V serial LCD, which won't work, but I could just get a 3.3v version and use the 5v elsewhere. Of course, my wife thinks I should leave the LCD out completely, so she may get her wish.

Sounds like this can all still work. I don't need to output 5V anywhere, and as long as the 3.3v inputs won't smoke at 5V I might be able to make this.

This is designed to record data from the 3 tap kegerator I have in my kitchen, if I were to run enough CO2 pressure in the lines to raise the analog input over the 3.3v threshold, I would be in danger of bursting my lines, so I might be able to get by just hooking them straight up to the analog pins.

Thanks everybody, I'll let you know how it goes.

Hi drischar,

A voltage divider would be the first option I'd look at. If that doesn't give you the accuracy you need, you can use an external ADC chip (via SPI or I2C) that can accept 5V analog voltages.

Chris

Thanks for the quick reply. It just occured to me that the digital I/O is also 3.3V based, which actually cuts out a number of digital sensors I am using as well, so I am rethinking this whole move. Unfortunately, everything I have for this project right now is 5V based (serial LCD, digital sensors, analog sensors).

I assume there is no way I can just force the board to use 5V all over without frying things :-P At this point, I would be converting every device I have.

I am working on converting a project of mine over from an Arduino to a Netduino. I'm definitely a noob when it comes to this sort of stuff. From what I understand, the analog inputs on the Netduino use 3.3V rather than the 5V on the Arduino. This causes a bit of trouble as some of my sensors require 5V in order to work correctly. My temperature sensors are great at 3.3V, but I have 3 gas pressure sensors that require 5.1V +- .25V to work correctly. The output of the pressure sensor is a linear value that corresponds to a value between 0 and 250kPa. In order to get these sensors working on the Netduino, I need to figure out a way to convert the 0-5V analog signal into aa 0-3.3V analog signal. I *might* be able to get by without doing this, as I should never exceed ~110kPa and therefore won't break the 3.3V limit, but that's playing a bit more dangerous than I would like. Is there a decent method to drop the voltage down to 3.3 while keeping the accuracy. From what I understand, this is where I would use a voltage divider, but I also don't understand how I can make that accurate enough that I still get the full range of my sensor since the values of resistors are not exact. I ssuppose I could give it a try (15k to 10k?), but I'd like to know if there are better options. Thanks.

I'm working on a project that requires the Netduino to send data over a serial bluetooth connection (using Sparkfun's bluesmirf module). I've got the hardware working fine, but I am having a little trouble on the software side of things. The data I send over the serial connection is a specifically formatted packet, I have code that reads and writes these packets (basically a poor man's serialization since .net micro doesn't support it). I'd like for my solution to have two projects, one build using the .net framework (normal) and the other being the netduino project. I'd like to share one "class library" between the two that describes the packet protocol. Of course, if I create either a .net or .net micro class library, the other project will not let me reference it, and I can't add the files to the projects directly as Visual Studio will make copies of them. Is there a way to produce shared code files? Sort of like I could have some shared headers for a c++ project, without having to build something like a DLL first?