yashsingh1/xdaforums huggingface dataset:
[Nexus One Android Development] RogerPodacter:
i know the << is supposed to stand for bit shift, however that function is supposedly only reading the data, not writing. if you notice the temperature code you posted, the comment says "11 bit signed result". so the way i see it for temperature, they grab all 8 bits for MSB ( << 8), and only 3 bits from LSB ( 8 - 5 = 3 since they only grab >> 5). that's where the 11 bits signed result comes from, 8 + 3. they are saying temperature only ever needs 11 bits of the total 16.

for the charge_uA they are just grabbing all 16 bits, 8 bit from MSB ( << 8), and 8 bit from LSB (which i guess needs no >> 8). no limit on charge_uA, it can use all 16 bits...

so the point is those << are just telling which bits to read. that's my theory anyway, i'm gonna do some googl'ing first (of to work first!). if those are NOT reading only, then we would have a serious problem attempting anyhing without knowing what its doing...

found this:
[Nexus One Android Development] dvgrhl:
"<< 8" means to bit shift 8 to the left. This is the same as multiplying the number by 2^8, or 256. So for example: (00000000 00001000 << 8) = 00001000 0000000 = 2048. Notice how we moved the bit to the left 8 positions. Bitwise operators are just that, operators, so they don't overwrite the value of what they are being performed on.

Here's maybe a better example. Say I have a binary number 01011011 and I want to find out what the second bit is. I can do a bitwise AND like this

01011011
AND 00000010
-----------
00000010

so effectively

if(01011011 & 00000010) {
#we reach this if the second bit was a 1
} else {
#we reach this if the second bit was a 0
}

So that's how you can use bitwise operators to get values of specific bits. We saw this with the CHGTF flag, where the value was used in a bitwise AND operation against 0x80, or 10000000 in binary. We know from the spec sheets that the CHGTF bit is the 8th bit, so doing the bitwise AND operation returned either 0 or 1000000 corresponding with whether the CHGTF bit was a 0 or 1.

Hopefully that doesn't confuse things more for anyone.
[Nexus One Android Development] theloginwithnoname:
No that's very helpful. Unfortunately I don't know how many bits to shift or what to get the quoted registers/values - can you advise any more on that?

For example: AGE_SCALAR - how do I know 1) whether to use int, u8, u16, or u32, 2) which bits to shift, and 3) how to output?

I guess the tech specs should have this somewhere (e.g. the references I have added on first post state "1-byte", "2-byte" etc - does 1-byte mean one <<, 2-byte mean one << and one >>????)

HELP!
[Nexus One Android Development] dvgrhl:
From the spec sheet, AGE_SCALAR is a one byte value. Are you wanting to just print it's value, or understand what that value represents?

If AGE_SCALAR == 0x80, then that represents an unaged battery. If AGE_SCALAR == 0x40, that represents a 50% aged battery and then that is supposed to initiate a learning cycle.
[Nexus One Android Development] theloginwithnoname:
Glad you're drilling down on this fella. I want to output that value as a decimal/float (3.2 prefereably, e.g. 98.52%).

So:

1) how do I get the value and output in "human" form (i.e. decimal/float)

2) how do I do the same for 2-byte values

3) how do I determine which is what??
[Nexus One Android Development] dvgrhl:
I am at work so can't I go into all these questions right now, but

1) Converting from binary to decimal isn't a hard thing to do. We know that 0x80 is 100%. 0x80 = 128, so current_value/128 = percent.

2 & 3) If the specs don't tell you, then there are tests we can do to determine what it is. strlen() I think, I can look into it later today.

If you want something to play around with, Google "C binary to int" and also lookup the strlen() function. You can probably write a little C program to test out logic, then put it in place in the Android code.
[Nexus One Android Development] RogerPodacter:
Following that logic, from the data sheet, we know that all addresses are single byte (8 bits). And for some addresses where they need 2 bytes worth of storage they double them up and label them MSB and LSB most sig byte and least sig byte (which we can determine from the mapping address code), but both are still only 8 bits each.

So is there a generic to just call all 8 bits of any address we want? Even if we pull extra non used bits they should just show up as zeros I'd think.

EDIT: that's not true, from page 29 of data sheet, for MSB and LSB they are 16 bit values:
[Nexus One Android Development] RogerPodacter:
theloginwithnoname, i've not seen the HTC code. maybe you could post a snippet of the parse function they are using for any additional values that we've not seen so far? maybe some of the ones you've successfully added.

our current objective: we need age_scalar and age_capacity.

i'm reading thru the example PDF's, but they just dont show all of them, such as age_scalar, so its almost a guessing game. but they DO show in the data sheet, for example age_capacity is mentioned in the data sheet:

so when we pull that value, we're gonna have to multiply it by 6.25uVh just like google does to all the others in the main driver code parse function.

similarly:

same with age_scalar above (bolded). now see attached image, they use that value in the equation (2^-10 = 1/1024) to send the value INTO the register, so when we pull it out we need to do the same thing (or opposite technically). my gut feeling is the palm pre driver does this for all of their addresses, they added equations for all of them, so they read the register value and the driver makes it into readable "human" form:D.

unless you know otherwise from playing with the added HTC values and getting outputs. if so let me know!

anyway, i wont be able to add the reference stuff till late tonight; i keep getting side tracked and then have to take care of something after work!

Edit: damn my values are similar. Rated capacity: 255 (bogus), Age scalar: 30976 (same, bogus most likely), age scalar simple: 121. Interestingly 121*.78=94.38. Likely bogus and coincidental.
[Nexus One Android Development] RogerPodacter:
Turns out my above post is correct. Somline reversed each register calculation to get and set the hex value. See this post.

http://forums.precentral.net/palm-pre/256967-find-out-how-good-bad-your-battery-15.html#post2613586

We have to multiply by 1/256 or 0.78. The problem is my register values are not updating, its always 121. Also age scalar 30976 is the bit value if 121 by multiplying by 2^-8. So the point is these would be correct, but why are the registers not changing? Is the code ok? Or is there something else missing...

Edit: I think this will help with the bit shift issue. Somline explains it and how it works in the hex conversion equations. It's exactly what we need to do, << 8 etc. Hope this helps.

http://forums.precentral.net/palm-pre/256967-find-out-how-good-bad-your-battery-14.html#post2612442
[Nexus One Android Development] RogerPodacter:
Damn I finally figured out the bit shift stuff and how they are entering each value into the register (in my favorite example pdf's lol). Technically it should be possible to just reverse that for any register we want. Damn I wish I had compiler setup.
[Nexus One Android Development] dvgrhl:
I've got my compiling environment all set back up again, and I have a successfully compiled stock CM kernel. I haven't been successful in flashing it to my phone though. Here is what I have been doing:

$ fastboot flash zimage /home/jon/android/kernel/cm-kernel/arch/arm/boot/zImage
sending 'zimage' (2181 KB)... OKAY
writing 'zimage'... OKAY
$ fastboot reboot

But when the phone reboots I am still on my normal kernel. I had thought I could do this and be running on the zimage I flashed until the next time I reboot. Any idea what I need to do differently to do this?
[Nexus One Android Development] RogerPodacter:
you are flashing the boot image with that command rather than doing a one time boot that will clear upon next reboot. you need:

fastboot boot zimage <path to zimage>/zImage

what you did was permanently flash it, but that still should have worked. how do you know its your original kernel vs not the new one? i.e. any changes made etc. sorry i hope that wasnt a "noob" answer and you already knew that. just trying to help:D
[Nexus One Android Development] dvgrhl:
The reason I think it didn't work is that the version information under Settings->About->Kernel didn't change. Thanks for the info about "boot" rather than using the "flash" command. Now I need to figure out why I get a "cannot load" message about the zimage when I use the boot command.

Edit: Figured out the "cannot load" issue, the command I needed to do was just "boot", not "boot zimage". But thanks for putting me in the right direction Roger. And it did work, but the info in Settings->About->Kernel did not update, so that must be set somewhere else I am guessing. I'm going to try making the changes we discussed for modifying the battery output to the log. That should let me know for certain if the zimage (and our code) worked.
[Nexus One Android Development] dvgrhl:
Roger this is the output of the log using your modified code:

09/05/2010 22:12:42 [INFORMATION] batt: 100%, 4157 mV, 57 mA (18 avg), 37.6 C, 1368 mAh, 3 full40 mAh, 3 aged capa, 121 scalar, 0 rated
09/05/2010 22:13:32 [INFORMATION] batt: 100%, 4143 mV, -41 mA (35 avg), 37.6 C, 1364 mAh, 3 full40 mAh, 3 aged capa, 121 scalar, 0 rated
09/05/2010 22:14:28 [INFORMATION] batt: 100%, 4148 mV, -66 mA (-80 avg), 38.8 C, 1364 mAh, 3 full40 mAh, 3 aged capa, 121 scalar, 0 rate
09/05/2010 22:15:18 [INFORMATION] batt: 100%, 4153 mV, 0 mA (0 avg), 37.6 C, 1364 mAh, 3 full40 mAh, 3 aged capa, 121 scalar, 0 rated
09/05/2010 22:16:08 [INFORMATION] batt: 100%, 4153 mV, 0 mA (0 avg), 37.3 C, 1364 mAh, 3 full40 mAh, 3 aged capa, 121 scalar, 0 rated
09/05/2010 22:16:58 [INFORMATION] batt: 100%, 4153 mV, 0 mA (0 avg), 37.1 C, 1364 mAh, 3 full40 mAh, 3 aged capa, 121 scalar, 0 rated
09/05/2010 22:17:48 [INFORMATION] batt: 100%, 4153 mV, 0 mA (0 avg), 36.8 C, 1363 mAh, 3 full40 mAh, 3 aged capa, 121 scalar, 0 rated
09/05/2010 22:18:38 [INFORMATION] batt: 100%, 4153 mV, 0 mA (0 avg), 36.6 C, 1363 mAh, 3 full40 mAh, 3 aged capa, 121 scalar, 0 rated
09/05/2010 22:19:28 [INFORMATION] batt: 100%, 4153 mV, 0 mA (0 avg), 36.3 C, 1363 mAh, 3 full40 mAh, 3 aged capa, 121 scalar, 0 rated

Just thought you'd like to see that it all worked (though not exactly as posted, there were some missing ";" characters, though the general idea was sound :)).

Edit: And on an entirely unrelated note, I always read your name as Roger Podcaster. So if you ever started a podcast I would totally subscribe.
[Nexus One Android Development] temasek:
To fit stock back cover only up to 1600mAh battery so don't be too tempted to get bigger capacity unless u like BIG size.
[Nexus One Android Development] RogerPodacter:
My post got cutoff. I was saying by the way we've all lowered our min charge current register 0x65 from <80mA to <20mA to squeeze little extra out of the top end.

Also we've lowered active empty volt from 3.416 to 3.201 and even tried 3.006volts to see if we could increase usable capacity. But the nexus battery is cheap and the volt drops so fast its unsure how much this really helps. We've seen some after market batteries with stock setting of 3.006volts out of the box. We're trying to extend capacity:-).

Also we've found a trick by writing to the acr register 0x10 if the mAh seems like its running out which guarantees to hit the empty volt and learn flag if the user missed the first attempt since normally the mAh would reset to zero at that point. It works well:-).
[Nexus One Android Development] chowlala:
I can't get big size. I've got an otterbox case. Hehe.
[Nexus One Android Development] overground:
Ok. Attempting this again on my stock battery. What pertinent stats should I provide after calibration? Assuming success.

EDIT: Navigation (via Maps) to a random location + Pandora + Hotspot + full brightness + screen never timeout = 400 - 600+ draw
[Nexus One Android Development] 19blacktiger77:
Do you know S-OFF? How can i have it without Root... :rolleyes::rolleyes::rolleyes:
[Nexus One Android Development] 19blacktiger77:
I have this version of battery app: 0.8.7 Beta. In general tab i can't edit Min Chg Curr (mA)... :confused:

How did you do? Thanks! :)
[Nexus One Android Development] mtw4991:
go to root explorer and longpress the setreg file, then click on "Open in text editor" and type "0x65 06" w/o the "", then save & exit. Chg. current(mA) should now be set to = 20. In terminal, echo 65 06 > setreg (I think, I don't use terminal much)
[Nexus One Android Development] 19blacktiger77:
It's exactly what i did... :rolleyes:

"That procedure you've pasted is not up to date anymore... In the new version of the battery app (Battery Calibrator) the temporary capacity is set by the app when its about to reboot.

Also most of text editor won't open the setreg file. Instead you should use: echo "0x66 a4" > setreg."

http://forum.cyanogenmod.com/topic/11823-battery-calibration-thread/page__view__findpost__p__100958
[Nexus One Android Development] mtw4991:
Well, that post is outdated I believe as I updated the instructional OP yesterday. I don't know what "most of text editor won't open the setreg file" means???wtf? If he meant to say, "most text editors won't open the setreg file" he is right, that's why we said to use Root Explorer. So then:

Using root explorer, go to /sys/devices/platform/ds2784-battery and LONG PRESS the setreg file. Options will pop up, scroll down to Open in Text Editor and type 0x66 06 to set the minimum charge current(mA) which was your original question>>(In general tab i can't edit Min Chg Curr (mA)...) You said nothing about setting capacity(mAh) and yes, the new app will set it for you. Guess it is not clear enough in the directions...I'll update as soon as Roger gets the new acr code compiled into the app.
[Nexus One Android Development] 19blacktiger77:
But i used root explorer! With partition mount as R/W, but doesn't work! Trust me!

The file appears blank and still remain blank after write.
[Nexus One Android Development] overground:
It's supposed to be that way. All it does is set the value then clear itself.
[Nexus One Android Development] mtw4991:
This is true. Trust me...just type in code, press menu and select save/exit. You should get a toast popup saying that the current file has been saved as a backup and the screen will be white and blank again...waiting for the next command.
[Nexus One Android Development] starfarer:
Do i need to "inputs" those values on next learn mode? or once set, we can skip those steps?
[Nexus One Android Development] mtw4991:
Not really, if you do another learn cycle, the settings should remain the same except for the age. Reset it back to 100% to do another learn.

If you have already done a successful learn cycle, then you know your battery's age and all you have to do is make sure the age is set correctly and charge to full. This way you should be able to drain from 100%-1% without shutting down at 10-15%.
[Nexus One Android Development] pwig:
How do you set the age manually? It's not in the app.
[Nexus One Android Development] temasek:
App only have option set age to 100. If u want other figure, edit "setreg" from the driver directory and input

0x14 xx

xx being a hex value of your age.
[Nexus One Android Development] mtw4991:
from the cheatsheet:

0x14 6a = 82

0x14 6f = 86

0x14 70 = 87

0x14 71 = 88

These are all I know:( ask Temasek for others, he's better at hex than I am by far lol
[Nexus One Android Development] RogerPodacter:
it may prove to be popular so we can add all the common registers to be set in the app if that's what turns out people prefer. I think the idea was we were trying to finalize the app as a learn mode detector at version 1.0, then expand functionality from there. It would be straightforward to add in min charge current, empty volt, etc.
[Nexus One Android Development] overground:
Dammit, got a calendar notification @ 3 hrs 15 min. I guess there's always tomorrow. :mad:
[Nexus One Android Development] RogerPodacter:
thanks for this link, i hadn't checked it yet. there's definitely a bug i didnt see before, minor though, where learn button is off but the ACR still bumps up in learn mode tab. checked the code and its an easy fix.

also i made the code changes last night so tonight when i get home i should be able to compile the apk and get it out there.

by the looks of it, the ACR write feature is working as intended, which kinda blows my initial hunch out of the water. i was sure its backwards but i guess if it works then go with it.

also there were some good suggestions in that thread, like tracking your full40. we do intend to track your age so that the app remembers your individual age and sets it if not already set. maybe detecting your true full40 could be a future addition too. in fact it could almost be like a battery profiles thing, where if you have multiple batteries you keep each one's parameters on file in the app, and can pick one in the app when a battery is swapped and it sets all the params accordingly lol..
[Nexus One Android Development] mtw4991:
That would be sweet Roger, especially since a bunch of us have ordered the 1600mAh battery! Also, were you saying that the ACR was bumping up capacity even when the learn mode button was off, if it got down low enough? Actually, it's not necessarily a bad thing as it would ensure you always run down to 3201mV prior to shutdown;)
[Nexus One Android Development] RogerPodacter:
yeah true. i guess some people dont expect it to perform acy action if the button's turned off and just like using that tab to monitor stuff. i wonder if there's a better way than a radio on/off button to turn learn mode on or off. a big toggle button? a settings option? eventually i think we will turn the learn detect into a service so it can run in the background and the user can keep using the phone, then when it gets close alerts the user its almost time etc. Dvgrhl brought this up and it's a great idea.
[Nexus One Android Development] mtw4991:
I'm currently at 22hrs. 45mins with 14% left at 179mAh/3669mV. Interesting that in awhile, I'll see the ACR bump up the mAh's:p What is the programmed bump point...<70mAh? The down side with this is we never get to watch it get down to 1%-2%, right?
[Nexus One Android Development] RogerPodacter:
that's not bad:). yeah well it will bump up at <70mAh and if your volt is within 0.2 of the empty volt. but it still seems like that is leaving out those that would hit <70mAh and NOT be within 0.2 of their empty volt. in that case, they would still run out of mAh because they only have 70mAh left, but their volt is up in the mid range, so the ACR write will not kick in. i think THOSE are the times when we need to bump up and what the original intention was...

but i think i could also be thinking of it wrong too...:D:o:eek::confused::p
[Nexus One Android Development] mtw4991:
I see what you mean. Maybe something like this would insure that you don't run out of mAh prior to draining mV?:

if mAh <=70 and mV = (3.400 -.2), then add mAh+200

or else

if mAh <=50 and mV = >3.400, then add mAh+200

I'm not sure where (or how) to set the values, but the battery % is pulled from the mAh right? No matter which way you do it, you're never going to see the 1% point as you will always have 100-200mAh left when mV reach 3201 and shutdown occurs. Seems like it is kinda defeating the purpose then as you'd never really know when its gonna die unless you are staring at the app right?

EDIT: boy, am I a dumb ass, lmfao! I'm sitting here watching it drop below 70mAh and when it hits 67mAh @ 5% I effing realize that I'm using the 1203 app that I was testing the age reset parameters on!

The good news is I'm at 1day 15 mins and have 49mAh's & 3580mV left at 4 %!
[Nexus One Android Development] overground:
I also brought up the same idea a few pages back.
[Nexus One Android Development] RogerPodacter:
Cool well I guess your dumpreg is the same so your capacity must be legit. I thought maybe some type of coulmmb counter or current offset register could be set wrong which could make counting mAh thru the acr inaccurate and report such a high capacity. But I guess not:-). You lucky duck I hope mine is like yours!
[Nexus One Android Development] 19blacktiger77:
Ok, thank you both! ;)
[Nexus One Android Development] 19blacktiger77:
But wiping battery stats what does erase? There's need to do that?

Thanks! :)
[Nexus One Android Development] 19blacktiger77:
You're welcome! ;)
[Nexus One Android Development] mtw4991:
No, there is no need to wipe batt stats, that is just a history file, it doesn't really do anything.

