yashsingh1/xdaforums huggingface dataset:
[Nexus One Android Development] thrik:
That is both interesting and highly disconcerting... my image of Seidio was that of a professional one.

But it seems like I lucked out in this case :) but we'll find out whenever my battery gets around to draining.
[Nexus One Android Development] RogerPodacter:
honestly they still really are the best, along with mugen. there was just the one serious palm pre issue which was shady, and then a few random cases here and there of wrong full40 values, not sure if intentional or not. but by far seido has the highest percent of correctly programmed batteries that we've seen, mugen too. all the cheap ones from ebay are most always wrong.

so its definitely worth buying the seido and mugen name for sure. its just there *were* a few cases..
[Nexus One Android Development] carblanco:
Can't get 3201mV

Hi all,

I think I've tried everything to get the 3201mV to start the learn cycle but my phone always shut down at aprox. 3400mV (8%)

The last I've tried is to send 0x10 03 to get those 300mAh but then battery drops from 95% to 27% with 4045mV so I thing that I'm doing something wrong.

If I want to down till 3201mV I must increase the battery percent just to reach 3201mV at a value in which my phone doesn't turn off (8%), right?

Or my phone can run with 0% for hours with >3201mV? Or which is the condition to turn it off?

Thanks.
[Nexus One Android Development] temasek:
You have seems to be wrongly informed of many information.

To start a learn cycle, your target drain your battery till you reach the Empty Voltage (AEv) of 3201mV. But you have to ensure that your capacity (mAh) is able to last till u reach 3201mV (AEv).

The manual pump of capacity (mAh) is

only necessary

when ACR Adjustment auto bump of mAh did not kick in.

So you manually bump up (if necessary) so that your mAh can last till u hit your Empty Voltage point (AEv).
[Nexus One Android Development] carblanco:
I see... but with ACR on I can't get down to 3201mV, the max I could down was 3400mV and then the phone turned off. So I think I need to tweak something.

Must I send 0x10 03? But then battery percentage goes from 97% to 27% with 4045mV

Thanks.
[Nexus One Android Development] onyxtouch:
good thread!
[Nexus One Android Development] temasek:
Now,

When u see your mAh drop to low level eg, around 100mAh but your Empty Voltage (AEv) still at high level, you can manually bump up the capacity (mAh) by entering 10 into the register tab and value as 01 for additional 100mAh or 02 for additional 200mAh, etc.

Keep bumping up mAh if it is still insufficient to reach your Empty Voltage point of 3201mV.

Doubts, pls revert. :)
[Nexus One Android Development] carblanco:
Ok, thanks, I'll report.

Just for my info, if I change 0x10 for entering in the learn cycle, must i change back to its stock value after the calibration? which is the stock value?
[Nexus One Android Development] temasek:
0x10 xx (xx being a value)

The above register of "10" is for manual bumping of your capacity in case in need more mAh to last till u reach your Empty Voltage point. You do not need to revert any value once u hit learn mode.

Btw when ACR adjustments are tweaked by Roger/Dvghl, it should work just fine for auto bumping of mAh when necessary. As for your case, just perform manual bumping of mAh if u really require. If you do not do that, your mAh drained before your Empty Voltage point, you will auto power down. Once it auto shutdown u will not be able to perform your learn cycle.
[Nexus One Android Development] Breece:
Ok my 1600mAh battery arrived. Can someone please point me to the steps needed to figure out the max capacity? :)

Thank you!

[edit]

I just set it up with 2500mAh and went into learning mode.. interesting enough none of the values refresh... Real-TIme Voltage stays at 4138442, Curr. 428.66 and Capa 104856...

wierd...

[edit2]

Uninstalled, rebooted, tried again... no change..
[Nexus One Android Development] dvgrhl:
For anyone having issues with the logging causing FCs, I threw together a current version of the app without the logging service until I can get around to fixing the issue: http://jonrichards.net/xda/battery_calibrator/BatteryCalibrator1.1.0-NoLog.apk.

I'll also take a look into the ACR write problem.
[Nexus One Android Development] RogerPodacter:
i think i see some maxed out registers in your new battery unfortunately. is your capacity really showing as over 100,000 mAh? if so, then your full40 is likely locked to maximum, both registers, ff or 255.

