Best way to read AD result.

[hmmpic]

I use the ad converter to get the ambiance temp (0-50deg.C), the resolution on the ad is 8 bit. I make one sample every 1 minutes.

What is the most stable way to get accurate result from the ad converter.
I think 1 read can get a wrong sample, therefore I looking for smarter way to do it.
I don't want the simple 5, 10 or more sample way.
Maybe something like, read 2 times and compare is diff is more than some bit, then take 2 new samples.

I looking for some clever experience on this.

[temtronic]

First you don't say what kind of sensor you're using, but for sake of discussion I'll assume a linear transducer like the LM34 or MCP9700 series.

For 8 bit readings, I declare an INT16, loop and sum 8 readings, then take the average(magical /8). It's very fast, simple, reliable, at least for the past 25 years. Works great with 16, 10 bit readings as well.

Since you're not into high precision, this will work fine.

For 'Stable' readings, use a precision reference IC for Vref, proper filtering of the A2D line, rail to rail buffering of the signal, reduce EMI noise with overall bypass filtering (power lines), board layout, GROUNDS, etc. There is no pont in some 'fancy' math if the original readings are not true!

[hmmpic]

Hi

Yes I use Microchips MCP97...

The way with summing a lot of samples is not what i want. If you read 128 bit in ex. 9 read and then you in the 10 read get 255 then you have an big error. Therefore a lot of samples must be read.

Any other suggestion?

[SherpaDoug]

The Olympic Average method works well to eliminate occasional bad readings. Search this forum for "olympic" for more info.

The formal way to deal with this is a Median Filter, but that takes a lot more CPU resources than the Olympic method.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[temtronic]

One problem I see, is your 'one reading per minute.'
Unless the environment where the sensor is is very stable and 'thermally slow', how can you figure out a 'bad' single reading from a real high rate of rise in temperature. PS.what do you do if a 'glitch' trashes that ONE reading?

Currently I'm testing thermistors,LM34,MCP9700 and DS18B20s for a project. The LM34 is winning so far (1/2 the cost of the Dallas chip), better than the MCP9700 performance. However, it's a 'battle' of 3 pins vs. 2, overall cost (LM34 needs caps,rs,etc.), distance vs. noise,etc.
Actual PIC, code space and programming are not real factors.

Given the one reading per minute mandate, I'd probably use the digital Dallas chip, unless you accept to take say 64 readings and average them.

[hmmpic]

@temtronic
I agree, and my problem is the "glitch".
I only read the sensor 1 time pr. 1 minutes. If that read is "ok" it is no problem. A read is just a real small sample maybe 1 us and if there are some spike or noise in that us it will give me a big error. Now the system have worked 2 month with no problem, until this moment. I have 1 bad reading (error reading, maybe noise or other things), and it is a problem.

@SherpaDoug
I will take a look at the "Olympic Average"

[temtronic]

If you properly bypass and filter all the VCC and ground lines, use a triple-Pi filter for the MCP9700 chip, shield the module in a ground Al box you'll eliminate 99.99999% of the glitches. It's all in the details of killing EMI before it gets you!
I've run LM34s, remotely outdoors for 5-8 years, in a solar collector POC setup. Each LM34 has it's own buffer opamp and triple Pi filter on the Vcc. Wiring is 'ugly' telephone cable (aka Quad) maybe 100-125' runs.
Sampling rate is 1 per second into a dedicated datalogger. I went back over 34 months of continuous readings and only found 3 'glitches', recorded during a bad electrical storm. Units are mounted on garage roof where 'noisey' arc welders live.

[hmmpic]

Thanks for information, I have now implemented what I mean is a "nice" solution for my needs.

I take 5 sample with 7ms between. Then I find the avg. and compare it with the last read. If there are more then 5 bit dif, which is about 2Deg.C there are something wrong, and I made 5 new samples.

It work well, because the temp. time constant is real slow.

[temtronic]

You might consider doing 8 readings as the average, since the compiler will do it real fast compared to averaging 5 readings. Get a better average, doesn't take that much time for the 3 more reads,...
just thinking out loud.

[Ttelmah]

Or (better), use six, or ten readings, and the Olympic method SherpaDoug has already mentioned.

Code as simple as: