READINTERNALTEMP, AN1333 and beyond....

AllyCat

Senior Member
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 than "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.

EDIT: See update in Post # 8.

Cheers, Alan.
 
Last edited:

MFB

Senior Member
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
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
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
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
@ 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
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.
 

AllyCat

Senior Member
Hi,
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.
When I "discovered" AN2092, I guess I was on holiday or busy with another project; so three years on, and I realise that I haven't actually followed up the above comment from post #1. I won't repeat all the detail from that post, but the subsequent replies are "branches" from the main topic, so may be skipped back to here. To summarise: the crucial requirement for any electronic thermometer is an accurate "Temperature Coefficient", i.e. the conversion factor from (e.g.) the change in millivolts from a sensor, caused by the corresponding change in its temperature. The PIC{axe} chips use silicon diodes, which are normally assumed to have a Temp.Co. of about -2mV/degC each. But if one performs a "two-point" calibration on a "real" PICaxe, taking into account the configuration shown in the Microchip data sheet, then the Temp.Co. (for each diode) appears to be hardly more than -1 mV/degC. That's rather disconcerting when we need better than +/- 2% accuracy for a reasonable (+/-1 degree) temperature indication.

The original Microchip Application Note (AN1333) specified the Temp.Co. as 1.32 mV/C, which is "surprising" (low) but at least gets us closer to the measured results, and making an allowance for the tempco of the supply rail (~ -0.065 mV/C) brought it down to about 1.25 mV/C. Thus, the additional graphs and data in AN2092 looked "promising" for getting towards some "usable" results, but then I only "skimmed" the complete Application Note.

Looking again now, I see that the non-linear Error graph is "concave downwards", so the correction should be concave upwards (although the actual degree of curvature is not great). For the range of about -25 to +25 degrees, this would decrease the gradient of the temperature curve by a few degrees, which we were seeking to increase. Furthermore, the new AN suggests the Temp.Co. is around -1.37 to -1.38 mV/C (not -1.32) , again taking us further from our target. :(

Therefore, (and the main point of this post is), I looked again at the tempco of the supply rail and realised that the Temperature Coefficient of the FVR in the data sheet (-130ppm/C) needs to be multiplied by the supply voltage. So at 5 volts, the tempco would be -0.65 mV/C, which shared across the two diodes reduces their effective value from -1.375 mV/C to just 1.05 mV/C, slightly overshooting my "target". But I normally use a supply rail of 3 - 4.5 volts, and didn't take into account the curvature of the error line (which together would take the calibration closer to -1.10 to -1.15 mV/C), so it looks as if I can finally account for the observed temperature characteristics. ;)

I've never been a great user of "78{L}05" and similar voltage regulators, so had assumed that most of the above calibration issues might "disappear" if I used a regulated supply. Therefore, I Googled a number of 78{L}05 data sheets from various manufactuers: some don't even mention the tempco or use a vague term such as "drift", but the first I found with a clear parameter quoted -0.65 mV/C, or exactly the same as presumed for the PICaxe FVR! I didn't see any lower values, but others of -0.8, -1.0 and up to -1.3 mV/C. Therefore, the use of the PICaxe FVR appears to be as accurate as a typical external regulator, with the great advantage that it is (thermally) directly linked to the sensing diodes. With an external regulator we may have little idea of the actual temperature of its chip; it may have a better thermal coupling to the "ambient" temperature, but it might be dissipating an enormously higher amount of power, depending on the application.

However, none of the regulator data sheets indicates a range for the tempco (only a "typical" value) and there are some more "strange" or vague comments in AN2092 (particularly concerning their "6-Sigma" values), so I may return to this thread in due course. But obviously the next task is to update my Code Snippet algorithm with the above parameters, which I'll try to do rather sooner than in three years. :)

Cheers, Alan.
 

AllyCat

Senior Member
Hi,

Well, I've updated two versions of my code snippet linked above (with another to come) to take into account some of the details from AN2029 (and some feedback in other threads). In particular, I've added code to compensate for the non-linear "error" in the temperature coefficient, shown in the graph from the AN posted above. Initially, I considered a "piecewise linear" solution, i.e. increasing the gradient of the line by say 10% outside of the reasonably straight "middle" section (i.e. between about 10 degrees and 80 degrees), perhaps combining the lower "break" with the code that handles the display of negative numbers. But a simple mathematical expression proved more efficient, actually fitting into a single program line, which has an advantage that no other variables need to be declared or used. The basic method might be of interest because it involves the kind of mathematics that some may consider to be "not possible" with a PICaxe. ;)