honestly i think these types of batteries are still usable, but you cannot perform a leran cycle nor can you change the full40. but give it a shot first though. for some reason some of the super cheap 1600 batteries have a chip which does not fully work.
[Nexus One Android Development] Breece:
And I did not even buy a "cheap" one but the one temasek suggested from HTC parts...

As I said I tried to change the full40 but nothing happened... oh well..

And the learn cycle will never finish cause the numbers dont change, whatever I try :'(

[edit]

Next time I will simply buy a cheap one from ebay.. 23$ or 10$ for "crap", doesnt really matter ;)

They sold me this battery:

http://cgi.ebay.com/1600mAh-Li-ion-...ccessories&hash=item3f040274fa#ht_3089wt_1139
[Nexus One Android Development] RogerPodacter:
haha i wasn't smashing you saying you're "cheap". that is interesting because my battery looks the same as the one you just linked from ebay. yet some have chips that works, and some that dont. strange.

so yeah if you cant change the full40 for example, then there's not much you can do. try to change the age value, and if that changes then at least you may be able to do a learn cycle, you just wont be able to set the proper capacity, which may not totally matter. does age work?
[Nexus One Android Development] Breece:
Ah no I did not mean to "lash out" at you ;) Its just that I originally wanted to buy from ebay but the "great supplier" htcrepairparts was suggested...

Thats what I got for paying twice the price...

