Somone managed to run it on a M1 MBP with Big Sur? #52
Comments
|
I tried on my m1 air. It doesn't work. I installed the helper tool and reboot my air but it still keeps charging. |
|
@JiaaackY thank you for this information! I already suspected that it would not work on M1 macs since they have no SMC like the intel ones have. Maybe I will be able to find a similar solution for M1 macs in the future, but for now I don't have a device to test. Best regards, David |
You can't imagine how many folks out there awaiting eagerly for the M1 version as this is the most amazing app you could ever install on your mac if you are careful about battery of your device. Love your work. |
|
I believe SMC should still exist on ARM Macs, it's just that the key I complied the smc tool from smcFanControl on an ARM Mac.
|
|
@asd123cqp |
|
Sure, here's the |
|
Thank you for dumping the smc keys @asd123cqp ! That is very interesting to me, I suspect Apple simply renamed some keys for the new M1 macbooks. From looking at your dump, I would guess that the key "BCMV" (maybe "battery charge max value"?) could be the right one. If you are brave enough, you could maybe try to write to it and see what happens. Although I must warn you that you can also brick your MacBook by writing to the wrong keys and I do not take responsibility if that would be the case. |
How could you brick it? Would resetting the SMC not fix an issue caused by this? |
|
@Superjack78 because we don't know what those keys do for now. Maybe BCMV actually stands for "battery charge max voltage" and modifying it actually messes with the charging circuit, having the potential to do some permanent damage to the battery even if you reset the SMC afterwards. |
@davidwernhart I doubt There are two values that stand out to me though. I searched the dump for keys that start with an "B" and have the value "100" and found these two: Update:
|
|
BTRS is for Bluetooth? 2018-08-07 09:16:29.919311+0100 0x7b Default 0x0 0 0 kernel: (IOBluetoothFamily) **** [IOBluetoothACPIMethods][SetBTRS] -- mACPIDevice->evaluateObject ('BTRS') successful -- took 23211 microseconds **** |
|
@asd123cqp Wonder if you have managed to try out writing to BMSC? |
|
I find it very strange that so many people (including me) want this feature (which is very sound, considering the sustainability etc.) but Apple cannot provide it natively. :-/ |
I believe it to be even more relevant now as with the increased battery life it becomes somewhat difficult to get this laptop to "healthy" battery levels in regular office use. |
I believe apple doesn't want to spread the fact that keeping your battery at 60% is keeping it healthy. if too many people know it, the "user experience" might suffer, because then people are afraid of charging it up to 100%. they rather hide it as a "battery optimization" feature, that is out of control of the user |
|
Did anyone tried out changing BMSC? I want to buy the new M1 MacBook, been using AlDente for a while, and wish to know if I can still use it for M1 MacBook. |
|
I'm slightly worried that this feature was removed from the M1 MacBooks. The support article "About battery health management in Mac notebooks" has two versions:
The latter doesn't talk about the "battery health management feature" at all. 🤔 |
M1 Macbook Air |
What I meant is the option "Manage battery longevity" under Battery Health (see screenshot in the Intel article). That feature is missing on M1 Macs (at least on my MBA). |
|
Well as long as the hook to enable "Optimised battery charging" is there, there should be a way to limit the charge. @stefandesu Are you planning to try out changing BMSC's value? |
I'm not willing to take the risk, sorry. 🙈 |
|
I don't really get how the optimised battery charging works. Had that checked since day one on both my iPhone and M1 mac, but haven't seen it stay at 80% once. I use my macbook at work plugged in to a screen, so it stays at a 100% at all times now unfortunately. Maybe start a BMSC insurance campaign at gofundme? 🤓 |
With Big Sur, I had to set the % max and reboot my Intel MBP 16" twice for the limit to be applied. Not saying that AlDente works on the M1, but I would try set the limit and reboot more than one time. Also, if we set it to stop at 80%, sometimes it goes over that (usually 1 or 2% above the value we set). |
|
No it just doesn't work on M1 MacBooks.
… |
It won't work without proper changes definitely. As per @asd123cqp's check, the BMCV SMC value is no longer there, thus we need to look for the proper value to change (if it exists) |
|
Yes I'm aware, I read all of that. I hope the value still exists under a
different name, because this tool is super useful.
|
This sounds like a good idea, but I honestly doubt to get enough backers to afford a ~1100€ M1 MacBook Air to experiment with. I guess it's much more likely that someone who already owns one finds the right key in the meantime. Best Regards, |
|
Honestly, I suspect they moved it to firmware level callback (ie. the ARM SMC callback) instead of the SMC value. |
|
I've figured out some more clues in case anyone is willing to risk their their laptop. When I first got my M1 MBA, there were 4 values in the SMC which had a value of 100. These were BMSC, BNSC, BTRS, and BUIC. Upon checking now, I see that BMSC and BNSC are both at 99 instead of 100. They seem to be related in some way, and the fact that they dropped to 99 seems to suggest that they are percentages. However, even though both of these values are 99, my laptop still charges all the way up to 100%. This may not mean much though, because I've noticed on all my MacBooks that even if my laptop battery is ~97% full based on actual current battery capacity divided by the maximum capacity, the laptop doesn't charge beyond that and the battery percentage reported is still 100%. |
|
This could also mean that the BMSC is the max battery percentage (ie. your
battery health).
…On Sun, 13 Dec 2020 at 6:20 PM Ryan Kim ***@***.***> wrote:
I've figured out some more clues in case anyone is willing to risk their
their laptop.
When I first got my M1 MBA, there were 4 values in the SMC which had a
value of 100. These were BMSC, BNSC, BTRS, and BUIC.
Upon checking now, I see that BMSC and BNSC are both at 99 instead of 100.
They seem to be related in some way, and the fact that they dropped to 99
seems to suggest that they are percentages.
However, even though both of these values are 99, my laptop still charges
all the way up to 100%. This may not mean much though, because I've noticed
on all my MacBooks that even if my laptop battery is ~97% full based on
actual current battery capacity divided by the maximum capacity, the laptop
doesn't charge beyond that and the battery percentage reported is still
100%.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#52 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACNGGKFZEV5ZW252Z47D77LSUSIO3ANCNFSM4T4TEQ5A>
.
|
Yeah it's weird - I've trying to make sense of what the gas gauge does in MacBooks. Especially when it updates qmax (the no load capacity of a cell). It doesn't look like it behaves like it should according to the technical manual of the chip. So far it seems that qmax is only updated after the first discharge after a full charge. This would be bad since it requires periodic full charging to keep track of battery health. And resistance updates get disabled after some time until full charge as well. Given apples "optimized" battery charging it's possible that a 80% charge counts as full charge for this. Currently testing if that's true. I think getting to the bottom of how to get a realistic battery health measurement is essential to make use of a tool like AlDente or EternalPower intelligently. We don't want to optimize the coconut bat full charge capacity if our regimen prevents it from updating to reality :). |
This is an Mac Book Pro 13. |
|
This is the same MBP again, now after spending 12h being charged to 100% to check if this changes anything: |
|
Kind of shocking how relevant a good cycling routine is to battery health measurement. My 2018 MacBook pro 15" used to flagged as needing battery service with ~77% of battery health. A couple of cycles between 75% and 10% with about 2 hours wait time at each level and I'm back in good standing with battery health of 82%, sometimes up to 85%. Qmax is still increasing each cycle: I think the core problem which caused the bad battery warning was cycling the battery with external 4k display connected. The discrete graphics card just draws too much to work well with a battery. These new cycles were done without external display at a power draw of about 10W. The laptop can draw 56W if its busy doing graphics. I think that pushes the battery internal resistance into the non linear range and messes up the calibration. And of course sitting at 40 C and 100% SOC for two years can't have helped. BTW there's also some evidence that capacity lost by sitting or cycling at very high SOC can be recovered by resting or even cycling at lower state of charge. Not sure if that was a factor in the rejuvenation of this laptop. If it was then running a couple of calibration cycles might have unmasked the improvement.
|
|
Much worse news for the MacBook Air M1. It's battery sucks. It's only been at 100% battery health since I never cycled it in the region where the underlying calibration data is updated. After a couple of cycles like above it's now at 96% battery health - after 12 cycles total. Looks like I got a rather bad battery. I'll keep cycling it until the calibration steadies and then I'll try to get a replacement. |
|
Long term I think one calibration cycle per month is absolutely necessary to keep track of its battery health. Good that 75% max charge is enough and you don't have to torture the battery at 100% for it. |
Sorry for the stupid question but I'm wondering to what percentage must we discharge for calibration? |
|
I've had success getting qmax updated when charging to 100% and then discharging to 0% or 55%. And 75% to 10% also works. Important is to let the battery sit both charged and discharged for a long time - like two hours. Once the DOD0 updates you can move on. Important is you need to charge to >= 70% and then discharge to >=~50% or <= ~10%. And the difference between both levels needs to be >40%. If your battery has been at a constant charge level for years you'll have to do this a couple of times. qmax needs to be updated and the RaTable as well. And both interact: for example when qmax is increased the gauge also decreases the values in the RaTable. So it takes a couple cycles to converge. Of course for true knowledge of capacity you need to do 0% - 100%. Did this with my iPhone and that really is still at 105%. For my laptop I'll probably just monitor how 75% to 10% changes with time. Should give a good indication of aging. |
|
Turned off charge limiter overnight to see if MacOS's BHM would work. Have been on AC at least 95% of the time in the past 2 weeks (device is ~3 weeks old). |
|
You might need to have the laptop sit at 100% for it to kick in. At first I thought the “machine learning” they use in it was just marketing but the PowerUI agent really does run neural networks to somehow decide what to do with your battery. It’s baffling. |
|
These are fantastic tools, thank you! @joelucid, I was wondering -- is there any downside to repeatedly writing to the CH0B key? Is this actually writing to some kind of NVRAM that may have limited number of writes? Can this degrade the non-volatile memory? |
|
@manuelmenzella My guess would be that the "NVRAM" cells in the M1 chip are still capacitor-based memory that does not wear out like NAND flash does. At least on the M1 mac mini, there is still a NVRAM battery that could support this functionality. On the M1 MBP, perhaps they just use the device's main battery to do this. |
|
@manuelmenzella Would you say that the risk is substantial? Doesn't the system itself write far more often to the NVRAM when charging and doing other stuff? |
|
@inprealpha I think you're probably right; I don't really have a good intuition for how often writes happen, though. @cjmaria good to know, thank you. It would be great to have some confirmation but I suspect this is safe. |
|
Hi Guys, AlDente Pro is finally out. You can check it out on our new website: https://apphousekitchen.com/ Best regards, David & Matthias |
|
@joelucid Excellent insights, and your conclusion that SOC of ~30% is good for storage matches with my research as well. See [1], [2], [3]. I think you already covered this with the 20% lower bound, but since the battery is used for burst current draw even when plugged in, another factor in the mental model should be the battery resistance at varying SOC. Luckily since as you mentioned newer laptops expose this information in the SMC we can query that directly. I'm not sure precisely how the intervals are broken up, but assuming each interval is the same there seem to be 16 intervals so I'll assume that each region is about 7% SOC. On my laptop the resistance was roughly the same ( So anywhere from 40-20 seems to be a fine region for regular use (low calendar aging, relatively low resistance during active use, and low resistance after aging as seen in one of your charts). If you are always plugged in and never use battery, then 30% seems like a decent value to use? I also agree that people probably cite ~40-50% storage SOC to account for discharge buffer, but for a battery that's plugged in this is irrelevant. Another factor might be what they're considering 0% SOC though? The first paper you linked stated that they considered 20% SOC as 3.6V I believe. You can also query this information from SMC to try to match it up (I'm getting 3.7-ish V at 30%). One question: What are your thoughts on maintaining a target charge level (i.e. just setting BCLM directly and having the laptop trickle-charge as needed to maintain that level) vs. setting a lower and upper bound (what AlDente calls "sailing mode")? The former has lower DoD, but most charge limiters from Manufacturers (e.g. Lenovo) implement the latter approach, so I wonder if it has any advantages? [3] https://old.reddit.com/r/batteries/comments/owjt2j/the_4080_rule_myth_or_truth/h7gmhlu/?context=999 |
|
@krackers: the internal resistance table isn't scaled linearly since more resolution is needed at the lower end where internal resistance changes more. Here's how to interpret the table (from https://www.ti.com/lit/an/slua511b/slua511b.pdf?ts=1641374769571&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FBQ20Z45-R1): For CellN R_aM where:
I log all this data in my current version of EternalPower. I don't have an opinion on sailing vs trickle charge - don't remember seeing anything on that. My guess would be that trickle charge is better unless you're at a very high SOC (say 100%) and sailing lowers the average SOC. This might be a good opportunity to share some other things I've learned about the M1 and its battery management:
Other data:
|
|
@joelucid Thank you for the link to the manual, it was an interesting read and it means that the 20-30% soc region has even lower resistance than I originally thought, and the bulk of the resistance increase happens from 15% downwards. That would also explains why dropping to 20% SoC is not at all sufficient for calibration since half of the table is dedicated to SoCs < 20%. As for
This might possibly be related to the "Manage battery longevity" feature, which can be optionally disabled on Intel machines but seems to be always on in M1. This feature is orthogonal to the 80% charge limit ("optimized charging" feature), and as you noted it effectively reduces the max capacity the system sees which I guess would have a similar effect of preventing charge to 100% of true SoC. I also have to correct myself when I mentioned "trickle charge" since it appears that term as defined in the literature applies only to non-lithium ion batteries, and with LiIon batteries the behavior approaching 100% is to reduce current, then once 100% is reached the BMS will cut charging until it falls below a certain threshold voltage, at which point a top-up charge is applied. This in principle seems just like sailing mode, just with a delta soc threshold on the order of few percentage and reduced current. In the TI doc that you linked, I see there is a section for "Termination Config" which specifies the voltage at which to reduce current as approach 100%. I'm also not certain, but since I didn't see anything in there about specifying an RSOC at which to terminate charging I assume the I'm not sure how the SMC actually behaves when BCLM is set – does it attempt to maintain the charge at the fixed level exactly (i.e. effectively a 1% SOC window), which could theoretically lead to rapid switching between charging/discharging under heavy draw (or a really shot battery)? Or is it smart enough to apply some hysteresis? I also recall the behavior (at least in past versions of osx) at 100% SOC was to wait until 95% discharge before beginning charging; I do not know if this is implemented at the SMC or BMS level though. This makes we wonder if there is an SMC key that controls this behavior [1], which could be used to natively implement "sailing mode", or if the tapering threshold of the BMS is exposed. Another point of minor note from the TI doc is that the displayed battery percentage is RSOC instead of ASOC ( / fcc) instead of (/ design capacity), and there is indeed a reserve even at 0% SOC which I think corresponds to One more question, @joelucid – I noticed a lot of sources suggest storing at 3.6-3.7V, which I presume to mean 3.6V when not under load. Correlating SOC with the For instance, the study you linked which discussed resistance after aging at different storage SoC used a 3.0V cutoff as 0% SOC I believe. I have not actually checked on my machine, but I'd suspect on the macbook 0% might be 3.3 or slightly higher. The By the way, out of curiosity was the first version of EternalPower (the one that didn't use the SMC key and required SIP disable) based off the [1] If you haven't already seen it, there was a talk by Ionescu about dumping SMC firmware, and others in the hackintosh community have made a turnkey solution to flash an smc with auth bypassed from which you can dump a memory image and analyze in Ghidra. Would be nice to reverse engineer this and attempt to work out what other useful SMC values exist, or if we can talk to the BMS and get it to do anything useful (e.g. lower charging current). |
|
Edit; I just tried again and I cannot replicate. Hm very strange. It's possible it had something to do with time remaining computations causing the trigger. |
|
After looking at the literature a bit more i'm fairly convinced that the SOC should be taken in relation to the lower and upper voltage limits. See this paper which albeit not on the same chemistry has the quote
which explicitly states that ultimately the voltage level is what is crucial, and the SOC is merely a user-facing presentation of that. I've seen a trend that in the literature most setups use a lower bounds of ~3V @ 0% SOC, but in most consumer electronics this seems to be set a more conservative 3.3V @ 0% SOC. With this in mind, we can see that the recommendations of storage at 3.6 - 3.8V storage would correspond to anywhere between 10 - 40% SOC depending on how the lower bound is defined, which I think also plays a role in the variation between what people say online. For the specific case of the macbook pro, I've found that for my non M1 machine the voltage vs. SOC very roughly corresponds with one shown here (3.3V lower bound), but take note that any point measurements will vary over time due to different loads, temperature, etc. We also have another datapoint on which to base our analysis for the MBP: the resistance table mentioned in previous discussions which stays pretty flat around ~ Based on this, I think it's reasonable to conclude that on battery use when optimizing for longevity a hard-upper bound of 40%, suggested-upper bound of 30% suggested-lower bound of around 15%, and hard lower bound of around 10% would be fine. Note that the lower bound is lower than the threshold cited by joelucid but from what I saw the study showing increased resistance below 20% SOC was based on a 3.0V cutoff; a 10% lower bound also being "safe" also accords with the resistance not really changing much up to that point. Take note though since both voltage and resistance start to rise sharply after 10% the soft-lower bound is probably better to use in practice. And of course the upper bound can be reduced for better longevity at the expense of reduced runtime, although the studies seem to indicate that the marginal benefit from doing so is much less than the benefit from going from 80->60->40->30. For cases where you will be almost always plugged in, seems like a target SOC somewhere between 20% - 15% seems like a good choice. |
|
Would be cool to show these ranges of SOC in the slider bar or have a few
buttons for 'presets' there:
[image: image.png]
…-------------
Rob van Haaren
On Mon, Jan 10, 2022 at 1:17 AM krackers ***@***.***> wrote:
After looking at the literature a bit more i'm fairly convinced that the
SOC should be taken in relation to the lower and upper voltage limits. See this
paper <https://www.mdpi.com/2076-3417/8/10/1825/htm> which albeit not on
the same chemistry has the quote
An important factor that needs to be pointed out is the definition of the
SOC window. Schmalstieg et al. [3] defined the SOC window from 2.5–4.2 V,
compared to the 2.8–4.15 V used for the here studied cells. If we consider
the corresponding voltage level for the SOC intervals instead, the results
produced by Schmalstieg [3] then prove to be similar to the ones presented
in this study. From this, we can conclude that how we define the SOC window
is important since the ageing is strongly linked to the SOC level, i.e. the
voltage level of the cell.
which explicitly states that ultimately the voltage level is what is
crucial, and the SOC is merely a user-facing presentation of that. I've
seen a trend that in the literature most setups use a lower bounds of ~3V @
0% SOC, but in most consumer electronics this seems to be set a more
conservative 3.3V @ 0% SOC.
With this in mind, we can see that the recommendations of storage at 3.6 -
3.8V storage would correspond to anywhere between 10 - 40% SOC depending on
how the lower bound is defined, which I think also plays a role in the
variation between what people say online.
For the specific case of the macbook pro, I've found that for my non M1
machine the voltage vs. SOC very roughly corresponds with one shown here
<https://blog.ampow.com/lipo-voltage-chart/> (3.3V lower bound), but take
note that any point measurements will vary over time due to different
loads, temperature, etc.
We also have another datapoint on which to base our analysis for the MBP:
the resistance table mentioned in previous discussions which stays pretty
flat around ~0x30 from 40% to 15% SOC and only starts rapidly increasing
below 10% SOC.
Based on this, I think it's reasonable to conclude that *on battery use*
when optimizing for longevity a hard-upper bound of 40%, suggested-upper
bound of 30% suggested-lower bound of around 15%, and hard lower bound of
around 10% would be fine. Note that the lower bound is lower than the
threshold cited by joelucid but from what I saw the study showing increased
resistance below 20% SOC was based on a 3.0V cutoff; a 10% lower bound also
being "safe" also accords with the resistance not really changing much up
to that point. Take note though since both voltage and resistance start to
rise sharply after 10% the soft-lower bound is probably better to use in
practice. And of course the upper bound can be reduced for better longevity
at the expense of reduced runtime, although the studies seem to indicate
that the marginal benefit from doing so is much less than the benefit from
going from 80->60->40->30.
For cases where you will be almost always plugged in, seems like a target
SOC somewhere between 20% - 15% seems like a good choice.
—
Reply to this email directly, view it on GitHub
<#52 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABCQBGYGKTNXYP3FJKNHHO3UVJ2YXANCNFSM4T4TEQ5A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
@joelucid I see you referencing |
|
@actuallymentor yeah I'm using CH0C. I have no idea what the difference between the two is. Long time since I looked at it. CH0C controls whether the laptop charges the battery from the power adapter. If it's 0 then only the operating power will get taken from the charger. |
It actually does taper current as it reaches target charge.
Nah - it does connect the charger to the laptop for operation. So it would only start recharging once the battery voltage drops either if the charger couldn't deliver enough or by self discharge. Not sure how much hysteresis it uses.
There is actually quite a bit of buffer between 100% and 99% in the old macs (IIRC 99% is more like 95%) - so that might be what leads to the hysteresis. But I'm not sure. I don't really think sailing mode is very useful unless you want to stress the battery. I have a cycling functionality in my app for that. It'll either wait for the BMS to record the OCV before switching for calibration - or just switch directly when reaching either limit (for stress testing).
Yeah they charge to a voltage obviously. BTW this is a bit of an issue generally: RSOC can vary by applied load and internal resistance. So a percentage may or may not be close to the voltage which makes sense from a longevity perspective. I had thought about allowing specifying the charge levels in voltage terms but never got to that. It's important for calibration: an old battery needs to go down much further than a new one to reach the OCV which enables calibration. Since the internal resistance disables the lower SOC range from use.
I had experimented with various ways to access the functionality. I think other than discharging with connected charger I had everything working without SIP disable in the end. But since then everything worked with SMC that just seemed like it was the easier path.
Yeah that's all true. Of course we don't really know what the best voltage to target is though. Clearly the chemistry has been tuned to allow higher voltages (I think iPhones now go up to 4.45 IIRC) likely using additives - not clear what the effects are overall. I'd go for maybe around 3.6V for storage.
Right - also note that there is something like a local internal resistance maximum around 60% charge. From what I've read this is due to a phase transition in an electrode - I believe the li ions accumulate in layers and a new layer is opened then which leads to extra stress due to expansion. So I'm trying to avoid passing 60% generally even if I need more capacity. |
For illustration here is my 2018 MacBook pro. Discard first two data values. Then it's 100%, 90%, ... - notice the local maximum at 60%.
You'll often see this effect in the literature even if its not discussed. That discharge cycles with a constant delta SOC around different average SOCs improve the lower you go in average SOC. But if 60% is included its bad. E.g. 50% - 70% is likely worse than 70% - 90%. |
|
For the CLI aficionados in here, I made a little open source tool in the same vein @joelucid's GUI that adds the following CLI commands:
Open source and without warranty. |
|
In case this could be useful new firmwares has a new flag (CHWA) to set a 80% limit managed natively. This limit works while the mac is sleeping. I modified @actuallymentor's tool (PR) to implement this based on Asahi's reverse engineering efforts (kudos to Asahi team for this) |
and others
Somone managed to run it on a M1 MBP with Big Sur?
The text was updated successfully, but these errors were encountered: