New software filter for adc reading

[Jerson]

The average I have in mind would be average=average*15/16+sample. Not many, but not too little and /16 can be done fast with shifts.
Ioannis

Ioannis, I think you must have meant

Average = (Average*15 + sample)/16

[Ioannis]

Yes Jerson. That was it. It was too late here, so...

Thanks for correcting.

Ioannis

[aratti]

Darrel thank you for pointing out where the error was. So obvious that I could not see it!

I have an improvment (mark2) and I will be glad to post it, if you could test it under the same condition as for mark1.

I am asking that since you have suggested to create another thread for testing the various statistical manipolation of the raw data. So please let me know if you are going to create this thread or if I can post it here.

Thank you again for your work.

Cheers

Al.

[Darrel Taylor]

Sure, post it here. This thread is about your routines.

My stuff is at the office, so I'll run it and the moving average Monday (if I don't get snowed in).

I'm still thinking about starting the other thread, but it needs to use a bigger chip, have different noise types and frequencies, use pre-sampled datasets so they're each working with the same samples, maybe some software and circuits to automate the process, etc. .... it may be awhile.

[Charlie]

Ioannis, I think you must have meant

Average = (Average*15 + sample)/16

One of the issues with so many samples is that you may run into the maximum size of numbers. You may need to play with the order of operations or break it into several steps to make sure you don't accidentally wrap. You also likely will be dropping significant digits which may or may not be an issue.

[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