Oh well, cant change the age. And even if I could a learn cycle would never work cause the app does not show any change in voltage so I could never drop to 3201 ;) Interesting enough I will now never know what capacity the battery has...
[Nexus One Android Development] mtw4991:
I would send it back and explain what you are doing with it and need a replacement, fwiw.:cool:
[Nexus One Android Development] Breece:
yeah right...send it back to hongkong ;)
[Nexus One Android Development] RogerPodacter:
i know, no worries;). its so weird cause i bought my 1600 from htcrepairparts as well, shipped from hong kong. i thought because i paid 24 bucks that it was for sure gonna be one of the good ones. apparently they have multiple batches of these that they send out.
[Nexus One Android Development] Breece:
Oh well.. your app is still great but now I am afraid I cant use it anymore :(
[Nexus One Android Development] RogerPodacter:
Oh well. So you're saying that even voltage does not read correctly? Cause you could at least use logging and graphing if needed. But I didn't know the volts was broken too!
[Nexus One Android Development] Breece:
Basically nothing works....
[Nexus One Android Development] Breece:
Well... maybe I should have complained AFTER talking to the customer support.. Sent them an E-mail yesterday and one today (they had a question) and now:

Well.. will see what happens next... And sorry for hijacking this thread, but I feel that this information might be useful for others who are looking for a new battery (for your app) :)
[Nexus One Android Development] theloginwithnoname:
Like the thought, and would have said this would be the most-logical thing to do *if* some of us hadn't already hit learning. However, I think I've proved that whatever the battery learns during this mode is sometimes (or never?) actually remembered or used :(

You'd still get the issues where battery tends-to 0% I've tried 10/20mA and it was never getting reached (from hazy memory, I think I left it trying for around 45 mins - it may have reached eventually but I wasn't overly confident at the time). As I was getting to around 1380mAh, I figured it would eventually reach an "overcharged" value that would not be reliable < 10% anyway.

Taking this forward, I could genericise this a little to say "use code to set the lower and upper voltages and capacities as per the specs". Might be worth stating these somewhere - update your earlier post or PM me the details?

What numbers, thresholds, %ages etc are you reaching with the new one?
[Nexus One Android Development] somline:
Thanks for this info. Didn't saw these documents.

You guys seems to get closer. Congrats.

somline

-creator of Dr.Battery for WebOS-
[Nexus One Android Development] theloginwithnoname:
Duuuuuude! You are *the man* re the work you have done for the Pre!!

Gonna PM you...
[Nexus One Android Development] RogerPodacter:
sorry i got way ahead. after somline sent me the palm driver, and i discoverd our "i2c" driver has the same attribute files, my idea is to add this to our driver code:

static ssize_t show_set_age(struct device *dev,
struct device_attribute *attr, char *buf)
{
int ret;
int age_scalar;

age_scalar=raw[DS2784_REG_AGE_SCALAR];

ret = sprintf(buf, "%d\n", age_scalar);
return ret;
}

static ssize_t store_set_age(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
int age;

sscanf(buf, "%d", &age);

w1_write_8(master, W1_DS2784_WRITE_DATA);
w1_write_8(master, DS2784_REG_AGE_SCALAR);
w1_write_8(master, age);

return count;
}

static DEVICE_ATTR(setage, 0644, show_set_age,
store_set_age);

int device_create_file(struct device *dev, &dev_attr_setage);

that is a very crude "proof of concept" that if successfully worked, we could expand that to be able to set any register, rather than just setting age_scalar like the code i just posted would.

once i saw what palm did, and somline explained that these "special files" they have are nothing more than device attribute files (getfull40, setreg, dumpreg, getage, etc) i researched what exactly device attribute files are, and how easy they are to add. devce_attr are just ways for userspace to interact with low-level driver hardware.

i've been working all weekend on how to add a test file, and the above is what i came up with so far. its crude, has no error checks or anything, but you could give it a shot. if it compiles i would test it on my crap battery. i'm still unclear on a few things and working it out, but if you have the time you could try that.

EDIT: i basically "kanged" that from our i2c driver, but these files exist all over our file tree structure. here's our ic driver:

http://github.com/CyanogenMod/cm-ke....34/arch/arm/mach-msm/board-mahimahi-microp.c

they are so simple in what they do, so i figured why not just add one that calls the write/read function, which is exactly what palm's "setreg" file does.
[Nexus One Android Development] RogerPodacter:
well after being defeated with the learn mode, my only choice left is to perform one with device turned on to see for sure. else i guess we can just say learn mode is broken on our batteries altogether...?

yes it still wouldnt help the lower drop to zero, learn mode would still be required to fix that. but at least this would make the battery "officially" capture the upper range capacity into the percentage meter in a proper fashion. adding that requirement to the code does not really achieve the same thing because the ds2784's parameter conditions are satisfied at <80mA, but our code artificially keeps it charging. updating the actual ds2784 parameters would now adjust itself accordingly and raise the battery full point if that makes sense.

again doing it with the code wouldnt necessarily achieve the same thing i think. just like we saw with the <20mA kernel, the battery jumps to full when it "thinks" its full (based on the ds2784 parameter block values) but our code forced it to continue charging anyway. it'd be nice, but might as well go for broke if we can ever get setreg working.

my new battery is identical to our old one with numbers. no change, except it goes down lower before dying, like <5%.

also, if we see in the data sheet, the percentage meter for our battery uses age scalar in its calculation (forget what page its on). so the reason we jump to 1361 or stop at 1361 is because age scalar is set to 95% which is exactly the point (around 1360 something). i'd like to experiment with age scalar just for the hell of it on my old battery to see what happens...
[Nexus One Android Development] somline:
If you could get dumpreg and setreg to work that would be the best. In my new version of Dr.Battery I only use these two (character device driver) files and make the translation from register values to readable form in the service.

BTW: For some reasons I can't explain openly I ported the service from java to C. The app is now open source. The sources can be found here:

h-t-t-p://git.webos-internals.org/?p=applications/drbattery.git;a=summary

The interesting code for you would probably be in "src/luna_methods.c"
[Nexus One Android Development] RogerPodacter:
unfortunately google did not give us the ability to do what palm did with you guys. so we first have to find a way to add a "setreg" file into our driver code. the above code i posted was an attempt at that, but i just used age_scalar for simplicity to see if it actually worked first. then it could be expanded to set any register, perhaps by calling google's read/write function they already included in their code (w1_ds2784_read / w1_ds2784_write). but i've been spinning my wheels on that one (i'm not good enough, even looking at the palm code).

just just shortcutting it seemed easier to me (i.e. the code i posted above).

do you have any recommendation's on how we could best approach this?

edit: setreg could be as easy as

static ssize_t store_set_reg(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
int reg;
int val;

sscanf(buf, "%d %d", &reg, &val);

w1_write_8(master, W1_DS2784_WRITE_DATA);
w1_write_8(master, reg);
w1_write_8(master, val);

return count;
}

static DEVICE_ATTR(setreg, 0644, NULL,
store_set_reg);

int device_create_file(struct device *dev, &dev_attr_setreg);

that would create a file called "setreg" in our directory, and could echo two integer numbers with a space between them to that file, which would be input into "reg and val" and into the write function.
[Nexus One Android Development] somline:
Sorry I'm no kernel "hacker". If I have time I will read though the 11 pages (sorry didn't have yet). We where just lucky to have this interface.

I assume to find the driver code (w1_ds2784_read / w1_ds2784_write) in this thread? If not please point me to it.
[Nexus One Android Development] somline:
So I've read through all pages. I think you got most of the secrets (some small mistakes). I also looked into one of the drivers. Interesting they use slightly different formulas for some values. Also your sense resistor has a different value.

Very interesting.

BTW: Because of an upcoming major OS update I was afraid about the availability of our interface and was thinking about writing a kernel modul.

As I know now Dr.Battery will still work in the next version. But maybe a kernel module is something you should consider. I don't know if such module will get access to the Battery.
[Nexus One Android Development] RogerPodacter:
Yeah our sense resistor is 15mOhm rather than 20. That's good your interface will still hold. That's ultimately a problem for us, no matter what we have no way to interact with our driver from user space without being rooted and running a custom kernel. No written app we write will be able to call the read/write function so this could never be for the masses, only for rooted users.

I'm setting up a build environment this week cause I'm ready to test out calling the write function and need to compile the edited driver. Sometimes just doing it is the best way to learn;-). Wonder if I can run a Linux install from a usb slave hard drive.
[Nexus One Android Development] somline:
Dr.Battery is also only available for "Homebrew" users. For good reasons. Think of every program has root rights
[Nexus One Android Development] RogerPodacter:
we made a little progress with nonamelogin and myself. my build envir is all setup and compiled a new kernel and was able to set my age_scalar value to something other than 95%. i first set it from 121 to 123, then went right to max and set it to 128 (i.e. 100%). when changed the percentage meter immediately adjusted itself, but the mAh stayed the same. so now my full charge reaches 1444 mAh. of course that's not real usable capacity.

also i pulled voltage terminating and current. voltage is 4.0992 volts and current is 80 mA. i definitely think i want to raise that voltage just a tiny bit in the future.

also i somewhat got the output file working but i need an expert with pointers and data structs to help me define some things, cause its just not sinking in for me!

so i'm able to create a file called "setage" and it shows up in the file structure. when the file is read i have it so it spits out just the address, and all seems to work. but i hit a roadblock trying to output the actual value of the address.

that's about it for now. i think its getting closer to something usable with this thread;).
[Nexus One Android Development] somline:
Congrats, good work. If I can help leave me a message.
[Nexus One Android Development] RogerPodacter:
Thanks:-). I should clarify that the setage file does not yet work to set the value. To do that we hacked the code one of the existing functions as a one time kernel which sets the value. I still need help linking the file to the write/read function. That's where I'm stuck cause of my limited understanding of these damn pointers and data structs!
[Nexus One Android Development] theloginwithnoname:
Next bits we're going to do are Vae (that's Active Empty Voltage), which is the point at which the learning function is activated. At present, on my N1 (and I think RPs) it's too low to regularly hit it.

