Increasing the maximum power draw

[dsimic]

Hello,

I've been poking around PineBook Pro for some time, and one of the issues is the battery charging current, which is way too low at slightly under 3 A at 5 V.  It even gets ridiculous, e.g. the battery pretty much never charges back to 100% once you try to recharge it from an empty state while still using the PBP.  Not to mention that the battery discharges when running higher CPU loads, which is both ridiculous and very bad for the battery life.

So, I took some time to investigate the PBP's wiring diagrams, trying to isolate the culprit.  In a few words, the good news is that everything points into that increasing the max. battery charge current should be a relatively easy mod.  It could even be incorporated into the next revision of the main PCB.  The bad news is that a mod like that must be discussed first.

The PBP's battery can easily take up around 5A during the constant-current part of the charge cycle, which is according to its data sheet.  The PBP's battery charger IC is configured to think that the system current is always zero, which means that only the max. charge current needs to be tweaked; again, this is according to its data sheet, page 17 in particular.  The PBP wiring diagram, page 11 in particular, shows the way the BQ24171 IC is configured, as already described.

In a few words, increasing the battery charging current to 4A would be pretty simple; all that's required is to replace the R44, R45, R47 and R48 SMD resistors, so their values configure the BQ24171 IC to take 4A from the charger (IACSET) and output 4A (ISET) as the battery fast-charge current.  Of course, any chargers providing less than 3A could not be used any more, which would render the factory-provided barrel-type charger useless; however, I don't think anyone would complain.

I cannot see anything that would prevent this mod from being successful.  The PCB traces designed for 3A can easily handle 4A, which isn't a huge increase of the current.  Maybe the F1 fuse would also need to be replaced, but I don't know that for sure because its max. current isn't available from the wiring diagram.

Thoughts?

[forthwith]

According to the schematics, the battery connector is a JSQ1201WR-7P, but there doesn't seem to be a datasheet I can locate on google. What is it's maximum power rating? It's already got 3 hots and ground pairs, so each one carries one amp apiece. It's pretty small, so that may be the weak link in the circuit.

A better alternative may be to increase the power output but leave the battery charging current as is. This way, under full system load the battery should still be able to charge, or at least not discharge.

[Dendrocalamus64]

Like I've said before, I typically keep the backlight set to about 3 or 4 notches above zero. With a low-opacity, high-contrast theme, that's easily usable, and it lets the battery quickly charge to 100% every time. CPU/GPU load high enough to drain the battery or eat 100% of the current is actually quite rare.

My suspicion is that the hardware designers were working in dim rooms and simply didn't anticipate people using grey-on-black themes next to wide open windows on a midsummer day. It worked for them.

As the battery monitor is able to get a detailed reading of the current charge status, I'm more interested in being able to set the charge endpoint to less than 100%, so as not to be death-charging the battery. It typically drops to around 94% overnight from self-discharge, depending on the temperature, then immediately gets topped up to 100% during use. This is the worst sort of charge pattern for battery longevity, and happens every day despite the fact that I'm not even using the battery.

I'll have to try this when I'm on a newer kernel.

[dsimic]

According to the schematics, the battery connector is a JSQ1201WR-7P, but there doesn't seem to be a datasheet I can locate on google. What is it's maximum power rating? It's already got 3 hots and ground pairs, so each one carries one amp apiece. It's pretty small, so that may be the weak link in the circuit.

A better alternative may be to increase the power output but leave the battery charging current as is. This way, under full system load the battery should still be able to charge, or at least not discharge.

That's a good point regarding the battery connector.  The battery can easily take 5 A, according to its datasheet, but it should be investigated further about the power rating of the battery connector.

I totally agree that not changing the battery charging current would be a much better way to go, but that seems to be impossible, unfortunately.  I'll investigate it further, but the overall design of the PineBook Pro seems to be taking all of its power from the battery, while the DC inputs are there only to charge the battery.  Quite frankly, such a design doesn't make much sense for a laptop, but everything points into that.

As the battery monitor is able to get a detailed reading of the current charge status, I'm more interested in being able to set the charge endpoint to less than 100%, so as not to be death-charging the battery.  It typically drops to around 94% overnight from self-discharge, depending on the temperature, then immediately gets topped up to 100% during use.  This is the worst sort of charge pattern for battery longevity, and happens every day despite the fact that I'm not even using the battery.

I'll have to try this when I'm on a newer kernel.

I agree, that's really bad for the battery longevity.

AFAIK, defining the charge thresholds isn't possible on a PineBook Pro (PBP).  IBM/Lenovo ThinkPads have built-in battery charge controllers that allow such charge (and discharge) thresholds to be defined, but the PBP's charge controller has no such functionality.

---

There are some more things to consider...

