Quote:
Originally Posted by arrrghhh
You noticed that too eh? viruscrazy explained that camro's battery code doesn't take into account peripherals whatsoever - so basically any radio, modem, etc that draws from the battery is not taken into account.
I've been chatting with WisTilt2 about this frequently as well, and there's a lot of agreement that the battery code is going to need to be either completely rewritten or severely overhauled. Not to discount camro and his work, but he never really finished his work as his phone blew up basically and never returned to the scene. We were going to get him a phone, but he didn't seem interested. So it's not an easy fix, but we do know what needs to be done at least - and sometimes that's half the battle  .
WisTilt2 has a lot of things on his plate with this project at this point, but he did say he wanted to talk to jonpry soon about rewriting this code. I look forward to seeing what he can do to improve this - there's a lot of bugs with the battery code, they're just not easily seen as batteries are mysterious beasts. |
Ahh, that makes a lot of sense. It's interesting to think how much coding is involved for a simple battery reading. I can't imagine what coding the rest of the device could be like!
Thanks for the reply, not a huge issue by any means, but a minor annoyance. I have noticed that different battery meters from the market give me back different readings sometimes but usually return to a roughly similar value. Perhaps they use different algorithms.
Wouldn't a relatively simple thing be to apply some sort of moving average in the reading? it wouldn't fix it in the long run but get rid of the small fluctuations. Though its such a minor issue that it may not even be worth it. I wish I knew how to code in Linux!