EDIT: Got down to 1% with 11mah left and 3310mv remaining at 24hrs 45mins with mod-heavy usage. I call that success with the 1203 app! Tomorrow I'm going to test the app with Rogers new code if its ready but its gonna be hard to beat
[Nexus One Android Development] somline:
Very interesting. I already read a bit more in your threads about it. Good work.

I will look into it over the next weeks.

Maybe I can include some of it in Dr.Battery.

Thanks
[Nexus One Android Development] theloginwithnoname:
You've got some more capacity there old boy! I reckon you could squeeze another 50-100mAh out, perhaps more, with that voltage...
[Nexus One Android Development] mtw4991:
Yeah, maybe a little bit more but it seems that once I get around 3300mV it drops fairly quickly to 3201 so I'm not sure it could eat another 50mAh prior to reaching 3201.

Also, is there a lower end "reserve" in the code? Seems my phone always shuts down once it hits 9mAh and then drops to 7/8/?mAh. It will drop 1,2 or 3mAh when normally updating, but the next update after 9mAh is always bam! & down.
[Nexus One Android Development] RogerPodacter:
there's no reserve in the code, but there is an empty mAh register that will shut the phone down if you reach that mAh. this register varies depending on your real time temperature, so if your phone is hot it may be 9mAh but if its cold it may be 18mAh. hitting these points would shut down immediately.