USB Power Delivery 2.0 and 3.0 specifications allow only up to 3 A when operating at 5 V.  As a result, the bad news is that even with hardware modifications there could be no improvements when using a USB Type-C charger, which is really sad.  The good news is that the PBP's charging logic can already act differently (i.e., use different amounts of input power) when using the barrel port and when using a USB Type-C charger, which could be modified to limit the input current to 3 A when a USB Type-C charger is used.

Quite frankly, the charging of the PineBook Pro could have been made much better.  Some improvements shoud be made to the overall design, IMHO.

[dsimic]

Good news!  In the meantime, I've switched from the factory-installed Debian to Manjaro ARM, and one of the results is that the laptop battery can now actually be charged when the laptop is connected to the factory charger and subjected to light use, i.e., low CPU load, WiFi turned off, Bluetooth off, etc.  I always had the same Gigabit Ethernet USB 3.0 dongle connected.  Under the same conditions, the factory-installed Debian made the same laptop unusable by ending up with completely discharged battery and the laptop abruptly turned off.

It isn't Debian's fault by any means, but there's no doubt that the Rockchip-provided Linux kernel that's shipped with Debian has some weirdness in it (i.e., "just get the SoC out the door" type of code) that caused unnecessarily high power consumption.  The Linux kernel shipped with Manjaro shows how the same thing can be done properly.  Good job, Manjaro!

As an example, the laptop running Manjaro can actually recharge the battery from about 73% to about 92% while under the above-described light load.  That was by no means possible with the factory-installed Debian, the battery would pretty much never recharge unless the same laptop was completely turned off.

As another example, the bottom cover of the laptop is significantly less warm when running Manjaro, under the same load.

However, running a "make -j6" inside the Linux kernel source tree causes the battery to drain rapidly, despite the laptop being connected to the factory charger.  That clearly shows that the PineBook Pro's charging subsystem is unable to provide enough power to support 100% CPU load, which is not good.

I am going to continue my investigation about possible hardware modifications that would improve the charging subsystem, and I will report my findings back here.

[xyzzy]

Other stuff would need to change to get >3A from the battery charger. The output inductor, L1, is 3.3 µH while for 4A the typical value would be 2.2 µH. Also likely changes to the input and output caps. The MOSFET, U40, would need to be able to handle the current too.

There's also the thermal limits of the charger controller, the MOSFET, other current switching FETs, etc. Just because the absolute limit in the datasheet is high enough doesn't mean the PCB layout is adequate to keep the thermal resistance low enough to reach that limit.

Anyway, a new PCB rev that will draw more than 3A from the DC barrel connector isn't really viable, since it wouldn't be possible to connect any of the existing power adapters without overloading them. It's not possible to just just "draw less" from the 3A adapter. The charger will try to draw more and the adapter will be unable to keep at 5V and drop voltage, or totally lose regulation, or trip a thermal fuse, or (I see the pine supplied adapter is not UL-listed!) catch fire.

I think what could be done is the program the FUSB302 to allow 5V, 9V, or 12V from the type-c connector with USB-PD. The battery charger can handle an input up to 17V. The input side current wouldn't need to be any higher. If I understand the charge circuit right, VCC_SYSIN will be regulated to the battery charging voltage, i.e. about 2V-4.4V, by the switching regulator in the BQ24171. So nothing past the input side of the BQ24171 will see a higher voltage if VCC_5VIN is raised up to 12V. That means none of the other regulators or the PMIC need to worry about >5V input. Only the charge LED will see it. Probably fine, it should be possible to chose a current limit resistor so that 5V is visible and 12V doesn't burn it out. And the circuits, which I don't totally follow, to prevent shorting between VCC_DCIN and VBUS_TYPEC would need to be able to deal with it.

[dsimic]

Anyway, a new PCB rev that will draw more than 3A from the DC barrel connector isn't really viable, since it wouldn't be possible to connect any of the existing power adapters without overloading them.  It's not possible to just just "draw less" from the 3A adapter.  The charger will try to draw more and the adapter will be unable to keep at 5V and drop voltage, or totally lose regulation, or trip a thermal fuse, or (I see the pine supplied adapter is not UL-listed!) catch fire.

I think what could be done is the program the FUSB302 to allow 5V, 9V, or 12V from the type-c connector with USB-PD.  The battery charger can handle an input up to 17V.  The input side current wouldn't need to be any higher.  If I understand the charge circuit right, VCC_SYSIN will be regulated to the battery charging voltage, i.e. about 2V-4.4V, by the switching regulator in the BQ24171.  So nothing past the input side of the BQ24171 will see a higher voltage if VCC_5VIN is raised up to 12V.  That means none of the other regulators or the PMIC need to worry about >5V input.  Only the charge LED will see it.  Probably fine, it should be possible to chose a current limit resistor so that 5V is visible and 12V doesn't burn it out.  And the circuits, which I don't totally follow, to prevent shorting between VCC_DCIN and VBUS_TYPEC would need to be able to deal with it.