Once we've got that, we'll be able to calibrate reliably, and once we can calibrate reliably we will know our true capacities and therefore be able to set the (capacity and) age accordingly.

We could possibly manually calibrate now by setting the age - where you see a jump from XmAh to 1353/1358, the X is your likely true capacity; if you set the age as 100 * (true_capacity/1452), you'd likely get reliable battery life and charges - mine's around 1270 so I'd set my age to 87.5

That said I'd feel happier about the battery working out it's "proper" capacity via learning, especially as the jump is done with a default age of 95% at present.

In summary, it's proper kernel hax at the moment but it seems to be working and therefore heading in the right direction.
[Nexus One Android Development] theloginwithnoname:
And I have already given up on doing that in an app as it is *way* beyond my ability/patience point! The logic is fairly trivial but linking to existing code, or kanging the code into a separate app, is the bit that I'm #failing on badly.

I suspect the first solution will be to do it via fastbooting several kernel images; it may never even get to app stage...
[Nexus One Android Development] RogerPodacter:
i cant believe it, i got the setage file to finally output the value. so now i'm trying to add in the ability to write to the file to set the age. :D
[Nexus One Android Development] RogerPodacter:
hot damn, i got it working. we can now read a simple file to see our age scalar, and if you want to change it, just write whatever value and it will change it.