The "error" curve, cut and pasted in #1 above from Figure 16 of the AN, gives the equation for "Sample 5" as : y = -0.0008 x2 + 0.0678 x - 1.2845 , but the graphs and numerical values for the other 4 samples look somewhat different. However, the right-hand Constant (1.2845) represents only just over one degree of offset, which will be corrected anyway by the essential single-point calibration. That it is quoted to 0.0001 C resolution is hopefully just a characteristic of the curve-fitting software used by Microchip. Similarly, the coefficient of x (i.e. 0.0678) relates to the "tilt" of the error curve which should be corrected by a two-point calibration. It is the coefficient of x2 which is particularly significant because (although apparently a small value) it is multiplied by a reasonably large number (the square of the temperature) to give an offset of up to 5 degrees C at the temperature extremes. Fortunately, the spread in that coefficient is relatively small (0.0007 to 0.0008) so we can take an average of 0.00075. Overall, "Sample 5" looks to be the best "average" of the five graphs/equations, which is why I chose to show that one. ;)

The first point of note with the equation is that it represents the "Error" in the calculated value, so to compensate for that error we must take its negative value (by changing all the signs) to give: Temperature correction, y = 0.00075 x2 - 0.0678 x + 1.2845 . There are three potential "obstacles" to calculating that with a PICaxe: The first is the very small (decimal) numbers which would just truncate (or round) to zero; a solution is to scale them up (multiply) by a larger constant (often 100 or 1000), but care will be needed to avoid the opposite problem, of overflowing the maximum 16-bit word value. Another problem is that PICaxe doesn't "support" negative numbers and the first two terms will generate a negative value if x is small. But the "two's complement" number notation, which handles negative numbers, is "compatible" with binary addition, subtraction and (some) multiplication (not division), so some intermediate negative numbers can be handled. Therefore, it is mainly necessary to ensure a final positive result, or to use / report the two's-complement value correctly.

The third problem is PICaxe's strict left-to-right sequence of operations, but the coefficient of x (0.0678) must be multiplied before it can be subtracted from the number on its left side. Of course the coefficient could be multiplied first and this intermediate result stored in another variable, but a neater solution is to make the coefficient "disappear". This can be done by multiplying all the coefficients by the same number, i.e. 1 / 0.0678 (=14.75), to make the coefficient of x equal to 1 . This has a further advantage by increasing all the coefficients to be more compatible with integer arithmetic. Thus the equation becomes: 14.75 y = 0.0111 x2 - x + 18.95 , or in typical PICaxe notation: w1 = w1 * w1 * 0.0111 - w1 + 18.95 / 14.75 . The * 0.0111 can be handled by converting it to * 1 / 90 , but I prefer to use the ** multiplication operator which (also) divides by 65536 , so * 0.0111 becomes ** 727 . Since all the values were only "ball park" estimates, they can be rounded to more convenient numbers and the final constant increased (optionally) a little to avoid a negative result ever occurring. Finally, as the basic formula calculates a compensation factor (i.e. the inverse of the error), add in the number that we started with (still in w1), to give the "One Liner" : w1 = w1 * w1 ** 727 - w1 + 20 / 15 + w1

Here's a simple "sanity check" that can be run in the simulator to show that it works:
Code:
for b0 = 0 to 170 step 10
    w1 = b0 - 40                                ; Input temperature (two's complement)
    if w1 > 32768 then                          ; It's a Negative value
        b1 = -w1 : sertxd("-",#b1,"C")          ; Report the temperature
    else : sertxd(#w1,"C") : endif
    w1 =  w1 * w1 ** 727 - w1 + 23              ; Adjusted for zero output at centre
    sertxd(" --> ",#w1," / 15",cr,lf)           ; Output compensation (shown * 15)
next
___________

Another Figure of interest in AN2092 is the "6 Sigma" graphs of the temperature-sensing diodes' forward voltage drop against temperature, which I've pasted below, with added sample data from AN1333. However, the term "6-Sigma" is not really defined; the limits often apply to exclude very "rare" devices / events (in the region of 1 in a million) but sometimes it is applied to devices outside a band of +/- 3 Sigma which are not particularly rare, perhaps 1 in 100. The limit lines do largely confirm the statement that I quoted at the start of this thread that: "Generally this equation will produce an uncalibrated temperature value that is within 100°C of the actual temperature.". But later there is the comment that:
"The linear equations shown in Figure 6 and Figure 7 suggest a slight difference in TC between the two parts with Sample 1 having a TC of -1.37 mV and Sample 2 having a TC of -1.38 mV. This illustrates the necessity to test parts from different production lots to get the best average value for TC."

The 6 Sigma graphs are useful to determine the minimum supply rail range at which the "4 diodes" sensor can be used. Strictly, the lowest Vdd is about 3.6 volts, although in practice it may be possible to use a 3.3 volts rail or less, particularly if very low temperatures are not going to be encountered. It appears to be almost impossible to use the FVR2048 with 4 diodes sensor, and the minimum supply rail with FVR4096 is about 4.4 volts.

AN2092-3TempD6sig+.png

An interesting feature of the Figure is that the gradient of the lines (i.e. the temperature coefficient) with higher diode voltages is significantly less than with the lower diode voltages (and vice-versa). If that were a "genuine" characteristic, then it could help to predict the temperature coefficient without so much need for "two-point calibration". However, I've not seen such a feature described elsewhere and I suspect it may be an artifact of the data used to prepare the graph, rather than being a useful characteristic. Certainly the added data from AN1333 appears to break the rule.

Cheers, Alan.
 
Top