CSD Tool assumes there are no batteries with capacity higher than original

@simo so if I buy a Polarcell battery and continue my habit of charging to 85% I should be allright?

By this chart comparison, it seems Jolla might report the charging level exactly as same between 7% - 85%, and accurate enough even between 3% - 97%. Should be all right yes, but I just can't be 100% sure before data from Jolla.

@simo As a logical question: if the Jolla charges the battery with its built in parameters and comes to an "official" end at 100% with slow flashing led, shouldn't that be a guarantee that it's NOT overcharging? If the battery itself would stop the charging by using its safety circuit, Jolla should show less than 100% and shouldn't stop? So, if I see the led flashing in the morning, I can be sure not to overcharge the battery, can't I? (I'm using the polarcell continuously since the first post here and always do an overnight charge.)

@Robomike Your longer term testing is promising for the safety, great job there, but without more information about the official battery I really can't answer to you... Jolla's 100% is set to a point where Jolla official battery reaches 2100mAh, so it's not a quarantee for any other batteries (until proven 100% compatible, which I'm somehow trying to reach...) By the way, you can get some more battery information during different stages of charging via terminal, using command upower --monitor-detail in your testing. And thanks for joining us here :)

@simo Thanks for your answer. But, from a technical viewpoint, for the device it's impossible to know how much energy is stored, unless the battery wasn't completely empty once - which is very dangerous for Li-Ion-batteries and should be avoided in any case. Theoretically you may replace batteries with different charge state anytime, and the device shouldn't kill itself by overcharging. The only parameters the device can see are current, voltage and temperature. The end-of-charge voltage is fixed and has nothing to do with the nominal (imprinted) voltage. The device _may_ use the coded curve (the img above) to make a guess about the charging state, and if it's well programmed, it may learn something about the battery's condition by comparing the voltage/current-position with some saved values. But it will never know the exact charge. (Btw: the curve plot in your initial answer uses an odd ordinate identifier. It should be "voltage", not "current". We should try to minimize confusion :) )

The "capacity" of 102.21% (>100) is most probably the reason that makes the test fails. But indeed only because the app thinks (in a hard-coded way) that 100% <=> Official Jolla battery capacity. By the way, isn't the CSD tool available a FOSS? Isn't it capable of running on community port on different devices? Someone should have noticed this bug already I think :X (as this tool would be great to see if you drivers work while you port the system to a new target)

@Elioty It reaches a capacity of 102.21% cause it calculates with the hardcoded value "Design maximum" instead of the one provided by the battery itself "Maximum".

According to https://wiki.merproject.org/wiki/SailfishOSS it's not.

//EDIT: Also it's not the capacity value failing. When "Value" falls below "Design Capacity" (caused by discharging the battery) the test passes while "Capacity" still shows 102.21%.

//EDIT2: @simo Still it shouldn't fail for non technical reasons. "Value" > "Design maximum" isn't technical. We need an answer from a sailor here.

//EDIT3: Even if for some weird reason the statement from EDIT2 would be technical the test should fail if the reported "Maximum" > "Design maximum" but that's not the case. So no matter how you look at it; there's a bug. ;)

Capacity is (and should be) calculated from the Design maximum value, which is set into the system by Jolla, no settings offered to change it (hence a feature: Jolla is a phone for 7.98Wh batteries (3.8V*2.100Ah) by design)

There is a workaround to manually change this value using dbus command, writing a new DesignFull value by what's expected from the battery, but before using such workaround I'd wait for information if the battery is safe to use in the first place.

But it's not about "Capacity" but "Value" (see also latest screenshot).

So either this is a bug or you just found the real root and this is just a symphtom. Bug no matter how you look at it... ;)

You didn't get it. Battery is seen as overcharged if the Value (current charge) > Design maximum (max accepted charge). Test SHOULD fail in this case.

So the bug is that the phone overcharges the battery? But why does the lockscreen show 100% charged then? Why didn't did I get a message that the battery is fully charged earlier? Did you just find 3 bugs in a row?

Those are the correct and important questions.

• (1) Three possibilities: Actual overcharging / wrong voltage (3.886V instead of 3.8V) / more capacity than what manufacturer has stated in the battery (2147mAh)
• (2) Lockscreen value is propably set too max 100%, and will show that while the charge is between 100-102
• (3) see the first answer

