ATTiny13a tempurature monitoring without additional components.

Flashlight Modding and DIY Parts
1

For the last few days I’ve been testing a few distinct characteristics of ATTiny13a that could possibly be used for a crude method of temperature threshold monitoring without any additional components. Of interest is page 155 (bottom graph) and 157 (also bottom graph) of the ATTiny13a datasheet:

Yesterday I put together a Convoy S2 with a QLite driver for ~4.4A and flashed it with some code I wrote that exploits these characteristics and took it out for a walk. It appears to work, better than I had expected. I put the threshold rather low, and when the light got warm it switched to a lower output, and when it cooled down it switched back to the highest output. The S2’s small pill (with no themal paste between pill and host) heats up pretty fast so I didn’t have to wait long. Without an IR thermometer I can’t say how accurate it is, but heat up and cooling times where rather consistent throughout our one hour walk.

So far so good, but it’s not that simple because the VCC voltage level has an impact on the result. By looking at the charts it seems that there could be a temperature difference of ~20C when the same threshold value is met, depending on if the input voltage level is 2.7V or 4.0V. This could be resolved with a zener diode, but for existing QLite boards you would loose the voltage monitoring… So maybe I’ll have a go at implementing different threshold values depending on what is read from the voltage check routine. I’d need an IR thermometer to do that.

Also, different light designs will mean the MCU is heated differently. The MCU in the S2’s small pill will heat up much faster than in for example the Supfire M6. If the same levels where used I’d guess that the M6 would run hotter before the threshold is met in the MCU.

Has anybody been down this path before?

2

Interesting project, never seen or thought of such things…

3

I can explain a little further what I’ve done…

The interesting characteristics I’ve based my code on are that when MCU heats up, two things of interest happen: The main RC oscillator runs faster, and the watchdog oscillator runs slower.

In extremely simplified terms with pseudo figures:
Lets say for example that at 20C the watchdog timer interval will take one second, and the main “CPU” interval will take 0.01 seconds (100 times per second). That means that for every watchdog cycle, the main CPU has run 100 cycles. If the temperature goes up, the watchdog cycle goes slower, so it will take for example 1.1 seconds for every cycle. If the main CPU cycle speed was not affected, it would run 110 times per watchdog cycle. But it is affected, it runs faster, so it might run at for example 105 timers per second. As a watchdog cycle now takes 1.1 seconds the main CPU will run 115 times per watchdog cycle. So I know that if the main cycle count is 115, the temperature is higher.

What I’ve done in the code is that I have a volatile integer that I alternately set and clear each time the watchdog interrupt code runs. When this volatile integer is set the main routine does a simple loop iValue which stops when the next watchdog cycle clears it. As the temperature goes up, the value of iValue after the loop increases.

As mentioned, I’ve played around with it in a light and it does seem to work. I’ll be getting a cheap IR thermometer to see how accurate it can be, but at initial tests it looks like it actually can be used for temperature monitoring…
But I haven’t read anything about here… hence my question if anyone has done any testing on this before.

4

Since I joined BLF I don’t recall seeing anyone else try temp calculation using the frequency shift of watchdog vs main RC.
Very nice.

5

I’ve only skimmed the thread because I need to leave the house, but it sounds like you’re putting in good work Mike C.

This technique has been published a couple of places I think, but I never looked closely. I think I just assumed that I’d find it was inappropriate for some reason. It sounds like you are finding otherwise!! It sounds like you came up with the idea independently, good job.

(arekmn mentioned those links over here, I’ve also seen a similar thing posted on “maker” type websites but I do not remember where.)

6

I didn’t come up with the idea, I read some references to that (or another) German article somewhere but saw it was in German with assembler code and just decided to test myself in my own way. My searches here didn’t find arekm’s post but I guess I didn’t use the correct search words.

As long as someone didn’t go down this road only to find it a dead end I’ll continue looking at it. I am ordering one of those cheap IR thermometers, should be good enough to see if the results are consistent enough to use.

Edit: This is where debugging would come in handy. I’d like to be able to see what the loop counter is landing as the temperature rises. Now I have to have the LED blink it out to me.

7

Very interesting. Haven't heard of anyone around here working that angle. My understanding is that the hive mind here thinks you need external components to monitor temp with Attiny13a. Given the shortage of pins on the Attiny13a, this definitely warrants further investigation.