You're right, it would be pretty much impossible to reliably determine the type ("standard" or "high current") of the charger connected to the barrel connector.  We'd need a separate signal/wire for the type identification, which is simply not an option.

Altering the built-in Type-C PD controller is a really great idea!  I'll have a detailed look into it and report back here.  There might be some other minor issues related to the increased voltage received from a USB PD charger; for example, it might be required to also modify the circuitry that adjusts the current configuration resistors for the battery charging IC when a PD charger is connected vs. when using the barrel connector.

[dsimic]

Well, the plot thickens, as it might have been expected.  In a few words, improvements to the SoC cooling will have to be made in parallel to the PineBook Pro's power circuitry improvements.  Below is a more detailed explanation.

Once the CPU cores are all kept at 100% utilization for an extended period of time (20+ minutes), the heat soak from the SoC affects the battery charging IC (i.e., TI BQ24171), which goes into thermal shutdown.  As a result, battery becomes rapidly discharged because the loaded SoC uses a lot of power and there's atually no charging at the same time.  Turning the laptop upside-down and providing additional coolling to the back of the laptop turns the previously mentioned 20 minutes into about an hour, but the BQ24171's inevitable thermal shutdown happens anyway.

I'm already evaluating a few possible solutions, including gluing a thin copper sheet to the inside of the back cover, using thermal epoxy.  The back cover seems not to conduct heat very well, which causes a hot spot where the SoC touches it.  Another possible solution being evaluated is gluing flat copper heatpipes to the inside of the back cover.  In addition, gluing a small heatsink to the BQ24171 IC should help a bit.

[dsimic]

Here's an update, and I'm also asking for someone to verify one of the conclusions, please see the text in bold below.

As far as I can see, the primary reason for the red LED to start blinking is still the overheating of the battery charging IC, BQ24171; the datasheet describes the STAT output and the status LED on pages 5, 17, 18, 23 and 24.  The conditions that cause the battery charging to be suspended because of the battery temperature, and the conditions required to enable or disable the battery charging in general, are described on page 9 and page 18 of the BQ24171 datasheet, respectively.

Another reason for the red LED to start blinking could be that the battery starts to overheat under load, but that doesn't seem plausibe to me, especially because I've never felt that the part of the back cover above the battery becomes even lukewarm.

Here's what the above-described conclusion has been based on:

• As configured in the PineBook Pro, the BQ24171 is nowhere near its charging current limit, which can go up to 4 A, but the battery charging current is configured (using the BQ24171's ISET pin) to stay at or below 3.3 * (20 / (20 + 100)) / 0.2 = 2.6 A.  As a result, the BQ24171 isn't running close to its limits.
  
• The PineBook Pro always takes power from the battery, instead of directly from any of the two power inputs, so no overcurrent protection in the BQ24171 should be taking place, unless the battery is faulty, of course.  This pretty much follows the reference design available on page 28 of the BQ24171 datasheet.  In other words, the BQ24171 is configured to just keep topping up the battery, and the battery provides additional power even when a charger is plugged into the laptop.
  
• When the red LED starts blinking, it doesn't return back to solid red until the cooling of the underside of the laptop is improved, nine times out of ten.
  

As an unfortunate result of the first two bullet points, the most power that the PineBook Pro can effectively consume from any of its power inputs, without reaching into discharging the battery, is around 11.4 W (2.6 A at around 2.1 / (100 / (107 + 100)) = 4.37 V, which is the battery voltage when fully charged), despite the fact that the barrel port, for example, can provide 3 A at 5 V, which equals to 15 W.  Could anyone, please, use the BQ24171 datasheet and page 11 of the PineBook Pro schematic to verify this and correct me if I'm wrong?

What really s*cks is that the BQ24171 pretty much cannot be made visible to the software, and its configuration is performed using resistors.   This also means that it's impossible to check the current temperature of the battery in software.  The only way to communicate with it is to observe the red LED; however, the pin that drives the status LED could be connected to a GPIO line of the RK3399.

Edit: More precisely, the above-stated limit of 11.4 W should be the limit for what the BQ24171 can put into the battery, while the total power draw from one of the two power inputs should be a little higher, due to the losses inside the BQ24171.

[megous]

dsimic: I've bought and checked with a better 5A cable. Now the voltage at the Type-C connector is 4.9V at max load, so the max PBP can draw from DC/Type-C VBUS is 11.34W (that's what I measured).

So that's the same as your theoretical 11.4W limit.