CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Best way to read AD result.

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
hmmpic



Joined: 09 Mar 2010
Posts: 314
Location: Denmark

View user's profile Send private message

Best way to read AD result.
PostPosted: Tue Mar 15, 2011 12:48 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Mar 15, 2011 1:16 pm     Reply with quote

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



Joined: 09 Mar 2010
Posts: 314
Location: Denmark

View user's profile Send private message

PostPosted: Tue Mar 15, 2011 1:41 pm     Reply with quote

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



Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA

View user's profile Send private message

PostPosted: Tue Mar 15, 2011 1:55 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Mar 15, 2011 3:14 pm     Reply with quote

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



Joined: 09 Mar 2010
Posts: 314
Location: Denmark

View user's profile Send private message

PostPosted: Tue Mar 15, 2011 3:33 pm     Reply with quote

@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



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Mar 16, 2011 3:31 pm     Reply with quote

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



Joined: 09 Mar 2010
Posts: 314
Location: Denmark

View user's profile Send private message

PostPosted: Thu Mar 17, 2011 3:21 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Mar 17, 2011 4:28 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19553

View user's profile Send private message

PostPosted: Fri Mar 18, 2011 3:23 am     Reply with quote

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

Code as simple as:
Code:

int16 olympic_ten(void) {
    int16 imax=0;
    int16 imin=1023;
    int16 isum=0;
    int16 itemp;
    int8 ctr;

    for (ctr=0;ctr<10;ctr++) {
        itemp=read_adc();
        if (itemp<imin) imin=itemp;
        if (itemp>imax) imax=itemp;
        isum+=itemp;
        delay_us(250);
    }
    //Now have the sum of ten reading, and the max/min readings
    isum-=imin;
    isum-=imax; //subtract the min and max from the sum

    itemp=isum/8; //compiler will automatically optimise this to a shift
    return itemp;
}

This gives the average of the _eight_ 'least extreme' readings from ten. Uses quick maths (integer addition and subtraction together with integer /8), so is quick, and is ideal for dealing with 'spike' noise, together with Gaussian noise.

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group