ADC resolution

[victorf]

There is an thread on the PICLIST discussing the PIC 10-bit ADC resolution. I have quoted here in thread order. Has the discussion any relavence to the ZX ADC capabilities?

An enlightenment will be appreciated

Vic

Someone was discussing ADC resolution some time ago...didnt pay much attention to it at the time of course but.....if I recall, the PIC internal 10 bit ADC really is good for only 8 bits, and other 12 bit ADC are really only good for 10 bits...to get a true 10 or 12 bit ADC its going to have to be an external device?


I'm using the A/D converter at the moment for a temperature sensor, and it accurately reads all 10 bits of the temperature (this is good, as it has a
10mV/K difference. This means at 5V each bit is about half a degree). Almost always the result is identical to the temperature in the room (as given by my thermostate). However, occasionally it starts to oscillate between the correct value and a value that is 10 degrees higher. I doubt this is caused by the lack of resolution, though: most likely it is a true oscillation in the voltage. As it only happens occasionally, it is rather hard to debug (it, of course, never happens when it is hooked up through the PICkit 2).


I remember seeing somewhere that to get the full resolution you need to have the PIC sleeping during the conversion. That way digital noise will not be a problem. Are you doing that?


hmmm...makes sense, but is this true? Right now I am just looking at a project spec to bid on, and trying to decide if a 16bit PIC will work or if I need to use external ADC and DACs


If you're meticulous about the environment the ADC has to work
in you can do better than 8 bits. Conversion in sleep, filtered
supply and reference, grounding etc. All good design practices

That hardly reduces the noise. The PIC's ADC is rather primitive (I think of it as a stretched 8 bit AD) and even if you sleep you'll still have noise. The only guaranteed way to get rid of it is to average 8-16 samples. Or if you require higher sampling rate use an external ADC with much lower noise. Analog Devices makes good ones.

[dkinzer]

Some of the points also apply to the AVR's A/D converter. As I read the Atmel datasheet, the ADC is capable of full 10-bit resolution. That said, the accuracy of the signal conversion is affected by local analog and digital noise. The Atmel datasheet describes several techniques to attain better results including avoiding signal transitions on other I/O lines on the analog port during the conversion or using sleep mode to "quiet" the environment during the conversion.

[DocJC]

Vic,
A few more thoughts on the AtoD subject to ponder.
I'll leave it to Don and others to discuss the "internal" noise of the AtoD on the ZX chips.

Keep your power supply very clean. This means large power supply caps, and bypass caps all over the board.

Think big picture about what you are measuring and your input sensor's intrinsic accuracy. An environmental thermostat, freezer alarm, temp/humidity display, etc. can sample slowly. Additionally, a few mS (or even seconds) delay in updating a value may make no difference to the end user.

Noise added to your signal will sometimes raise its value, sometimes lower its value. If you average several readings the noise will tend to sum towards zero average noise, leaving you with just your signal. For example, take 7 measurements, optionally eliminate the high and low values, and average the remaining 5 values to obtain your reading. For real time, higher speed sampling, this may exceed your hardware capabilities, (real time engine combustion modulation, high quality audio / video sampling, etc).

Look at your senor's accuracy! If your temp sensor, for example, is only accurate to +/- 1', then setting your AtoD input range to measure 1/100's of a degree doesn't make much sense, in terms of accuracy. How many decimal points do you need if the integer is off by 1.
Precision is the ability to measure small changes in your signal. You may be able to track 1/100's of a degree changes in your temp, even though the overall reading is off by several degrees. High precision may be useful, for example, for a model rocket altimeter. The absolute barometric pressure is of no real interest. The change in pressure, measured with high precision, is useful to calculate the altitude reached.

If your input sensor signal changes "slowly", then you can put an RC filter on it to limit its bandwidth. This prevents it from fluctuating rapidly with noise, which averages toward zero. Some sensors, for example some digital accelerometers, have a DtoA converter putting out the analog signal. The stairstep output signal needs the RC to smooth the signal (remove the high frequency components) so you can then feed it into your AtoD.

Just some of my thoughts on the subject.
JC

[Don_Kirby]

If you average several readings the noise will tend to sum towards zero average noise, leaving you with just your signal. For example, take 7 measurements, optionally eliminate the high and low values, and average the remaining 5 values to obtain your reading.

I'm using a very simple Kalman filter to smooth out fluctuations in my sensors' output. Basically it's a running average, where the newest AD value is given more weight than previous values. The advantage is in the simplicity. You need only know the current and previous values to come up with the average.

Code: Select all

Public Const SENSOR_INPUT as Byte = A.7 'ADC Input Pin
Public Const Vr as Single = 50.0 'The Dampening rate.  Higher numbers resond slower to changes
Public ADC_VALUE as Integer 'This is what the other tasks will see

Public Sub SensorTask()

	Dim Vn as Single 'The New Sensor Reading
	Dim Vi as Single 'Just a variable for the math below
	
	'Initialize the value so we don't have to ramp up to it at startup and remember what it is

	Vi = CSng(GetADC(SENSOR_INPUT))
	
	Do
		'Get the current AD Value
		Vn = CSng(GetADC(SENSOR_INPUT))
		'and Apply the damping value
		Vi = ((Vi*Vr)+Vn)/(Vr+1.0)
		ADC_VALUE = CInt(Vi)
	Loop

End Sub

-Don

[GTBecker]

Forgive me, Don, but that is not a Kalman. A Kalman filter is a _predictive_ device whose output leads - ahead of the real measurement, which is considered corrective feedback. Yours is a form of an integral that can not predict future measurements.


Tom

[Don_Kirby]

Of course you're correct Tom. I didn't mean to mislead, but was at a loss to put a name to the technique.

-Don