PDA

View Full Version : A/D conversion problem with pic16F88



Tapio Linkosalo
- 28th July 2006, 12:17
I'm trying to get temperature readings from a thermocouple, using INA128 op.amp. connected to pic16f88. The problem is that although I get readings that seem to be valid, every now and then (10 to 20% of the reading, with irregular intervals) are erratic. The erronous readings are always smaller than the correct ones, typically about 1/4 of the real values (i.e. if I should get values around 400, I get every now and then values of about 100). The op.amp. is connected to the porta.2 pin.

My configuration is like this:


OPTION_REG.7 = 0 'enable portb pullups
TRISA = %00000100 'set porta pin 2 as inputs
TRISB = %01110011 'set portb pins 2,3,7 as output
OSCCON =%01101100 'set internal osc at 4 mhz w/freq stable
OSCTUNE = 0 'internal osc. running at factory calibration
CMCON = 7 'comparators off
ANSEL = 4 'porta.2 AD-input, others digital
ADCON0 = %01010000
ADCON1 = %10000000
PIE1 = 0 'disable all interrupts
INTCON = 0 ' -"-


And the code that reads A/D looks like this:



readAD: 'Do the AD-conversion
adcon0.0 = 1 'turn on AD-converter
pauseus 20
ADCON0.2 = 1 'Start AD-conversion
notdone:
if ADCON0.2 = 1 then notdone 'wait for low on bit-2 of ADCON0,
' = conversion finished
ADresult.highbyte = ADRESH 'move HIGH byte of result to ADresult
ADresult.lowbyte = ADRESL 'move LOW byte of result to ADresult
return


Is there something wrong in my configuration/code? Thanks!

Acetronics2
- 28th July 2006, 12:43
Hi, Tapio

Did you verify the minimum acquisition time, ( 16F88 Datasheet p. 219 ... looks you did !!! ), line impedance between INA out and ADC in, and ref voltage ( or 5v supply ) stability ???

Hope also there's no relay nor "heavy load" driven from the Pic supply ...

Note Thermocouple and INA inputs shielding also have to be really care-treated not to be a spike-antenna.

Need a portion of scheme for further analysis ...

As first trail, try 50 or 100 µS as an acquisition time ... and try to scope the INA output for glitches.
Second trail : a Very-low pass filter between INA and ADC

Third trail : a softw. non-linear-change value rejection !!!

Alain

dhouston
- 28th July 2006, 14:45
OSCCON =%01101100 'set internal osc at 4 mhz w/freq stable
I don't think you SET the frequency stable bit; you loop until the MCU sets it.

OSCCON =%01101000
While OSCCON.2=0:Wend

Tapio Linkosalo
- 29th July 2006, 07:33
There are some heavy loads involved. The circuitry is a thermostat, that sets heating power of a resistor by cutting power on and off via a N-fet. The fet, however, is connected directly to 12V input, while the PIC is powered with a 78L05 regulator. I guess I need to scope the power to the PIC to be sure.

I tried to chech the output from the INA with a data logger. Did not see any ripple there, however the logger had acquisition time of 1ms, so I suppose I'm better off scoping that part, too.

Software measurement rejection is indeed one option, I just wanted to make sure that there is no error in the A/D configuration before taking that route. Thanks for your comments!

Tapio Linkosalo
- 31st July 2006, 10:25
Ok, tried increasing the acquisition time up to 1000us - no help. Then checked the voltage with PC-scope. Input voltage to PIC is stable (also used as Vref), and the ripple on the output from op.amp. is just a few percent, nothing like the error readings in the AD. Still looks like there is a configuration problem in my software?

Acetronics2
- 31st July 2006, 13:19
Hi,Tapio

Could also come from an unwanted 10 to 8 Bits truncature ( indexed EEPROM transfer bug i.e. )... I do not see why, but it is possible ... so, to be checked !!! .

Alain.

paul borgmeier
- 31st July 2006, 15:20
Tapio,

Another thing to try ....

Remove the thermocouple input from RA2 and replace it with a known voltage input (from a voltage divider or pot). With this, you should be able to determine if the problem is from the software side or the hardware side. Just a thought ...

Tapio Linkosalo
- 1st August 2006, 05:43
Alain,

truncation is a possibility that came also to my mind. I tried adding "define adcbits 10" to the software yesterday, at that time it started to work, but it could be also that re-soldering one lead of the thermocouple at the same time was the real reason. I tried to remove the define, even erase the chip and reprogram in case that the define did a change in the configuration that was not reversable by removing it, but could not return to the erraneous state of affairs.

I wonder if the reason could be in the input. I checked the output from the op. amp. with oscilloscope, and it seems to be stable within around 5%, nothing like 4-fold variation in the input values.

Acetronics2
- 1st August 2006, 07:40
Hi, Tapio

Glad to hear it works ...

As the Define Adcbits deal with adcin ... I'd bet the thermocouple was the trustable reason ...

Alain

Tapio Linkosalo
- 18th August 2006, 11:42
Actually, it did not work, but now I think it does.

The problem was not in the A/D configuration, but the op-amp. The datasheets tell to add a resistor for bias current return path which I had not added (and also had to tinkle around as ref ground and opamp power ground must be different). So the erronous readings were due to thermocouple drifting towards V+ref end of the input.