it is directly related to those 4 slope registers if you've seen those before, each slope is a different temperature range. anyway i've tried to calculate the empty mAh but i dont know the exact equation, i came up with 19.2mAh a few times but i think that was too high.

the only time your empty mAh will be zero is at exactly 40 Celcius and above, all lower temperatures will be greater than zero.
[Nexus One Android Development] mtw4991:
got it...had forgotten about the temperature variable.
[Nexus One Android Development] RogerPodacter:
so i looked a little closer at this battery, and i actually ccant figure out a few equations. but your Current Offest Bias 0x7B is ea, and mine on stock is fd. but when i plug either of those into the PDF equation, i dont get the same answers that they do in the first place!

that and RSgain 0x78/79, yours is 04/21 and stock is 04/09.

interesting differences...i cant wait to get my 1600 and test it! it left Hong Kong yesterday...
[Nexus One Android Development] tech338:
Kernel Konfusion

Okay. I am still unable to get learnf to stick until charging is completed. I keep getting a [batt] Charging Off [timeout] problem before %100. Here is my log:

http://pastebin.com/x52f4CK7

At line 154, I loose learnf as charging stops. Phone was in airplane mode, screen turned off, and apps at a minimum - plugged into a HTC wallcharger.

In researching, it seems that some recent changes were made to the kernel and changing the values for charging timeout. So I think my problem is the PureFroyo Kernel which was last updated 11/26 but still has the enhanced DS7284 driver stuff. Guess it's not up to date...

With that said, which kernels seem to work best and have the latest/greatest code? Perhaps the OP can update the 1st/2nd post with kernel compatibility info?
[Nexus One Android Development] mtw4991:
I have no problems with timeouts on WM latest kernels, but Pershoots have the 3 hour wakelock fix and should be fine. idk if CM6.1 kernel has the 3hr fix, but I don't have issues with it either. Maybe contact your kernel dev??