Your response had several technical assumptions, which clearly conveyed your ignorance .
The opinionated and pointed nature of your messaging is merely expectation and frustration…
I don’t care if you know my background, experience or knowledge. It’s irrelevant to me, as I wasn’t talking to you.
How many systems have you worked on?
What is your experience with lithium cells, controllers, conditioning, maintenance and testing?
Did you instantly recognize SoC? Or did you google it (or llm chat for it)?
You may not like my tone, and that’s fine. But trying to correct me on a subject matter on which you are not an expert, and are not sure or aware if I am, is a poor decision…
Better to ask questions before admonishing, if you’re not sure yourself.
Now, to inform you: programming the SoC to actual capacity is perfectly normal for most firmwares.
It requires a little bit more nuance to program this in, but the net effect is that the LED’s always reflect the actual SoC.
By programming a fixed curve or LUT, the LED programming will slowly become less accurate over time.
Typically, what can occur, is that your system never fully indicates ‘full charge’ as that voltage cannot be reached…
The worse outcome, is that full charge is indicated, but quickly lost… e.g. the SoC goes from 100% to 70% in 20 minutes, but then takes another 12 hours to go from 70% to 10%.
This asymmetric results is due to the non-linear SoC profiles inherent to lithium technologies .
The final reason, is that not all cells are created equal. They’re extremely similar, but differences do exist, and they’re small enough that 5 LED’s (20% increments) for state easily make those subtle differences ambiguous.
LiFePO4 (which is one of the safest chemistries available), has a pretty typical curve. Not all cells are equal, though, so having different cells results in different curves.
Now, let’s talk about the advantages of a hard-wired (programmed LUT or curve function):
There are never random errors due to odd charge cycles or charging/discharging errors. Thus, edge cases are eliminated.
There’s less probability of a bug being programmed into the firmware, as it’s a “set and forget” type of development, which is great for stability and reliability.
It’s easier to program, so cheaper.
Now, let’s talk about an adaptive SoC estimation routine:
Most modern devices employ the adaptive algorithm. The reason they do this, is as mentioned: subtle manufacturing differences will not impact the reported SoC, as batteries degrade (they all do), the SoC will reflect the actual current capacity of the battery, and thus the reported charge state will be accurate to real capacity, not original capacity.
Also, if there are changes to the hardware design, an adaptive system will not be adversely impacted, as a few charge cycles will cause the LED indicators to incrementally improve.
It’s harder to maintain, as it’s not always a ‘set and forget’ type of implentation, more edge cases are encountered and different logics have different benefits and drawbacks, which requires some testing and evaluation, which is not easy in a startup (which Emlid was for some several years).
There are a lot more details we could delve into, but I wanted to give you the benefit of learning, instead of simply chastising you.
My request to find out if an adaptive SoC was possible isn’t a technically poor question, and my decision to build a custom pack would only be technically poor, if I was ignorant, which I’m not.
I’ve worked with lithium for quite some time, and was at a research lab where we built a 4kWh system out of a number of banks and series of fault-redundent cells.
Very best.
