Workarounds/known issues 7/22: Updated for FRX07

[gtmethod3]

Originally Posted by [sammich]

Stickied

Great news!



I'm not sure if this has been mentioned or not, I did not see it on the list. I have noticed that my battery drops 20%-30% whenever I make a call and shortly after I hang up (2-4 mins) the battery level slowly creeps back up. My guess is that when the communications chip becomes active, the current it uses causes the battery to think it is lower than it should be.

This makes sense since phones have rated talk time and standby time. No idea how to fix it, just figured I would make note.

[arrrghhh]

Originally Posted by gtmethod3

I'm not sure if this has been mentioned or not, I did not see it on the list. I have noticed that my battery drops 20%-30% whenever I make a call and shortly after I hang up (2-4 mins) the battery level slowly creeps back up. My guess is that when the communications chip becomes active, the current it uses causes the battery to think it is lower than it should be.

This makes sense since phones have rated talk time and standby time. No idea how to fix it, just figured I would make note.

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.

[gtmethod3]

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!

[arrrghhh]

Originally Posted by gtmethod3

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!

Ironically camro did basically just that. Meter used to be WAY jumpier. I'm guessing you weren't around pre-Oct 2010 .

[manekineko]

Originally Posted by gtmethod3

Great news!



I'm not sure if this has been mentioned or not, I did not see it on the list. I have noticed that my battery drops 20%-30% whenever I make a call and shortly after I hang up (2-4 mins) the battery level slowly creeps back up. My guess is that when the communications chip becomes active, the current it uses causes the battery to think it is lower than it should be.

This makes sense since phones have rated talk time and standby time. No idea how to fix it, just figured I would make note.

Thanks! Added it to the list.

[manekineko]

System server bug removed from list thanks to the new rootfs.img.

Always satisfying to remove something from the list!

[arrrghhh]

Originally Posted by manekineko

System server bug removed from list thanks to the new rootfs.img.

Always satisfying to remove something from the list!

Heck yes. Awesome work by stine, considering his device didn't even exhibit the behavior .

[manekineko]

Keyboard indicator lights now working in mainline kernel starting from 1258!

[manekineko]

Updated to reflect that camera now works, and USB mass storage works on NAND builds and on some Neopeek builds!

[manekineko]

Updated with new information on getting CDMA location and buttons beneath screen working.