8

Regardless, it’s not a bad thing to pursue. It will be interesting to see your findings!

[EDIT: I already knew about arekm’s post. I do not think I’d have found it either if I was getting ready to start your project w/out prior knowledge of the post.]

9

Interesting…heat actually affects clock speed on the ATtiny…hmmm

10

I've also seen articles on that 1-2 years ago, with a demonstration for detecting relative temperazure changes, but since even the ATtiny25 with it's built-in temperature sensor gives a poor absolute accuracy of +- 10°C, I passed on experimenting with the frequency shift. I'm curious about your findings.

11

Continuing without an IR thermometer is pointless so I went down to the local electronics shop and picked one up. With it I should be able to determine the accuracy.

12

I’ve done some measuring and have a some data. The IR thermometer had a hard time measuring directly on the pill so I put the pill in the host and put the thermometer over the light like this:

I programmed the light (a Convoy S2 with ~4.4A) to heat up with PWM set to 255, and when the threshold was met I had the PWM switch to 7 so it could cool down until under the threshold, then back on 255 to heat up again until the threshold was met, and so on.
It’s the MCU’s temperature that triggers the threshold switch so the host temp would lag a little and continue to rise for a second or so after the light switched to low PWM. Same thing happened when cooling down although not as noticeable. Thermal paste was used between the MCPCB and pill, but not between the pill and host.

The values from the IR thermometer are presented like this: first column is temp reading of the host when the threshold to switch to low PWM was met (called it OFF), next is host peak temp before it started cooling down, and third value is temp when the light was cool enough to switch back to PWM 255 (ON). I let it run for 15 ON OFF cycles.

This first list is a list of measurements done with the pill screwed into the head but with tube off and 4.2V from power supply unit.

Edit: Temperatures are celsius

OFF - Peak - ON
38.0 - 42.3 - 39.9
40.3 - 43.0 - 40.6
41.5 - 43.8 - 41.2
41.5 - 43.7 - 41.3
41.3 - 41.5 - 41.4
41.5 - 43.3 - 41.4
41.6 - 44.0 - 41.4
41.9 - 44.8 - 41.7
41.8 - 44.3 - 41.8
41.8 - 43.3 - 41.5
41.4 - 42.4 - 41.5
41.7 - 44.6 - 41.8
41.9 - 44.1 - 42.0
42.0 - 44.1 - 41.9
42.0 - 44.0 - 41.9

This second list is a list of measurements with the light fully assembled and with a cell charged about a week ago (Sanyo from 18sixfifty).

OFF - Peak - ON
35.4 - 37.5 - 35.7
36.3 - 37.8 - 36.8
37.4 - 38.6 - 37.6
37.5 - 38.2 - 38.0
38.3 - 39.2 - 38.6
38.7 - 39.3 - 38.8
39.3 - 40.5 - 39.3
39.3 - 40.1 - 39.5
39.5 - 40.3 - 39.5
40.2 - 41.8 - 40.1
40.2 - 41.1 - 40.1
40.5 - 41.7 - 40.3
40.7 - 42.0 - 40.5
41.2 - 42.7 - 40.8
41.4 - 42.7 - 41.0

Sorry about the presentation. I tried the table formatting but it crapped out on me.

The actual temp readings of this IR thermometer can probably not be trusted, but I’d like to think that the temperature differences are reliable enough. Also worth noting is that heat up and cool down times varied a little, but everything went to fast to record times.

As I was measuring the host and not the pill I can’t really be sure of what to make of this data. The host temp when the threshold was met generally got higher as the test went on, and took less time to reach the threshold (on heating up at least). I guess this is expected as more heat was stored in the host?

My initial thoughts are that appears to work pretty well. It’s too bad I can’t measure accurate temp of the pill though. I started with a few measurements with the thermometer on just the pill but it seems that with a smaller object the readings where less accurate.

Anyhow, I’d like to hear opinions. Waste of time or worth pursuing further?

13

Would filling a pill behind the shelf over the attiny on the backside of the driver with potting give closer readings as the entire thermal mass would heat rather than the static air behind in the space between driver and shelf/star of the pill?

14

I’m not really entirely sure what the data is, did I graph it correctly? OFF and ON seem to track well… if that’s a good thing? Could you elaborate for me on exactly what these columns represent? Maybe I’m just being stubborn… :frowning:


15

:beer: Could good enough for an overheat safety. It might be more consistent than it looks since this is just measuring the head. How about a thermocouple or just a thermistor on the attiny to see if the numbers there are more consistent?

16

The technique could work with a particular tiny13, but the thresholds would need to be customized for each chip. Try doing it with a dozen or so tiny13’s from different date codes and see what happens. Also check the counter values at different room temperatures (using a low PWM level).

Also try with the light cooled in a freezer, refrigerator, room temperature, hot car to get a feel how the environment affects it.

17

Oops, I’ve re-read Mike C’s last post and I see that my graphs are 100% wrong. The data visualization will be a bit more complex to properly represent this, but it’s not a big deal.

18

I thought about it, but didn’t as I’d guessed the air would heat quick enough as the S2 pill is pretty small. I’ll do it though, the results I got are good enough for me to continue and compare with a potted pill.

I turned the light on from cold so it had max output. When the overheat threshold was met the light turned itself OFF (not exactly off, but PWM level of 7). Although OFF the thermometer registered increasing temps and peaked after a second or so. The light then cooled down, and when it went under the threshold the light turned itself back ON again.

If we look at the first entry the light turned OFF at 38.0C, temp continued to rise for a second or so, peaked at 42.3, then dropped down to 39.9C before the light turned itself back ON again. Next row is when it turned itself OFF again, peaked, and then back ON… and so on and so on for 15 cycles. Peak temperature is probably not that interesting, but worth noting to point out thermal lagging. I won’t care about registering actual peak temps in any further tests, but I’ll be looking at it. I didn’t bother recording times, the light heated up pretty darn fast and I was a lot more interested in the thermometer readings.

Hmm, I can’t find much info on the tolerances between revisions and the datasheet seems pretty specific on oscillator frequencies vs temp. How much do you think the differences will be? The values I am getting from a single 16 ms watchdog cycle are not that high so I wouldn’t expect any major differences. I’ll try a few others, not a dozen, and if results are close it will be enough for me. If one is going to be picky, one should calibrate turbo timeouts for each particular ATTiny13.

I’ll definitely do some of this.

I’ll do a little more testing with a couple of other ATTiny13a’s, do various refrigerator, freezer & oven tests, and also with a potted pill. It’s pretty time consuming so it’ll take awhile, but I’ll post the results here when I get ’em.

19

I am not a programmer by any means so take what I say with a grain of salt.

The idea of temp self monitoring without additional components is definitely a great idea and from the looks of it very possible. From the real usage standpoint it would need a timer on the off side to prevent reactivation (don't know if it is possible).

As the tests show, once the host is heated up from cold the on/off cycles increase in frequency because the host never truly cooled down and they never will after the initial turning off unless the usage of the light ceases. With a timer there is a forced cool down period and then you get your ability to use back. Somewhat of a combination of a stepdown timer and an internal safety lockout to prevent self destruction, if that makes any sense.

Or maybe a better way to explain is (just pulling numbers out of thin air):

- 100 c thermal protection kicks in

- 100% locked out for 3 minutes

- If desired safe temp is reached then 100% can be reactivated manually (a constant auto on/off can make someone crazy)

With that said, I also like to use my own judgement on what I think is or isn't to hot to handle/use based the on necessity of the light at the time. 100% might give me 5 minutes where 50% might give me 15 minutes but low would not be enough light at any amount of time.

20

Yeah, the on off behavior is only for testing purposes. It would certainly be annoying for normal usage. As mentioned by others, I need to test a couple of other MCUs, stick ’em in the freezer, pot the pill and so on. I won’t be changing any code between these tests.

What I intend to use this for (if it works good enough) is to replace turbo timeout with temp monitoring. Instead of switching to a lower mode based on time it will switch based on temperature. Turbo timers are reset by clicking back to turbo or turning the light off and on again, while my temperature threshold method does not allow turbo mode until the light has cooled down to a set value. I can turn the light off when it’s in overheated mode and turn it back on and it will not go to turbo mode until it has cooled down. I couldn’t trick it or reset it.

For my testing purposes I use the same threshold value for turbo on and off. If I later put temp monitoring into use I could use a lower value for turbo on after overheat, forcing the light to cool down more before allowing turbo mode again.