First off, I want to clarify that I'm talking about battery lifespan as in how long the battery keeps holding a charge before it wears out and becomes unusable, not how long the device can run between recharges. For the purposes of this post, I'll refer to the former thing as "battery lifespan" and the latter thing as "runtime".

There's a problem with lithium-ion batteries nowadays, and it's that we've all been lied to about how long they last. They don't actually inherently wear out after only one or two years of service - they just do that when they've been pushed beyond their reasonable limits for charge capacity to squeeze every last possible second of runtime out of the thinnest possible battery. Remember when they used to say that laptop batteries lasted around ten years? Well, they've only grown better since then, not worse; we only get such dramatically worse cell lifespans nowadays because most consumer electronics vendors like advertising big numbers for runtime on a charge and making the thinnest devices they can manage (and they also like selling you a new phone every year). If we only charged our batteries to 80% of their rated capacity and limited discharge to 20% of their minimum charge level, they'd last several times longer, but naturally, the state of hardware and software is not designed to make it easy to do this. While turning off your phone before it reaches 20% may be simple enough, nobody likes babysitting a charging phone to catch it when it passes 80% and take it off the charger - you really need a way to make it cut itself off before then.

The Pinephone does pretty well here, I understand. Its fancy PMIC does let you program in your own charge parameters, and the Linux sysfs interface makes this easy to do from userspace. But it's not the Pinephone that I'm worried about now; it's the Pinebook Pro (and maybe the regular Pinebook; I haven't inspected it as closely).

The Pinebook Pro has a very large, expensive battery in it, and plenty of runtime to spare, which is why I find it very disappointing that it has a hard-wired charge controller that sets the charger cut-off voltage with a pair of resistors - to, if I recall the schematics correctly, around 4.35 volts, which is eye-wateringly high (in my book, 4.1 volts would be much more appropriate, maybe 4.2 at most). Vendors may claim that modern cells are "designed for" higher float voltages, but they're also "designed for" much shorter lifespans than they used to be. The bottom line is that they just do last longer if you treat them better, which is why I think Pine64's designers should really consider picking more conservative charging parameters for these things.

Setting charge thresholds in immutable hardware, as was done with the Pinebook Pro, isn't unacceptable (although a smart PMIC with user-settable values is definitely better), but I think we deserve to have those parameters set to values which prioritize a bit more longevity over out-of-the-box capacity. I mean, it's not Pine64's goal to sell everyone a new Pinebook Pro battery every other year, right? With the way the supply situation tends to be, I would think this idea should practically strike fear into the hearts of a lot of us. I've tried to be careful with my unit's battery, but it's already showing its age only a couple of years later, and holds noticeably less charge than it used to. It doesn't have to be like this. If I had a way to limit charging to 80% of the design capacity, I'd still get 8 hours of runtime on a charge, but would get potentially twice or three times the battery lifespan compared to now. Doesn't that sound like a worthy tradeoff?

If you think I sound like some kind of conspiracy theorist, remember that plenty of enterprise-grade laptops offer battery charge parameter adjustment in their firmware for specifically this reason. The Toughbook I'm writing this post on has a "high-temperature environment" option that limits charging to 80% of baseline capacity - ostensibly to keep the battery from wearing out faster in hot climates, but I have it turned on all the time to keep it from wearing out too fast in general. The Dell XPS series has a way to set thresholds to whatever you want them to be in the setup utility, and Thinkpads let you configure them directly from the OS with SMAPI and such.

My two overall points here are these:
1. I want to see future Pine64 devices prioritize the inclusion of some sort of programmable PMIC/battery controller whose charge profile can be configured. In addition, I think that these chips should be given relatively conservative default charge parameters, so that the users who need to change them are the users who want more runtime at the expense of longevity, and not the users who want their devices to last.
2. I think that it would be worthwhile to make a small revision to current Pine64 devices, namely the Pinebook Pro, to reduce maximum charge voltage in future production models. I won't claim to be experienced here, but surely the retooling costs associated with changing two resistor values are not insurmountably large?