2 is out of question, I watched the locksckreen. Test passes again when lockscreen shows around 97% charged. For 1 and 3 have a look at the screenshots again (esp. the battery provided / abstracted values "Maximum" / "Capacity"). I'm off repeating myself over and over again for you...

Why do we even disagree... Test should pass with 97% charge in your case. Capacity has nothing to do with the test result. For (2) you're probably right, the charge level is calculated from the Maximum instead of Maximum design (in which case your test should fail with 98% and 99% on the lock screen)

We disagree cause either the test should pass cause "the current charged capacity (Value) is in reported capacity range (Maximum) or "the reported capacity range is higher than the designed capacity" should trigger the test to fail. The current "the current charged capacity is in reported capacity but higher than designed (artificial) maximum so we fail" behaviour just doesn't make sense.

Thanks for the explanation, but in what case this test should fail in your opinion? I see the possible overcharging, wrong voltage or wrong capacity all as good reasons for failure. By the way, do you have a meter to check the actual voltage of a full battery?

I already told: Test should fail for technical reasons. Voltage is checked by the phone itself, battery itself tells it has higher capacity ("Maximum") but that isn't why the test fails. This was my last reply to you as you keep me talking in circles. It even seems like you keep refusing looking at provided screenshots.

Your battery is most probably overcharged due to too high nominal voltage, reducing the lifespan of it with 2-4 months. 2.2% overcharge doesn't sound too bad, but as a kind advice I suggest you don't let your Jolla to charge it full. It's designed to carry 2100mAh, and your Jolla charges is over that. You reach about 2100mAh when your lockscreen shows 97%.

However you see the fail in the test, that test is supposed to warn you if there's something wrong, and that's what it does. We can leave ourselves disagreeing on this, no problem.

So you suggest to me to open 3 new bug reports:

1. Voltage test in CSD Tool passes when it should fail.

2. CSD Tool assumes max Wh instead of reading it from battery EEPROM.

3. Phone knows it overcharges battery but does it none the less, risking to explode.

See, as long as you keep assuming instead of relying on data and keep arguing as if you would be talking in the name of sailors there's no more need to talk to you, so please stop.

//EDIT: Did a bit of research: The PolarCell battery is secured against overcharging.

@V10later:

1. Voltage seems ok. If it is between min and max why should it fail?

2. Unfortunately lots of charging chips or batteries have no such idea about max battery capacity (or lack an EEPROM completely) or other battery parameters. They need to be fed in separately with some table containing battery data. Luckily most batteries have built-in overcharge/overcurrent protections.

3. Most charging chips handle end of charge by using a current threshold over a certain amount of time at a certain known voltage. They don't take into account capacity as that value is close to meaningless for charging (especially over a long period of time due to battery aging etc)

@V10lator I actually tried to relay on data, asking you about the max voltage for fully charged battery, measured with a meter, in a meaning to compare it with Jolla battery max voltage. My latest comment is really an assumption without that info, sorry for that.

@simo If I would have a meter you would have data. Sorry.

To add some other data:

• With every charge the capacity shrinks a bit (currently 100.98%). I guess that's some kind of calibration and not aging?

• I inserted the original battery again and it also showed a capacity of >100% (this was done just for testing, am using the PolarCell now).

• The PolarCell deserves it's name: It's cooler than original not only while charging.

Thanks for the additionaol data, let me share some more assumptions based on those :)

• Capacity gets a bit lower on each charge, and that might be even faster if the battery has been overcharged (or discharged close to 0mAh) previously. Smartphones shut down a long before 0mAh is reached.
• CSD tool, afaik, calculates capacity from several previous charges, so the reading on your Jolla battery might be affected by earier readings of PolarCell battery
• Cooler sounds very promising, both for the safety and for the lifespan, but the readings might be uncomparable because of different age of the batteries.

Philippe De Swert also mentioned tables, so if CSD uses those written for Jolla battery, all readings based on those might vary on "compatible" batteries making them unreliable. It tells us that the PowerCell battery is somehow different, for example reaching it's full capacity with lower or higher current, while Jolla Phone stops the charging based on Jolla battery currents. But this enables both overcharging and undercharging situations, so it leaves me only guessing... However, any dangerous overcharging should be prevented by the safety circuit. A meter, or a charging chart of both batteries would be needed to ensure the compatibility.

Thanks for interpreting and sorry for my tone lately, guess I wasn't really myself.

For 1 and 2: Do you know where it stores the data? It might be a good idea to whipe the cache when switching batteries.

