New software filter for adc reading

[aratti]

Hi Darrel here the version 2. In this version, I am using the mean instead of single data and then I select the median. Let see how it perform.

Charlie:

With a 12 bits ADC there is the possibility of overflow, with a 10 bits ADC you are ways within the word size, even if you sample 1023 which is the maximum value.

Cheers

Al.

[Darrel Taylor]

Sorry for the delay, I was getting unexpected results from the moving average and I wanted to make sure it wasn't something I was doing wrong.
But I 'll get to that in a minute.

Al, here's the results of "Mark2" under the same conditions as before.
I haven't changed the voltage calculation for it, so it's still reading higher than normal.
It looks a little different, but still jumps +/- 2 counts fairly frequently.



Now notice the green line in the above plot.
What, you don't see it ... me neither.
It turns out that the Running average is so slow to respond that it's reading is not even on the chart.
Zooming out a bit shows this ...



This was the formula used ...

RunAverage  VAR WORD

ADCIN  0, ADval
RunAverage = (RunAverage*15 + ADval)/16

I let it run for over an hour and it was getting close, but it still hadn't reached 2.5 volts.
I don't think I'd want to use that formula.

[Ioannis]

Thanks Darrel. Is that on the X-axis ... time? I guess it is and the time it takes is forever.

OK, if we use 3/4 will sure be faster, but how accurate?

On an experiment with touch sensors I can confirm that it could not get close to the real sample value though...

Ioannis

[Charlie]

Hey Darrel - I'm sure you don't want to make a career out of this mini-project, but can you explain that result? It's not obvious (to me at least) why it takes so long and the green line never reaches ADval. Playing with this in a spreadsheet, it can take between 100 & 150 samples to get there, but you have WAY more than that, and it's not even close! Do you think this the accumulated result of dropping LSBs, and effectively always rounding down?

Also, to address the ramp time, when I've done something similar in practice, the first time through the loop I make RunAverage = ADval to effectively eliminate the ramp, and at least start in the right ballpark. (I'm sure you typically do as well). Wouldn't it be more fair to add that curve instead (or as well)?

[Ioannis]

I think with the running average will never reach the final ADC value because of rounding errors.

E.g. for 10 bit ADC and say a RunAverage value of 1008, on next iteration 0.9375 should be added, but since PBP does only integer numbers, the RunAverage will sit at 1008 for ever. This would be the final value of the filter.

I suppose this kind of running average routine is for floating point maths only.

Ioannis

[aratti]

Thank you Darrel for such a quick answer. I will keep thinking what else I could do for further improvment.

As far as the running average is concerned, a way to have a faster answer could be:

ADCIN chan,ADVal

If RAv = 0 then
RAv = ADVal
ELSE
RAv = (RAv*15 + ADVal)/16
ENDIF

In this way you load the variable with the raw value and then you smooth it. Just thinking!

Cheers

Al.

[Jerson]

Another running average that may be useful to all. This one will work even if you do not have floating point. However, you need to be able to handle large numbers or size the buffer appropriately that it doesn't overflow 'sum' while summing. Of course, you need way more ram than the Avg = (Avg*(n-1)+adcval)/n formula which is good for Ram Constrained systems.

Pseudo code.

NumOfSamples   equ   16

AdcVal             Word                               ' adc reading is placed here
Samples           Word [NumOfSamples]     ' rolling buffer having NumOfSamples of AdcReading (must retain value between calls to R_Average)
Index              var     byte                       ' next position where the sample will be put (must retain value between calls to R_Average)
Sum                var     long                      ' gross sum of all the samples (must retain value between calls to R_Average)

RA_Init:  ' initialize the running average
      Index = 0
      Sum  =0
      return

' enter with A
R_Average:
     sum = sum - Samples[Index]                    ' remove the oldest sample from the sum
     sum = sum + AdcVal                                ' add in the latest sample             to sum
     Samples[Index] = AdcVal                          ' and save it in the buffer too

     Index = Index+1                                     ' move the index
     If Index > NumOfSamples then Index = 0  ' wrap around if needed

     return sum / NumOfSamples                     ' the running average

Caller has to initiate with RA_Init before using the R_Average routine. I hope you will excuse my pseudo code since I am a bit rusty on my PBP at this moment.

[Darrel Taylor]

I agree!
That Avg = (Avg*15 + ADval)/16 running average is only going to work with floating point math.
It's surprising how many times we've seen it used around here in an integer only language.

Charlie, I don't think setting it to ADval first will help, because it is likely to still be a short distance from the real value.
And it's when it's close to the real value that it doesn't move anymore, so it would never get any closer than that first reading.

[Ioannis]

Ehh, hmm, I think it is Al, Darrel

It is indeed surprising how many have used it, but who thought that it needed floating? Also Microchip use it in various AN like the cap-sense routines but of course C does support floats.

Anyway, Fast Average and Oversampling I think is the best Darrel-Soft as usual.

Ioannis

[Charlie]

And it's when it's close to the real value then it doesn't move anymore.

Well, that's sort of the objective of filtering, right?

But I think I'm getting my head around this - it's an issue of the SIZE of change needed to make an impact on the reading. So if there is no averaging, a change is recorded when the reading changes by a whole number value of 1. If you are averaging 4 readings, then the change must be at least a whole number value of 4 before it gets included. With 16 samples, the reading has to change by at least 16 before it registers, and so on. In effect you are not integrating small changes, you are tossing them out... which is sort of where this thread started.

I think I'd better revisit several projects where I've used a rolling average, although I don't believe I've ever used more than 4 samples.