I know that Pine64 devices are only cursory modifications to reference designs - and as such, I do not believe that there was any actual intent to limit the lifespans of our devices here, only a lack of effort to prolong them - but I do think that this would be a very worthwhile and important tweak to make. Batteries are the primary limiting factor on electronic device lifespans in the modern world, and they are severely hampered in devices on the consumer market by factors that quickly amount to nothing more than greed. We don't need to be limited by this here; Pine64 is not a billion-dollar profit-focused corporation and does not need to follow all the same industry trends in the interest of being competitive. Let's do our own thing.

Will the PineNote have an audio volume control button?

That would be good for page turns when holding both the PineNote and the pen would not be convenient (general reading).

Hi I've just received a PinePower 120w PSU which so far seems to be a great little power supply. One question though the toggle switch on the rear doesn't seem to do anything on my unit. Regardless of the switch position the display can be turn on and off and I can charge my phone on the wireless charger. Is the switch supposed to turn the whole unit off or am I missing something??

I don't mind the default one with Phosh but I feel like it isn't super mobile friendly with the really small buttons and whatnot. Anyone know of a better calendar app?

https://youtu.be/5vYlEUN-8cg

Just a suggestion but how about selling a pine64 branded usb dongle based on the eg25-g modem? It could be handy for those who own single board computers, pinetabs or even ordinary x86 desktops.

Seems like a natural step considering the work going into the firmware for the pinephone. The usb audio interface for voice calls pretty much works out of the box (after some help from a-wai) - here's a quick video demo.

   

Hello all:

I just got my PineTime 4 days ago. Very nice bit of kit!

Where can I find somewhere that documents under what circumstances the PineTime is discoverable (advertises) and under what circumstances the PineTime is pairable?

Based on some experimentation, after a reset (button held for 10 seconds), the PineTime advertises and can be paired. Then, after a few minutes, it stops advertising and can not be paired.

However, looking through the InfiniTime source https://github.com/JF002/InfiniTime/, it would seem to read that there is *no* limit on the amount of time that the PineTime advertises. Take a look at these two comments, for example:
./src/components/ble/NimbleController.cpp:
"// For now, the advertising is restarted as soon as it ends. There may be a race condition that prevent the advertising from restarting reliably."
"// We already have a bond with the peer, but it is attempting to establish a new secure link.  This app sacrifices security for convenience: just throw away the old bond and accept the new link."

These comments make it sound like the PineTime never stops advertising, and never stops being available to pair (even when already paired!)

I have an Early Adopter Pine Tab that I'm looking to sell.
Asking $150 plus shipping.
Comes with keyboard and charging cable.

Hi all, i an getting the below error when trying to rebuild multilib.db ... can anyone help?



sudo pacman -Syyu
:: Synchronizing package databases...
core                       237.4 KiB  88.6 KiB/s 00:03 [##############################] 100%
extra                        2.4 MiB   398 KiB/s 00:06 [##############################] 100%
community                    6.0 MiB   382 KiB/s 00:16 [##############################] 100%
multilib.db failed to download
error: failed retrieving file 'multilib.db' from repo.ialab.dsu.edu : The requested URL retur
ned error: 404
error: failed retrieving file 'multilib.db' from mirrors.ocf.berkeley.edu : The requested URL
returned error: 404
error: failed retrieving file 'multilib.db' from mirror.math.princeton.edu : The requested UR
L returned error: 404
error: failed retrieving file 'multilib.db' from mirrors.gigenet.com : The requested URL retu
rned error: 404
error: failed retrieving file 'multilib.db' from mirror.dacentec.com : The requested URL retu
rned error: 404
error: failed retrieving file 'multilib.db' from mirror.clarkson.edu : The requested URL retu
rned error: 404
error: failed to synchronize all databases (failed to retrieve some files)

Can we run Rust Firmware for PineCone BL602 (or PineDio Stack BL604) in a Web Browser... Simulated with WebAssembly? Let's find out!

Rust on RISC-V BL602: Simulated with WebAssembly