3: The original battery is just a few weeks old. You could feel it heating up while charging with bare hands since day 0. So I think the PolarCell is really better here (+0.1°C while charging according to sensor, no heat detectable with bare hands). :) On the other side I question the sensors of both batteries a bit as readings right after boot differ by ~7°C.

Will ask a friend for a meter next days. Do you have some infos about "charging chart" in the meantime?

BTW: Yes, I purchased the battery just for testing and not cause I needed a new.

@Violator, @simo:

1. The data is stored in the charging chip (the specific term used is a coulomb counter) So getting weird values after switching batteries of a different type will make it show weird values (like the overcharge that was mentioned when you put back the Jolla battery) as the reference data and calculations do not match anymore with what the coulomb counter reports. Not to mention the mix-up with the current measurement due to different resistive value (and incorrect correction as that resistive value changes with temperature).
2. Since the battery curve might be different the charging current and related heating would be different too. And yes sensors will report different values due to hw difference (usually resistance as a thermistor is used)

Battery data is in the kernel: arch/arm/mach-msm/bms-batterydata-sbj.c, the driver is too in drivers/power/pm8921* . CSD reads the data from sysfs btw. I hope now you will all learn that battery/charging is not as simple as you think.

Oh and I forgot to mention how much fun this is to try to understand and correct when you don't have access to the specs (and ofc every charging chip/battery is different).

Thanks @Philippe, great details :) How is the saved data handled when changing a Jolla battery to a new Jolla battery then? For how long the old battery data mixes the results?

@V10lator for charts, search images for "li-ion charging profile". I'm quite interested on comparable charts, happy if you're testing

@simo : It keeps using the same saved data (as the same/similar battety is expected to be inserted). It can be cleared by leaving the battery disconnected for over 10min I believe (internal cap needs to run out of juice). But the driver still uses the data like sense resistor, battery curve etc for the original battery, so things will still be "wrong" with a different battery.

perfect... 10 mins and a new Jolla battery should start to collect fresh data if so. But let's see if you get a Polarcell chart calculated @V10lator - here's one for Jolla battery by kernel values:

@simo: Sounds like you misunderstood the part where I say where it will still use non-matching values and get things "wrong. It will not collect fresh data for a chart. It will just clear the coulomb counter info. So it will count the power that goes in and out slightly differently, hopefully getting rid of the over 100% values for the original battery at least.

@spacebarnick ;) I think I got you right, CSD will be showing wrong data for a different type of battery even after coulomb counter reset (but if it does that on new Jolla battery after reset, that would be a bug).

Anyways, that's why the measurements for any possibly compatible battery must be taken with an external meter, or get the data from the manufacturers of those.