so if you want to set age to 127, just write to the file:

echo 7f > setage

and that's it. i'm gonna work on expanding this so rather than just age, we can just call the full read function itself, which would make it more flexible.
[Nexus One Android Development] ExtraDas:
I bought one off of ebay with exactly the same problem (it's also the seemingly the same battery). Told the seller what the issue was and he agreed to send out a new one without needing the old one back. I'll report back if the new one has a working chip.

The battery I have is good. It last a full day where stock would need a top-off around 5pm (bad signal in my building at work drains it faster then it would normally).

It just seems that some of them have a bad chip. However, I paid $15 for mine which included a wall charger. The battery is always useful as an emergency back-up at that price, regardless of the state of the chip.
[Nexus One Android Development] temasek:
Great! Post your results soon.....
[Nexus One Android Development] Breece:
Well lets hope then its not a problem with the batch... My $22 battery lasts about as long as my old one I think... but if I receive a second one it will be a bargain ;)

I dont think the new one will work though.
[Nexus One Android Development] chowlala:
I sent mine back to hk yo. Lol.
[Nexus One Android Development] Breece:
Oh well.. but that is expensive and I think not worth it ;)
[Nexus One Android Development] thrik:
hey, got my battery working properly. my full40 is currently at 3655. thanks guys!
[Nexus One Android Development] temasek:
Great job! Congrats. :)
[Nexus One Android Development] endiz:
I had to manually adjust the mAh setting too. Is there a reason why the ACR adjustment doesn't work as intended? I'm running CM 6.1
[Nexus One Android Development] temasek:
Possibly due to certain conditions, somehow it missed triggering the auto bump of mAh. Roger and dvgrhl are looking into it.
[Nexus One Android Development] RogerPodacter:
Yeah we think we may change the equation to 0.3volts and <150mAh. I mean really its a race between mAh and volt, how much mAh will drop in the span of 0.3 volts? All we want to do is make sure mAh does not run out and express that in code.

So I think widening the mAh number helps. It's either that, or just make it bump up no matter what. So just set a hard limit of some low mAh number, remove the volt check altogether, so it will bump up everybody no matter what? Would it make sense to go that route?
[Nexus One Android Development] mtw4991:
Probably easier and less confusing/frustrating for noobs to the app. Let me know what you decide and I'll rewrite the instructions for the op.
[Nexus One Android Development] RogerPodacter:
do you guys think there could be any negative result of sampling the battery every few seconds? if anyone read the data sheet, the 7 result registers such as voltage and current, they are updated regardless of whether something calls for readings to those registers or not, so technically each time one is read it puts no extra work on the battery, right?

from the perspective of the OS there is barely any extra work showing up hitting the CPU, so that should be ok. i'm just wonder if extra sampling could drain the battery quicker, or put higher load on it than normal? i'm not sure how i feel about it. what do you guys think?
[Nexus One Android Development] theloginwithnoname:
Make it an option, unselected by default, Rog?
[Nexus One Android Development] RogerPodacter:
oh yeah for sure. i was just curious from theoretical stand point. the sample rate is already working well and interesting to use.

could faster readings pull down the voltage/current for example?
[Nexus One Android Development] SiNJiN76:
How often do we need to calibrate? (Phone is currently in Learning Mode :D) It took like 3 tries to drain my battery to 3201mV.
[Nexus One Android Development] temasek:
Battery age will drop over time. I would say every 3 months is a good figure.
[Nexus One Android Development] mtw4991:
I calibrate mine every 2-3 weeks when I get bored lol, but no need to do it that often unless you start auto - shutting down prior to 0%. If age is set correctly, this shouldn't be an issue very often.

Dang u are fast T!
[Nexus One Android Development] temasek:
I remembered back in the early times I performed learn cycle DAILY !!!! :eek:

LMFAO :D:D:D
[Nexus One Android Development] mtw4991:
:rolleyes:

Me too...I was learning how to learn Rodger's way