Battery third (temp) terminal as multipurpose analogue input

Thinking on making a dummy-battery for one of my cameras (to hook up to a larger external battery). I know CHDK lets you read the temperature of the battery, so I'm sure some sort of variable resistor could be hooked up to the temp terminal and be read by a user script. My only question is what the update rate would likely to be: how often can the camera poll the temp sensors? Would it be say once every few seconds (in which case it would be pretty useless for most applications) or say maybe several or even dozens of times each second (in which case it would work). Also, what would the resolution be likely to be? I'm guessing the range would be from maybe -20 to less than 50 degrees, would decimal points be achievable for greater accuracy?

Of course many applications would come to mind with such an easy to access analogue input, and it wouldn't require a bulky USB cable to be connected as well.

Sounds like a great little project!  I don't think anyone has done a lot of work on this so anything you find out and report back here will be well received.

Well the thermistor in the battery should be 10K Ohms at normal room temp. (Probably 10K at 20 C) I think it is probably something similar to this (in terms of function, if not structure), and probably NTC (i.e. its resistance increases as temp decreases and vice versa).

See here: for a teardown of a canon battery. Note that in this case the thermistor had been substituted for a fixed value resistor of 10K Ohms.

Now I haven't had time to play with this, but it is possible that so long as you keep the range of inputs within the range that the camera considers a safe temperature, you should be able to use the input for whatever you fancy, an LDR, external temp probe, PIR input, and an external zoom and/or focus controller, were ideas that sprang to mind.

As to how often it is polled, I have no idea, that you would either need to work out from the code, or by experimentation.

If you set a value for that resistor that suggests the battery is overheating, (and maybe even that it is in danger of freezing) then the camera will probably shut down (unless you override that function in the firmware somehow).

 

Well I just did some testing on my IXUS 65 that I recently acquired and found that the temperature range was from -10 degrees C (open circuit) to 90 degrees C (shorted to gnd). The camera did not shut down at this temperature though (I have yet to test this with my SX40 though), I also tested it with a range of fixed resistors. The resistors are fairly accurate probably about +-1%. The results here may have some typos though.
I'm guessing the pull-up resistor would be about 22kohms according to Ohm's law (assuming about 3.1v open-circuit, see below)

k ohms	degrees C	Voltage
56	-9	2.25
47	-6	2.14
39	-3	2.01
33	1	1.89
22	9	1.57
12	21	1.13
10	25	1.01
8.2	29	0.871
6.8	34	0.756
5.6	38	0.647
4.7	43	0.56
3.9	47	0.488
3.6	49	0.448
3	53	0.385
2.2	61	0.291
1.8	66	0.241
1.5	74	0.18
1	80	0.141
0.68	88	0.096

If anyone's interested in deriving a formula:
https://en.wikipedia.org/wiki/Thermistor#Steinhart.E2.80.93Hart_equation   
Personally though, I think I'll just go with a 50kohm logarithmic variable resistor and guess the values or calibrate it as needed

Out if interest, the open circuit voltage on the temp pin ranged from 3.015v (with the display on sleep) to 3.115 (when about to take a photo). Interestingly enough, the voltage was higher with a flatter battery (or with more current being drawn). However, the actual temperature readings taken with both a charged and nearly flat battery weren't noticeably different.

As for the polling rate, I have yet to measure it, but it seems to update constantly at a very fast rate, so I guess it would be no problem for most of the uses I have planned for it. I guess I'll play around with some code tomorrow and try to get a variable resistor controlling maybe exposure or zoom or something. Any idea if it would be possible to have a script running in the background polling the temp sensor while the camera is in sleep mode? I reckon that combined with a PIR sensor would make a killer motion-activated photo-taker that would last for weeks on one battery.

That looks logarithmic to me.

In fact it looks remarkably similar to this...

... which would make the formula...

"The standard formula for NTC thermistor resistance as a function of temperature is given by: "



"where R25C is the thermistor's nominal resistance at room temperature, β (beta) is the thermistor's material constant in K, and T is the thermistor's actual temperature in Celsius."