Phone discharged completely yesterday, so I took the battery out till I was able to recharge. Now, after a full recharge, CSD Tool shows a higher capacity again (was 100.98%, now it's 101.23%).

If I undefstand your last discussion correctly it doesn't make sense to collect a chart from kernel values now?

Will take battery out again now, wait a bit and then reinsert original battery. Let's see what happens...

//EDIT: Result after around 15 minutes: CSD Tool shows exactly 101.23% for the original battery, too. So it looks like nothing has been resetted.

//EDIT²: Fun fact: While the PolarCell battery feels heavier than original with bare hand measuring it's actually 0.2g lighter (37.4g vs. 37.6g).

//EDIT³: As taking battery out for > 10 minutes seems unreliably to reset counter does anyone know a IOCTL or something along the lines for that?

kernel values won't change (unless changed by a coder), so yep, no idea to collect another chart from there. Those are for original Jolla battery only, and can be used in comparison with another chart. A compatible battery would have a similar curve regarding currents in certain temperatures.

Too bad there's no change after reset, capacity calculation seem like a mess to me now...It sounds like changing an aged Jolla battery to another original, brand new one might not give correct values in that case?

Alright, thanks. So back to getting a multi...

Yea, it really looks like a mess. Source codes are way to big for me to interpret but that's why we really need some way to reset counter from userspace (IOCTL). Coding an app from there on would be a no-brainer.

@V10lator: Good luck with that! If the chip actually supports something like that it might be possible. But who knows? And yes the source code is a horrible mess, virtually impossible to interpret without specs. Good thing Qualcomm is handing them out easily... Oh no right, you need to be a privileged customer (several million+ chips) and pay several thousands of $$$$ to be maybe eligible..

Well, as the kernel is able to write the data it should be possible to whipe it, too. A good driver design would expose that functionality to userspace. At least in theory based on my limited knowledge, only codes know but we can't read so, well...

I downloaded HTC Desire 310 kernel sources to be able to compare. Seems like a corrupted download:

tar xzf ~/Downloads/Desire310_1.00.401.4.tar.gz
tar: Springe zum nächsten Kopfteil.
tar: Beende mit Fehlerstatus aufgrund vorheriger Fehler

(free translation: "tar: Jumping to next header part." - "tar: Exiting with error state caused by previous error")

Couldn't find anything comparable to bms-batterydata-*.c and that's at the driver dir: http://picload.org/image/ipiarwg/htc310-kernel-power.png - Any hint what to compare with what? Other than that I don't think re-downloading the kernel package is usefull - won't do that unless there's a good reason cause the download server was painfull slow.

//EDIT: BTW: Did anyone compare original Jolla battery with original HTC Desire 310 battery yet?

@Violator: The kernel driver afaik uses the battery curve and other battery data to make sense of the data sent by the chip. It almost writes nothing to the chip. From a quick look mostly initialization data. Anyhow without specs this is a guessing game.

//EDIT: Also I don't know the HTC desire 310, but it could have a different charging chip...

To make things a bit easier, and just for the basic safety factors, comparing Jolla battery and Powercell battery discharge (for example constant 200mA) with external meter and drawing two charts, marking up currents every few minutes, starting from full until both batteries reach 3.4V. If similar, that's promising for safety. Measurement should be repeated in several temperatures.

As I still don't have access to a multi I wrote to the PolarCell guys (which is Wannsee-Electronic). They replied:

Hallo Thomas,

da wir selbst der Markeninhaber von PolarCell sind, sind wir auch direkt die richtige Ansprechadresse... : )

Laut den Aussagen anderer Kunden soll es im Jolla 1 keine Probleme geben. Wenn Sie es wünschen können wir Ihnen gerne ein entsprechendes Testprotokoll des Akkus anfertigen, eventuell hilft dies ja weiter. Könnten Sie mir zur Klärung vorab die Daten des entsprechenden Originalakkus mitteilen, Nennspannung, Nennkapazität, Ladeschlussspannung (müsste alles auf dem Akku stehen).

Danke & Grüße

Translation:

Hello Thomas,

as we own the brand PolarCell we're also the right ones to contact... : )

According to some customers there shouldn't be any problems with Jolla 1. If you want to we could send you a test protocol for the battery, maybe it helps.
Could you send me the data of the original battery, voltage, capacity, charging end voltage (should all be written on the battery).

Thanks & greetings

Will reply them now with data from original battery + asking for the protocol. @simo As I don't see charging end voltage, just max charging voltage (is it the same?) I'll attach your chart to my reply, too. Hope that's okay.

@V10lator they have no use for that chart, just the basics from the battery (3.8V / 2100mAh / 4.35V). However the last number, for 100% charge, is written into kernel as: 4322 4323 4320 4314 4307 (mV) depending on the temperature (from lowest to highest). The actual full charge current should be metered, and it might be 4.35V - as the kernel values might be fixed for certain charging chip / current meter in use

Thumbs up for Wannsee for being so helpful. I guess they also noticed the increase in HTC Desire 310 Polarcell batteries. Looking at their eBay sales, they were 9 pieces in July and above 30 in the first 8 days of August, that is since when we found out that they are good for use in the Jolla phone.

Yes, hope we get some helpful data from there :) How about Jolla battery manufacturer, is the datasheet allowed to be shared by Jolla or is it under some NDA?

Reply from Wannsee-Electronics:

Hallo Thomas,

bitte entschuldigen Sie meine späte Rückmeldung, leider waren unsere Testgeräte noch mit anderen Test belegt. Im Anhang finden Sie das Testprotokoll zu diesem Akku inkl. Testkurven. Ich hoffe, dass dies etwas weiter helfen kann.

Grüße

Translation:

Hello Thomas,

please excuse my late reply, unfortunately our test systems where busy. Attached you'll find the test protocol for the battery incl. test curves. I hope this helps a bit.

Greetings

Here are the attached files: https://www.dropbox.com/sh/mx84uhbrtd58fbs/AADaOy-LHxfS5orZARzFi6_la?dl=0 - Would be great if somebody could convert them to pdf as I can't open them.