I would like to integrate a framework mainboard into a project which will require more power than the FW battery would be practical for. Is their any way to use a different battery or custom li-ion pack with a framework mainboard besides via USB C?
It would be ideal if the laptop was still able to charge via the battery and recognize when it is using the battery and plugged in for battery management.
Is the battery hardware/communication protocol open source? Is their any internal or community development of a framework compatible BMS?
I imagine @Kieran_Levin could answer this. Although I imagine he is crazy busy. My own hazarded guess on this is that the BMS is setup specifically for the battery that the mainboard uses. Charging lipo is bit more complicated that we might understand. It was certainly good of you to ask this question.
Although maybe Framework thought this already through and you can use another battery. You might just need to update the BMS firmware with the new battery’s specifications. (IE: if the voltages, capacity are changing)
@2disbetter I don’t actually care about charging that much though for other peoples use case it could be useful. I had primarily intended to charge it separately for faster charging than the mainboard can provide.
I was hoping for a way to just “trick” the mainboard into recognizing charging and using battery perhaps by pulling one of the battery connector pins high or low with a microcontroller and power the mainboard from the battery connector both when charging and discharging (or some other non voltage sensitive power rail).
Edit: My goal is to add a higher capacity battery to act as a UPS for the mainboard and additional hardware. I have considered using a commercial UPS and inverter but this is very inefficient, heavy, and bulky.
@2disbetter Because that would lose a USB C port and potentially provide an unreliable connection. Also their would be no detection of when it switches to battery mode which would reduce battery life if it does not switch into low power mode.
You could try putting 17.4V across pins 1-3 and 8-10 and see if the mainboard still boots up correctly. If so, you could then build a battery with it’s own BMS and charger and connect it to those pins. If it doesn’t boot, pins 6 or 7 could be something to do with battery presence detection, or you might need to find a way to simulate the framework battery’s BMS. Attaching a logic analyser or oscilloscope to the DAT_SMB pin might let you decode the signals by converting the binary to ASCII - assuming they’re not encrypted.
If you don’t manage to get the BMS communication working but the mainboard boots off the battery without it, you can set the framework, or any laptop, into a sort of low power mode by reducing the CPU clock speed using a tool such as ThrottleStop (it can also throttle start).
Needless to say, there’s considerable risk in not just building lithium based batteries, but also trying to put voltages onto random pins on the mainboard, even if it should be fine according to the pinout…
@MatthewGB Thank you for the very through response. I will have to try that. Now to see where I can identify and purchase the connector…
Decoding the BMS communication protocol is definitely beyond my abilities. I was hoping this communication would be documented somewhere. Perhaps dissecting a battery I could identify the BMS chip used and get it from the datasheet. If it’s standardized their may even be an existing breakout board for it.
I hadn’t considered manually setting the low power mode but I suppose that could be done via usb serial and a monitoring program running on the mainboard.
You shouldn’t have to go that far. I’ve never explored it myself but I understand Smart Battery communication has standards that are publicly available. This being Framework it feel very unlikely that they use a handshake or verification to block non-Framework batteries, like most other laptop makers seem to do.
The protocol is somewhat standardized but the ec does expect certain batteries. The laptop side of the communication is actually open source, you can see how it talks to the battery and probably make a custom version that doesn’t get a panic attack when it gets dc on the battery connector with a non responsive battery.
From the ECs perspective, having power on the battery pins without the battery talking to it means something seriously went wrong with the battery (if something goes wrong in a laptop battery it usually permanently disconnects the power pins, if it dies and could not do that something went really wrong and that battery is probably not safe to use).
It may actually take different batteries, didn’t read that far into the ec code jet but power on the power pins without battery communication is not a normal state to be in, this hints at something in the battery being really wrong, and I’d be a bit concerned if it didn’t get at least a little offended at that and really concerned if it tried charging it.
I wasn’t suggesting that it would just accept no communication. I was just saying that other manufacturers actively try to block you from using 3rd party batteries & that Framework likely doesn’t do that.
Yeah that probably not but it looks like the battery may need a specific controller chip. If there was some asshole blocking you could just take it out, open source ec for the win. Honestly one of the main reason why I was so interested in the framework.
I am curious if you manage to pull this off, I am actually interested in a smaller battery to fit my 10.5" tablet project better. I guess I can´t just replace the cells with smaller ones xD Also, do you guys think it would be in realm of possibility to have 2 batteries connected at once? What I would really love is to have a smaller battery in the tablet (that would help me to make it much thinner) and the stock battery in a case - and neither would use USB-C ports (I am already using one for the display) and both would charge via the mainboard. But I feel like I am well out of my league here as I am not even close to electrotechnician, so please don´t laugh if I said something utterly stupid.