+- PINE64 (https://forum.pine64.org)
+-- Forum: PinePhone (https://forum.pine64.org/forumdisplay.php?fid=120)
+--- Forum: PinePhone Accessories (https://forum.pine64.org/forumdisplay.php?fid=123)
+--- Thread: KB: Phone not/barely charging from power supplies when keyboard is not full (/showthread.php?tid=16334)
Pages:
1
2
RE: KB: Phone not/barely charging from power supplies when keyboard is not full - Phalio - 04-07-2022
(04-04-2022, 11:43 AM)estokes Wrote: You can manually control how much current each battery gets. The kb battery has a current limit exposed in sysfs,
/sys/class/power_supply/ip5xxx-charger/constant_charge_current
By default it is 2.3 amps, which seems to be about all the usb interace can muster. If you lower it to something like 1.5amps, then you can raise the limit on the internal battery, and the current will be shifted the the internal battery. If you don't feel like doing this manually I've written a daemon that manages the interaction between the main battery and the kbd battery, available here https://github.com/estokes/pinephone-kbpwrd
Thank you so much, it works!!! Now I can get the phone battery to charge even at high usage with the phone drawing around 1.55A, setting the keyboard input limit to 0.5A in that case still results in a net +0.4A making the percentage go up! Interestingly it looks like the phone current only increases by exactly half the amount the keyboard current decreases, seemingly making it less efficient. For example, decreasing the KB current by 0.8A only increases the PP current by 0.4A:
Code:
| KB limit | PP | KB |
|----------+--------------+--------------|
| KB off | -0.35A | 0A |
| 2.3A | 0.1A | 2.4A |
| 1.5A | 0.5A (+0.4) | 1.6A (-0.8) |
| 0.5A | 1.2A (+0.7) | 0.2A (-1.4) |I see Megi even linked to your project on his website, I must have missed that. Or perhaps it was added after I last visited that specific page. I’ve made some tests using kbpwrd and written down observations, but I suppose I should put that in a GitHub issue. Thanks again for your reply, not knowing how to solve this had been bugging me for weeks!
My issue is solved and this is all I need to know to use the keyboard without issues, so I’ll mark this as solved. But there are some other related open questions I still have that would be nice to get the answers to, so I’ll leave them here just in case anyone can answer them.
1. I came to the conclusion that the PP’s current value seems to be unsigned and the kbpwrd readme confirms this, calling it a kernel bug. Does that mean that it would be possible to read the actual value and this bug just has to be fixed? If so, is it likely to be fixed, has it always been there and is it known what exactly is causing it?
2. Aside from the charge current difference I described in the table above (why does that happen?), when the KB battery charges the PP, the KB’s absolute current value is always a lot greater than the PP’s, for example: KB -1.4A 3.5V, PP +0.6A 4.2V (light load, PP drawing 0.35A). Where is this difference coming from? Or rather, where is it going?
3. Is my assumption correct that, when the PP is being charged, the value of the PP’s current_now is the sum of the amount of power the PP’s parts currently draw, being the (apparently negative) current value of the PP when it’s not getting any external power, plus the amount of power it receives externally? Which would mean that to get the actual current the PP is being supplied with, one has to subtract the (negative) current value it displays when not being supplied with power? For example, with the values in question 2, to get the actual total current value the PP gets, one would have to add the 0.35A the PP displays while not charging to the 0.6A it displays while charging (without changing hardware load), making it get 0.95A in total.
4. There are two input limit values on the PP side: axp20x-usb/input_current_limit and axp20x-battery/constant_charge_current. As per Megi’s FAQ, I’ve changed the former, and kbpwrd’s code seems to also only include that one. By default, the former is set to 0.5A and the latter to 1.2A. Setting the former to greater than 1.2A as suggested (1.5A) and as done by kbpwrd, the latter limit seems to still apply, limiting it to 1.2A. Should that one also be changed? What’s the difference between the two? I guess the former could be the limit of what the pins may transfer and the latter what the PP battery takes. So the PP battery would take at most 1.2A, but the remaining power could still be supplied directly to the PP’s SoC. The PP’s current value seems to cap at around +1.2A, so I guess that would make sense. But in the example where the PP was drawing 1.55A, it displayed a value of (definitely positive) 0.4A. If my assumption from question 3 is correct, that would mean it would get a total of 1.95A from the charging cable through the pins, which is a lot higher than both limit values that were set to 1.5 and 1.2. The same appears to happen when charging from the KB battery.
5. I upgraded to kernel 5.17 from Manjaro testing one or two days after its release, getting KB capacity reporting for the first time. I believe during the first days, the percentage seemed to constantly fluctuate, it’s stable now with frequent very short deviations. But it still seems to be quite random. Plugging the cable in or out makes it change to a completely different percentage. And then plugging it in or out again to yet another value. It also doesn’t seem to increase or decrease linearly. It makes huge jumps, only going down to 50% right before it stops charging for being empty for example. But displaying a low percentage when charging in this state. It definitely doesn’t look that related to the OCV value to me. Since I have no idea how this guessing of its capacity works, I don’t know if this is to be expected and if it for example improves automatically over time, and if so if I could do something to provide optimal conditions for this process and how long it might take.
6. According to Megi’s FAQ, plugging it into a computer USB port is a bad idea. Is that simply because it would supply so little power that it would be useless, or would it actually be bad, like taking more power than it should instead of merely taking the default minimum? My experience with the non-PD 5V 3A supplies might suggest the latter.
RE: KB: Phone not/barely charging from power supplies when keyboard is not full - ragreenburg - 04-14-2022
I absolutely love my keyboard, when it works. I have the same issue where it shows the phone is charging but it is getting so little power from the keyboard (even with the change current allowed) that the phone is discharging. I've shimmed my keyboard twice to help with it but it doesn't work with consistency and the worse part is, if you charge the phone with the keyboard connected you can brick the keyboard. So you can either use the keyboard for a bit, take it off and charge the phone, turn the phone off then attach the keyboard and turn back on (which is ridiculous) or charge the phone with the keyboard on and hope it doesn't get bricked.
I think the fact that Pine64 hasn't really made a public announcement about the massive shortcomings of the keyboard is pretty gross business tactics. The fact that most users have to physically modify the keyboard just to get it working and they've known this since launch and haven't said anything is very disappointing. I purchased a Pro day 1, keyboard day 1 and a UBPorts edition of the regular Pinephone as well as a Pine Time. So I have given Pine64 about as much business as I can because I like what they are about, but this stuff really turns me off of it. Selling a broken product without telling customers is so disappointing.
RE: KB: Phone not/barely charging from power supplies when keyboard is not full - Phalio - 04-16-2022
(04-14-2022, 10:17 AM)ragreenburg Wrote: I absolutely love my keyboard, when it works. I have the same issue where it shows the phone is charging but it is getting so little power from the keyboard (even with the change current allowed) that the phone is discharging. I've shimmed my keyboard twice to help with it but it doesn't work with consistency and the worse part is, if you charge the phone with the keyboard connected you can brick the keyboard. So you can either use the keyboard for a bit, take it off and charge the phone, turn the phone off then attach the keyboard and turn back on (which is ridiculous) or charge the phone with the keyboard on and hope it doesn't get bricked.
I think the fact that Pine64 hasn't really made a public announcement about the massive shortcomings of the keyboard is pretty gross business tactics. The fact that most users have to physically modify the keyboard just to get it working and they've known this since launch and haven't said anything is very disappointing. I purchased a Pro day 1, keyboard day 1 and a UBPorts edition of the regular Pinephone as well as a Pine Time. So I have given Pine64 about as much business as I can because I like what they are about, but this stuff really turns me off of it. Selling a broken product without telling customers is so disappointing.
I agree that there are many issues with the keyboard and they should be made very clear on the store page so that every customer knows what not to do under any circumstance and that they would have to apply certain workarounds and/or wait for software support to improve. I would consider the current version more of an Explorer Edition, but I believe most issues can/will be solved even with this version. Except for the power supply in phone issue.
Charging works perfectly fine for me with adjusted limits. I believe they reset each time you plug in a cable or reboot, are you sure you have them set correctly for whatever state you are currently in? You can try the aforementioned kbpwrd, though I’ve been experiencing multiple bugs using it or my own attempt at automated limits that make them mostly not work for me, but it does seem to work for kbpwrd’s developer. Or as I’ve done before, make a udev power rule for a permanent set of limits if dynamic limits don’t work. But that will eventually be an issue of the past as Megi has announced automatic charging management for kernel 5.17.2 which I suppose will work even for me. Of course this means that one can’t have this new kernel driver and the userspace driver with custom keymaps at the same time, but fortunately Megi now also announced custom keymaps with the kernel driver. I hope I’ll be able to recreate the same keymap there I use now. I can’t live without my own custom keyboard layouts, especially with the limited amount of keys on this one.
Regarding pin connection issues, have you tried the method I described here? It supposedly works reliably, I’ll record how I do it and report back on if it works again when I decide to give Sxmo a try and take the phone out.
(Written on my PP+KB away from home. Apparently this website has a minimum width that is larger than the PP’s screen in landscape mode at 200% scaling.)