READINTERNALTEMP, AN1333 and beyond....

AllyCat

Senior Member
#1
Hi,

READINTERNALTEMP is a rarely-used command, probably because it's basically [contentious view] "useless" [/contentious view]. To qualify that slightly, it's useless unless you have a regulated power supply (which the vast majority of PICaxe projects don't have) and aren't interested in negative temperatures and/or an easy calibration procedure. Also, the related Microchip Application Note AN1333 is now quite old.

I've written several posts and code snippetts on the topic, which I won't go into detail here, but a brief summary is that a stable (or measured) supply voltage is absolutely essential to produce useful results. Also there was/is a bug in PE5 that produces erroneous results; the "fix" in PE6 increases code-size considerably, and still doesn't accommodate negatve (degrees C) temperatures, nor any better calibration strategy then "change K and see what happens". :(

Just a little more background: A "rule of thumb" is that the forward voltage of a silicon diode normally drops by about 2.0 mV per degree C rise in temperature (perhaps 1.75 at lower currents), but the Microchip PIC data sheet specifies only 1.32 mV/C. Furthermore, if you use the FVR as a reference voltage to measure the supply rail, then that itself has a temperature coefficient, which reduces the effective tempco to just 1.24 - 1.25 mV/degree C.

On that basis, I have produced some very satisfactory code (IMHO) which can measure "chiptemp" to within just a few degrees. Since I don't have an environmental test chamber ( :) ) my calibration method was to "stuff it in the freezer for an hour", which gives a useful temperature change (> 40 degrees) from room temperature (and I do have a freezer thermometer). But I still had niggling doubts about that -1.25 mV/C.

So now to the point of this thread. I was recently browsing Microchip's website and they now have a new AN2092: "Using the Temperature Indicator Module" (dated 2016). I had to smile at the comment on page 2 that:
"Generally this equation will produce an uncalibrated temperature value that is within 100°C of the actual temperature."
Well yes, so will "guessing" it to be +40 degrees :) , but the AN does contain much better detail than AN1333. However, on pages 4 and 6 there are two rather contradictory statements :

"The graphs show that the temperature response is very linear when verified at 10° intervals."

"The graph looks reasonable when first viewed but much of the measurement error is lost in the scale of the graph. A better option is to look as a scatter diagram of the error of the individual data points".
Here is one of those graphs:

TempModuleError2.png

So it appears that for my "freezer" test I need to include another correction factor of about 2 - 4 degrees! I won't be near my "hardware" for a few days, but maybe I'm finally close to getting "usable" temperature results from the PIC{axe} chips.

Cheers, Alan.
 

MFB

Senior Member
#2
Self heating errors

Attempts to measure ambient temperature will also be frustrated by the effects of self heating, and this will change with output loading. Although I looked at this effect some years ago, before internal temperature measurement was supported by the PICAXE, it was still possible to observe a significant internal RC oscillator shift with increasing output current. Unfortunately I no longer have these results but it would be interesting to repeat the test whilst monitoring the PICAXE internal temperature sensor.
 

newplumber

Senior Member
#3
Hi AllyCat
I love the comment you read from M page two ... I think its great you're trying to make internal chip temp better because I am thinking for like new beginners
they could have this coded in every program and it could be possible to stop short circuits in case one places a wire wrong to a pin to pin
with out a resistor and maybe the internal temp would alarm before the chip physically does .
Or maybe I am thinking the impossible but thanks again
Mark
 

AllyCat

Senior Member
#4
Hi,

Thanks for the replies. Sometimes self-heating will be (almost) negligible with a PICaxe; the current drain of the core at 4 MHz (lower frequencies are available) is around 600 uA, so less than 3 mW at up to 5 volts Vdd. All the packages are under 100 degrees/W to ambient, so there should be less than 1 degree rise. Obviously IF the output drivers are working "hard" then there will be more dissipation, but many of my applications use the pins as inputs for sensors, with only logic signal level outputs via SERTXD or SEROUT.

But conversely, perhaps you want to measure the temperature of the chip. Although the thermal conductivity may be available from the data sheet, some of the heat sinking of the packages (particularly SMD) is via the "pins" and PCB tracks, so potentially dependent on the PCB layout. Thus the chip temperature may be "unknown" even if the dissipation can be measured or calculated.

Another useful application can be some "header" code to attach to the start of every program (at least during development). A simple Vdd measurement (using CALIBADC or similar) sent via SERTXD is a useful confirmation that the supply is "good" (it also indicates if an "unexpected" reset has occured) and adding the chip temperature could give more detail. For example a higher than expected temperature might indicate if a sudden "overload" had caused the supply to collapse and cause a Reset.

I rather doubt if the PICaxe can be fully "protected" from destruction by overheating, because the temperature detection subroutine would need to be called frequently and reliably (like a "watchdog"). But if a "chiptemp" routine is available and the main loop time is not too critical, then why not give it a whirl. ;)

Cheers, Alan.
 

premelec

Senior Member
#5
Symbol toohigh = 100 ; empirical determined value when chip IS hot
IF chiptemp > toohigh THEN
GOTO alloff
ENDIF

alloff:
LOW everything
GOSUB flash_OT_LED
GOSUB siren_noise
GOTO alloff

;-0
 

newplumber

Senior Member
#6
@ AllyCat that is why I think its great that YOU are working on it because I understand (patting my back) maybe 40% percent what you wrote....In a few years I might
be closer to your level :)

@premelec yes i was thinking something like that too except mine would do the same with 30 more lines of code and all the labels used up
 

AllyCat

Senior Member
#7
Hi,

IF chiptemp > toohigh THEN
GOTO alloff
ENDIF
Actually that can be a "one-liner"; IF chiptemp > toohigh THEN alloff ;)

But a little more is needed, something like:

Code:
init:
   CALL readchiptemp
   < report/set threshold temperatures, assuming chip is near to room temperature >
main:
DO
    CALL readchiptemp
    IF chiptemp > toohigh THEN alloff
    < do something useful >  ; But don't take too long :-) 
LOOP
alloff:
DO WHILE chiptemp > safetemp
   < everything = INPUT >
   < give a warning >
   CALL readchiptemp
LOOP
Unfortunately the readchiptemp subroutine is not trivial because of the readinternaltemp bugs in PE5 (for which I still try to write compatible code) and the "bloated" version of readinternaltemp in PE6. :(

However, I have posted a moderately compact version in #2 of this code snippett. ;)

Cheers, Alan.
 
Top