For portable-computer power applications where the Marketing Department isn’t dictating “thou shalt cram as many Joules as possible into this super-thin package!”, lithium iron phosphate (LiFePO4) is a much better battery chemistry than anything with a 3.7V nominal voltage and a 4.2V charge voltage.
This is because LiFePO4 batteries maintain their performance for many more charge-discharge cycles (thousands instead of hundreds) and many more hours of adverse use (i.e. constantly held at 100% charge via external power). The concept of using these batteries at 18650 size to provide battery backup power for small computers, has already been proven in the 40-pin-header world by products such as LiFePO4wered/Pi.
There is also the good side-effect that, leaving aside protection circuitry, LiFePO4 batteries are far safer than any other lithium battery. Specifically, it is much more difficult to ignite a LiFePO4 battery than any other lithium battery; and, without any cobalt, thermal runaway becomes outright impossible.
So why aren’t these batteries a drop-in replacement? Because among lithium battery chemistries, LiFePO4 has a unique voltage range - 3.2V nominal, 3.6V maximum charge voltage, and (EDITED: approximately 2.4V) minimum safe discharge voltage. It requires a dedicated PMIC (or a PMIC that can support both voltage-ranges and be told which one to use) in order to be used safely. The PMIC on the DevTerm’s mainboard only supports the voltage-range of standard lithium batteries, and its manufacturer does not make any other PMICs for LiFePO4 batteries.
I’m not quite sure why the PMIC and 5V boost converter couldn’t fit onto the battery module’s PCB, which is unfortunate since this makes the choice of battery-chemistry much more difficult to change after-the-fact.
The schematics indicate this PMIC (AXP228) on the main board. Is that what you found too?
There’s a lot of settable registers in there, and the PMIC is connected to the core module by GPIO0 and GPIO1. Those docs seem to indicate that the charge voltage can be set via REG33H[6:5].
Yes, that’s the chip I saw. [6:5] means only two bits, and according to the register’s description on page 39, those two bits map to four fixed values: 4.1V, 4.2V, 4.22V and 4.24V.
I would love to see LiFePo support… at the moment i remove the batteries when the DevTerm is not in use because i am a bit paranoid about LiIon batteries…
I have a small bit of know-how in that department, and the DevTerm GitHub repo has the electrical schematics, but I didn’t notice any board artworks. Without them it’s not possible to make new boards that will fit the core, the shell, the screen, the keyboard and all of the other components that attach to the OEM boards.
That is, unless someone else wants to do lots of expensive trial-and-error. Or maybe sacrifice their mainboard and battery module - desolder all components, put the bare PCBs through a flatbad scanner, and take careful measurements from the results.
Do you also remove them from your laptop, smartphone, smartwatch and myriads of other devices that use Lithium based battery?
They are in a safer place in your DevTerm than anywhere else as they are enclosed in a device so no risk of short-circuit, crushing or anything.
Of coure it is, else nobody would make second source part for lots of devices where there is actually no schematics, nor PCB design provided.
Can be tedious, but in the case of the DevTerm most of the component placement is irrelevant, and you only really need to care about where the USB ports are, where is the connector for the battery, and the miniPCI-ish connector on the side for the expansion board. You also need the position of the holes to hold the PCB. And even the PCB shape don’t really matter as long as it fit.
Nothing that cannot be done in about 30min-1h with the board and a calliper, then some work with your favourite PCB CAD tool.
Though if you ask nicely, I’m pretty sure CPi can give you the mechanical info about that PCB, may be not the design but at least all the sizes needed for all of these placement.
With all due respect, if I knew how to do all this myself in a reasonable amount of time, I wouldn’t be asking about it on this forum, I would have just gone ahead and done it already.
No, that’s silly.
That said, such devices’ propensity for permanently-installed batteries adds an extra level of annoyance when the LiCo-type battery inevitably loses its capacity, long before any other component might fail, just because I treated it like a tool not a baby.
For someone with real PCB CAD skills, sure. For me who can barely draw a few traces on pcbnew, it’s quite a bit more than just “tedious”. Altering existing CAD designs to put the power electronics where they belong, is barely within the realm of what my know-how and time can do.
I’m pretty sure I recall hearing about how high-frequency signals (i.e. the HDMI and USB2.0 ports) have to have their PCB traces … what was that term … “impedance-matched”, I think? But, I’ve no clue how to do that. More importantly, since the HDMI signal travels through the Ext module via an internal connector and we have no PCB CAD files for either board, there’s no way for someone who does know wtf they’re doing to figure out if there’s something funny going on, like, idk, an impedance mismatch in one board that is compensated-for on the other.
With all due respect, if I knew how to do all this myself in a reasonable amount of time, I wouldn’t be asking about it on this forum, I would have just gone ahead and done it already.
I encourage you to give PCB design some more time (if you have any interest)! You seem like you have enough knowledge to carry you. Don’t let high-frequency signals or gaps in your knowledge scare you away. Like you said, these are just tools.
I may not be more knowledgeable, but if you decide to start designing this, I’d be happy to provide some feedback if I can. I bet there’s others here who would also be happy to provide some feedback too.
I honestly hope we get strong enough community that eventually redesigns the whole Dev Term! The community already has lots of feedback and ideas for improvements.
Especially because HDMI is not that high frequency (40-50Mhz is high but we are far from 0.5 Ghz.)
The only thing you need really for HDMI (and USB to some extend) is to have somewhat matched line lengths, and KiCAD help you to do that and it is really not that hard to use.
Other than that If you really wanted to change the chip that do the charge for the battery, having anything else than the mechanical info about the PCB is probably useless, you will need to change quite a lot of thing on it to fit the new power management chip.
And now I see why this whole thing is completely infeasible.
There is a kernel driver for the DevTerm’s PMIC, albeit subject to custom CPi patches.
Without the kernel driver there is no fuelgauge, no power-management adjustments based on whether external power is present, no emergency shutdown to protect the battery from overdischarge damage, etc etc.
Now pick a random PMIC. The probability of it being for LiFePO4 batteries is slim. The probability of it having a Linux kernel driver is also slim. Therefore the probability of it having both of these required properties is negligible.
I’m a software person, but I’m no kernel hacker. And given the small scale of the patches used for the DevTerm, many of which are not C code but rather just device-trees (why do these have to be patches, rather than overlays that you just tell u-boot to apply like on a 40-pin Pi!?), I doubt that CPi would pull an entire driver out of their hat.
I don’t know n, you maybe come from the Raspberry Pi world, but Device Tree overlay is not really standardised in the way to apply them. Oh non raspberry Pi system you need to change the boot script of uboot to take account of overlay, and in general there is only one applied.
How the device tree is done is a big hack, and overlays is another one and one DT is specific for one board and soc and cannot really be shared with another.
[semirant]
The linux Device Tree is based on the structure of the name from the Open Firmware “BIOS” used in Sun workstation and most Power PC Macintosh (that’s why all dt related function in the kernel are prefixed with “OF” as in Open Firmware)
But with a major difference. The Linux DT is only describing “devices” where the of tree have more info; the OF version is also machine specific, but is also mostly generated on the fly by the firmware and the kernel/OS have nothing to do with it, where for linux the kernel hold all of it, and it is there to solve a problem that were not there to start with. Most ARM devices are not extensible, the kernel is generally build specifically for the device, and the DT is normally used to allow to have a “generic” kernel with no prior info on how exactly the hardware is, and the device tree give all the hints about that:
Generic kernel for ARM make little sense as they still are build for a specific SoC, so most likely for a specific device around that SoC.
[/semirant]
