I agree with PStechPaul that displaying the results after averaging, with more digits.
would be helpful in analyzing and understanding the noise present.
While + and - 1 digit is the theoretical limit of resolution for each single sample from a ADC conversion,
this isn't true for the averaged result.
The Averaged result will have better resolution than 1 LSB of the converter.
so displaying the result as Accumulator value divided by 20, is an excellent suggestion.
It may even be used in the user's calculation of final results.
This is actually the same technique that is used in high resolution 'Sigma/Delta' AD Converters
used in digital multimeters and other high resolution A/D converters, with 14 bit, 16 bit, 18 bit,
or even higher resolution.
For this to work, it is assumed that there is a little high frequency noise in the signal,
coresponding to about +/- 1 LSB of the AD converter,
and with a frequency higher than the sampling frequency of the ADC.
Some even apply dithering, that is adding a little high frequency noise to the signal to be measured.
However, neither Averaging nor Low Pass filter, in hardware or software, or high resolution ADC,
will help if there is Low frequency noise in the input signal,
that is if the noise have frequency lower than the period of averaging calculation.
In fact, in results displayed in message #7 and #12,
the variations come quite regularly:
47, 47, 48, 48, 49, 49, 49, 48, 47, 48, 48, 47, 47, 48, 49, 49
With one more decimal digit in printing of averaged values, as Paul suggest,
I suspect that it may be possible to plot a quite recognizable sine wave like curve.
I am not sure if the interval between printing values, is constant, or not.
What 'btbass' is suggesting in message #11 is another way of organizing calculation average value,
sometimes called a moving average or running average. See Wikipedia.
But it is average calculation anyway, with results similar to what the original poster is already doing.
Such a moving average is a way of organizing the calculation such that,
a updated average result value is available for each measurement value inserted.
It does however require a division to be performed for each measurement value added,
instead of one division at the end of a batch of measurements, as the OP. have been doing all the time.
The effort of doing divisions may be reduced, by using number of samples that is a power of 2.
e.g. 4 or 8 or 16 or 32 or 64 ... or 256 ... or 1024, ... , as suggested by pcbbc in message #4 above.
The compiler may, or may not recognice these numbers, and replace the division with shift operations.
Or it may be programmed with shift operator in the code.
Averaging with a number of samples = 256, may be made efficient by picking away a whole byte, instead of doing a long division.
It will however Not remove low frequency noise.
post edited by Mysil - 2019/12/09 06:49:54