Averaging AtoD samples

[HankMcSpank]

So I have a need to average out some AtoD samples & a bit of googling found this (DT's averaging routine)...

http://74.125.77.132/search?q=cache:...&ct=clnk&gl=uk

(Btw, yes I did use the search bt I've just climbed down off the chair having tried to catch all the info going over my head!)

Now that looks link above looks like it might be ideal (perhaps a hammer to crack a nut in my situation), except I don't have a clue how to integrate it into my code! (I'm still massively wet behind the ears & really don't know how I've managed to kludge what I've already got together!)

In a pretty crude manner, up until now I've been averaging by storing the AtoD values in a few variables - then adding them together & then dividing by the number of variables I've used. I removed it from my code because it wasn't very elegant, my (simple) code was getting bloated etc.

Could someone be so kind as to outline how I can elegantly/simply average say 16 samples on a rolling basis?

For any responses, can we sssume my A to D sample is stored in a variable called signal_in

[Darrel Taylor]

If I had a hammer ... I'd hammer in the morning ... Whaaap!
You sure you want that around you nuts?
I like pistachio's, they're cracked already.

So take the code from that page and save it to a file called "average.pbp".

Add a line in your program ...
INCLUDE "average.pbp"

When you get your reading that you want to average ... put it in the variable Value, then GOSUB Average.
The running average will be returned in the same variable (Value).

Now sit back down in your chair before you hurt yourself.
<br>

[HankMcSpank]

Hi Darrel,

Thanks!! (that all sounds too simple...even for someone as clueless as me)

I'll try that soonest ...but I'll be sure to keep the chair nearby to get right back up upon!

(PS I wasn't saying your routine was a hammer to crack a nut per se, but simply a hammer to crack a nut with my simple requirements!)

PPS why do I keep getting that Random Question "missing letter from the word cof_ee" wrong? It's an 'f' damnit.

[HankMcSpank]

This is somewhat related to my ongoing pitch detection quest (in that it's what's driven me to ask - I'm seeing occasional glitches in the input signal, which is causing a hiccup in the 'time measured between comparator interrupts, oncde in a while), but it could relate to any situation...not just pitch detection, so hence coming back to this thread.

My question relates to 'intelligent' averaging (& rejecting spurious values)

Let's say you have a series of data (counts, samples, pulses....whatever) , but within the data occurs the odd 'sample' that's way out of whack. For example.....

2, 2, 2, 3,2,2,3,2,2,2,8,2,2,2,3,3,2

What I'd like to do is average all those samples, but reject any one occurence that's way out of whack (eg if 1 sample per 16 is out of whack, ignore it). so in that example all the 2s & 3s get averaged, but the 8 is ignored....else it'll really dick the average!

Ok, if it were that simple I could probably kludge something together - BUT, lets say that the above series of data is then immediately followed on by by say...

10, 10, 11, 10, 11, 10, 10, 11, 10

therefore giving a stream of values like thus.... 2, 2, 2, 3,2,2,3,2,2,2,8,2,2,2,3,3,2,10, 10, 11, 10, 11, 10, 10, 11, 10

There clearly becomes a problem, because the first couple of 10s of the second series would appear out of whack to any 'moving' simple check that was applied to the first series.

Ideally, I'd like to put in place some form of intelligent averaging routine, where only samples that are close together (say percentage terms) are averaged, any spurious samples out of that range (say 1 in 8 samples) are rejected ..... but if a threshold is breached, then the spurious values aren't treated as spurious anymore, but as new valid data to be then averaged.

Clear as mud?

[mackrackit]

I can not think of a "fast" way of doing it but you could check the difference between each pair and if the difference is more than X toss the value...
maybe...

[HankMcSpank]

I can not think of a "fast" way of doing it but you could check the difference between each pair and if the difference is more than X toss the value...
maybe...

but in that example above, it would mean when the series 10s & 11s arrived, there'd be a problem? If comparing in pairs & throwing the second one a way (ie if it deiviates too much), then the 10s would get rejected cos they're way out of whack wrt to the previous series of 2 & 3s (or have I misunderstood your line of thinking)

[ScaleRobotics]

Sounds like you could use this:

http://www.picbasic.co.uk/forum/cont...orting-Numbers

[ScaleRobotics]

Hey Hank,

You could try Melanie's number sorting routine. She talks about dumping the upper 4 and bottom 4 numbers. You could do something similar. http://www.picbasic.co.uk/forum/cont...orting-Numbers Something like Aratti's example: http://www.picbasic.co.uk/forum/show...1327#post91327

Or, you could use Darrel's oversampling routine. It is not weighted, but still interesting. It worked very nicely for getting 16 bit results from an altimeter sensor on a 10 bit A/D pic. http://www.darreltaylor.com/DT_Analog/

[HankMcSpank]

Hey Hank,

You could try Melanie's number sorting routine. She talks about dumping the upper 4 and bottom 4 numbers. You could do something similar. http://www.picbasic.co.uk/forum/cont...orting-Numbers Something like

Thanks (as ever) for the input - re Melanie's number sorting code......that's what I was doing in post #14 above - it works, but this weighted average has got me curious now!

Whichever averaging/sorting method I eventually use will ultimately go into a frequency detect PIC circuit - I use the PIC's onboard comparators...but the sample 'counts' are a little bit erratic ....eg for Kkhz I get a stream of 'counts' in or around 5000 (which is correct for the clock speed)...but then every 10-12 or so readings, in comes a sample that way out of whack - so it's a case of which method to go with to best eliminate that gracefully!