-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: >>> Bugzilla Bug 1181 - Battery temperature is incorrect >>> http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1181 >> Is it for sure true that the 10K does not exist INSIDE the battery unit? > > I would say that it has to be true, but I don't know what is actually > in there. If you take an Ohm measurement from the thermistor terminal > to the ground terminal on a battery, you can get numbers higher than > 10k. I put a known thermistor next to the battery and let it run at a > few different loads and the new calculation tracked the reference > measurement correctly (there was a +4C offset, which seems reasonable > since the thermistor is inside the battery packaging and my reference > was outside).
Sounds like a good test to me. >> - - Math could result in negative values, but unsigned types were used >> >> OK.. I guess this means that -mA means charging. > > It's the other way, actually. We're measuring charging current so -mA OK >> This didn't make any sense to me... the ADC values are u16s, how can we >> overflow a u32 multiplying them by 2400? ... > adc_adcin1 and adc_batvolt are both u_int16_t. Multiplying them by a > large number before implicitly casting them to a u_int32_t is what > could cause the overflow. That is why I made an explicit caste before > the multiply. Again, I changed it to a signed type. Wouldn't be the first time gcc surprised me but doesn't stuff get promoted to int before any arithmetic happens? - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHmhWVOjLpvpq7dMoRAu2IAJ0fOe1Quc5UwXJnO+9xhtnNK3fxWACfZobF EApiXlLuoWYos/WF9Ht8uFs= =fpax -----END PGP SIGNATURE-----
