New software filter for adc reading

[Ioannis]

Excellent analysis Darrel!

It would be interesting (at least to me) on your same setup to test the moving or running average too.

Also, how did you collect the samples? From Excel side I mean. By text file?

Ioannis

[aratti]

Thank you Darrel for your interesting post.
I need to correct your statement, that the routine takes only 14 samples instead of 15. I have re-checked and found no error. From raw data 0 to raw data 14 makes a total of 15 samples! If I am in error please let me know where the mistake is, since the true MEDIAN can be taken only from an odd number of samples.

In your test you have injected audio signal into a DC line, well this is rather different from a non cyclic random noise that you can see in harsh environment.

Performing DC reading, I hate to see the decimal part of the display behaving like a dancer, hence, I consider the MEDIAN approach interesting, since it make the reading rock stable.

Let see other reports, you will be counted as against. Thank you again for your preciuos contribution.

Cheers.

Al.

[aratti]

Adding part to my previous post.

Ok found the error the sorting part of the routine was stating:

If Index < Sample then goto SDH_Loop

Now since Sample = 14 then the statement should be:

If Index < (Sample + 1) then goto SDH_Loop

in order to sort the whole series of data.

Thank you Darrel for pointing it out

Cheers

Al.

[Darrel Taylor]

Well no.

The sorting routine was OK.
It needs that statement because the sorting uses Raw_Data[Index + 1]
If you make your suggested change, it will overrun the array.

The problem is in the sampling portion.

If Index < sample then goto Read_Again

Should be ...

If Index <= sample then goto Read_Again
____________________ _______________________ ____________________

Ioannis: Thanks!

If you have a particular running average routine (I've seen several), I can throw it in the test.

And the data was formatted like this ... using a total of 300 samples

Ready
2.502, 2.534, 2.497, 2.497, 2.500
2.507, 2.529, 2.497, 2.497, 2.500
2.487, 2.529, 2.492, 2.497, 2.500
2.502, 2.534, 2.502, 2.502, 2.500
2.502, 2.534, 2.502, 2.502, 2.500
2.507, 2.529, 2.492, 2.492, 2.500
2.517, 2.529, 2.497, 2.497, 2.500
2.492, 2.529, 2.497, 2.497, 2.500
2.492, 2.534, 2.502, 2.502, 2.500
2.507, 2.534, 2.502, 2.502, 2.500
2.517, 2.529, 2.497, 2.497, 2.500
2.497, 2.529, 2.492, 2.497, 2.500
2.502, 2.529, 2.497, 2.497, 2.500
2.512, 2.534, 2.497, 2.497, 2.500
2.497, 2.534, 2.502, 2.502, 2.500

The order is ... Raw, Median, Melanie, Average, Oversample.

I cut&paste the data from the terminal program into Excel and used the "Text to Columns" command.

We could create another thread and test out various averaging routines.
Figure out the best sample size and measurement techniques. But I doubt anything could ever be better than Oversampling.

[Ioannis]

Hi Darrel.I too agree that nothing may beat the oversampling. It is obvious.

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.

Cut and paste? Well, I was thinking too complex I guess...

Ioannis

[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

[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.