Traveling Tech Guy

I proposed you an algorithm that we used tons of times, and it is working very well.
Of course you must init the vars' values.
The very first "actual" value should match the ADC read.

If you own an Excel-like tool, try that function on the cells.
Cheers

Thanks Mario,
I wasn't suggesting the algorithm doesn't work. Just that it seemed like the variable was uninitialized in the sample you attached.
I'll give your suggestion a try.
Regards,
Guy

Try this average:

const float N = 4;
float actual;

actual = (adc.Read() + (N-1) * actual) / N;

The higher is N the smooth will be the filtering.
The step-response is somewhat exponential.
Cheers

Mario,
I think the result of your equation is non-deterministic: you are using actual before initializing it.
But I see what you're trying to achieve. Still, as I told Chris, the sudden peaks are so far above the norm reading, that even with averaging I'll get crazy results.

Hi Guy,

When the Netduino Plus is talking to a network, there are a lot of interrupts firing the background. These may or may not affect the analog input values. We're doing some tests here to determine if we can disable interrupts completely during analog readings...to see if that clears things up.

It's also possible that the ARM microcontroller on the Netduino has reduced analog accuracy when the embedded network MAC is in use, but it's more likely to be a software issue (resulting in different setup times, readings, etc.)

Many microcontroller apps take multiple readings--and then average them. This may be a scenario with that sort of approach would be appropriate as well.

Chris

Hi Chris,
Thanks for clearing it up. Coming from software problem resolution background, I've seen plenty of problems that are caused by "environmental factors" - i.e. factors surrounding the actual issue, that you'd never even consider to be the root cause. The Netduino+ contains so many layers and functions (network, analog, digital, sd card...) that some background noise is sure to seep in once in a while. I'm glad to see you guys are on top of this. Hopefully it IS a software issue, and can therefore be solved in a future release (any news on 4.2 BTW?)

As for averaging readouts - yes, I thought of that, but how do you average -30 and +300? The behavior is such that the temperature jumps up (or down) and takes several seconds to normalize. If during that time a bright light shines on the senor, it jumps even higher. I'll have to have a longer period of time in my averaging equation - and that would mean losing some resolution (no biggie - it's a fun project, not a crucial application).

One other thing I thought of is registering when the light conditions change drastically, and ignore the temp sensor for several seconds afterwards - using the last sane reading. That would get rid of the peaks as well.

Guy

Hi Guy,

Just to rule anything else out--were you operating without a network cable plugged into your Netduino during this test?

I'm just trying to sort out all the potentials here We've found a few analog sensors which don't work well...whether it's because they can't drive enough current or otherwise...that's what we're trying to sort out. Analog inputs should be pretty simple things.

Chris

Hi Chris,
I tested twice - with, and without the network. The ranges of variance with the network cable are greater than without, but I can confirm bad behavior even when the network cable is not in use.

I then tried 2 modes of cable disconnect: one where the cable itself is still connected to a router, but the router is disconnected from electricity; and one where the cable is completely out. In the second case, it looks like the variance is smaller - almost to the point of no trouble at all, but once in a while the application gets frozen - the last 2 values remain on the screen and won't change again until a forceful reboot. I hope I have not damaged my Netduino with all these games.

To sum it up:
* if I do not have the network cable in, I get accurate results;
* if I have it in but with the router off, I get discrepancies and the program gets stuck after
several such jumps;
*if I have the cable in and the router on, I get crazy discrepancies (that get posted to Pachube sadly - my sensor graph was 14-24 C - it's now -30 - 306 )

How's the Ethernet port affecting the analog pins? Anything else I can try?

Thanks,
Guy

About the Fritzing resistor colors.
The Fritzing drawn resistor is a 330 Ohm, granting an error within -/+ 5%. Orange is 3, black is zero and the 5% tolerance is gold.
The resistor you used is much better: -/+ 1% (last ring brown). Since its precision, it has a ring more, so: orange-orange-black-black ==> 330.0

About the strange value.
I noticed a strange jitter on the ADC readings on my Netduino PLUS, when the ethernet cable is plugged-in. As soon you unplug, the readings are stable. No workarounds, maybe an average.
Could be that?
Cheers

Mario,
My problems started before I added the Ethernet/network component (as you could see in the video) to the equation, and it keeps on happening now.

As for the resistor coloring in Fritzing - I realize both representations end up as 330 Ohm. I was just wondering if I could have Fritzing draw my actual resistor (i.e. 5 rings), rather than a similar one, or do I need to manually add a part?

Thanks,
Guy