... which is about as exact as you will ever require ... or you could just use a lookup table 

As for the polling rate, I have yet to measure it, but it seems to update constantly at a very fast rate, so I guess it would be no problem for most of the uses I have planned for it.

Looking at the D10 firmware dump, the Get*Temperature functions do not read MMIOs directly.

"Thermometer" task seems like it's might be responsible for this. It calls some stuff in  "ADCScn.c" that does look at MMIOs. From a quick inspection it looks like it would sleep either 300ms or every second between iterations. The 300ms case looks like it would be used to me, but I could easily be missing something.

It's possible you could read the MMIOs directly (using peek in lua for example) if you wanted a faster polling rate, though you might have to take care of calibration or smoothing yourself.

FWIW, if no battery is present (running on external power) GetBatteryTemperature returns -20c.

Any idea if it would be possible to have a script running in the background polling the temp sensor while the camera is in sleep mode? I reckon that combined with a PIR sensor would make a killer motion-activated photo-taker that would last for weeks on one battery.

Depends what you mean by sleep mode. In the display off sleep mode where the camera is running (assigning the "Zzz" function to print key) script running, so you could definitely wake up and respond to that. However, the battery won't last for weeks in this mode. If the camera is actually off, then CHDK isn't running. I'm not aware of any other sleep modes.

It's possible you could read the MMIOs directly (using peek in lua for example) if you wanted a faster polling rate, though you might have to take care of calibration or smoothing yourself.

That would probably give more resolution as well. Any idea of what the address is? Would it be different on each camera? I wouldn't need to enable lua native calls would I?

If I can get enough resolution I might try using an ultrasonic distance sensor to measure the subject distance and focus on it. Would beat using the AF lamp all the time.

If I can get enough resolution I might try using an ultrasonic distance sensor to measure the subject distance and focus on it. Would beat using the AF lamp all the time.

I know its not where you are trying to go,  but with a simple & cheap Arduino clone, you could read the ultrasonic sensor, convert distance to a pulse width modulated 5V signal and feed that via the USB port on the camera to be read by a CHDK script.

That would probably give more resolution as well. Any idea of what the address is? Would it be different on each camera? I wouldn't need to enable lua native calls would I?

I didn't reverse engineer this very thoroughly. Basically, I noticed that Thermometer task (findable by the string "Thermometer" followed by a createtask call) sits in a loop that (among other things) calls a function (at F843FC0) that reads MMIOs based on a table in ROM (found at FFAD6170). On D10, these range from 0xC0900040 to 0xC0900054 (followed by another set from 0xC0900080 to 0xC0900098, not clear if they are related). MMIO can vary between cameras, and it's more likely for models that were released far apart. I didn't see similar code for a540.

I tried dumping these, using the following chdkptp code
!status, t,temps=con:execwait('j=1 t={} for i=0xC0900040,0xC0900054,2 do t[j]={i,peek(i,2)} j=j+1 end return t,{get_temperature(0),get_temperature(1),get_temperature(2)}') for k,v in ipairs(t) do printf('0x%08x:0x%04x\n',v[1],v[2]) end for k,v in ipairs(temps) do printf("%d:%d\n",k-1,v) end
The values seem to be half words (the function only stores a half word) that vary, it's not immediately clear if they have a direct relationship to the temperatures.
The value at 0xc090004a seemed to be consistently 0x03ff when the battery wasn't present, and in the range 0xff to 0xe0 when it was present. get_temperature(2) was returning 37-41 over the same time.

edit:
I may be wrong, but I think that
0xc0900046:0x00e0 < ccd temp
0xc0900048:0x010a < optical temp
0xc090004a:0x00d7 < battery temp
where lower values correspond to higher temps. In addition to the battery removed value, this is based on watching the difference ccd temp in record vs play mode. Units are not clear (if this is correct at all, which is far from certain)

edit:
I think 0xc0900044 is related to battery voltage. ~0x351 at 4.2 volts (external power), ~0x2d9 at 3.66 volts (battery, rec mode)