Then it will not surprise you that I feel it is quite weak an argument to switch from the technical domain to insinuations on a personal note. I simply believe the best bet on improving SoC tracking is to implement a digital twin (ish) solution, and that Victron will not do that for us in the upcoming years.
The root causes are trivial: practically none of the current generation of Victron compatible BMSses nor the BMVs have what it takes to do long-term stable SoC tracking (that does not rely on a mandated regular full charge cycle that is). The technical solution is equally trivial, every single modern EV is proof of that. Getting Victron to implement that into the core functionality of VenusOS is the non-trivial part.
And I consider this theoretical twin solution completely over the top and nonsensical. A solution for the “Sheldon Coopers” of this world. Completely unnecessary for 99% of everyday users. That Victron isn’t fixated on something like this is the only logical decision. But it’s a decision I don’t have to make and won’t make.
What would we be without the “Sheldons” of this world? Humor would be intellectually poorer.
That’s not theoretical at all, that’s common practice. And as I indicated, the implementation can range from a very minimal static ‘leakage’ correction to a full blown predictive State of Health implementation. But you don’t have to use or even believe any of my contributions here, just don’t make it personal every time I have a different opinion thank you.
Of course, to kill a mosquito, I could use an atomic bomb instead of a fly swatter. Unfortunately, this benefits neither the proponent nor the opponent.
I’m assuming you rather continue this conversation all by yourself, I’ll leave you to it then.
Is that your intention? Or at least something close to it?
Thanks
What happens if I simulate a zero current for the shunt, corresponding to the battery’s quiescent current, and then perform a zero-current calibration? Shouldn’t the shunt then always operate with this quiescent current and calculate it correctly? That would solve the problem, wouldn’t it? Or am I missing something?
Yes that would indeed introduce a constant current bias, but at the cost of not having any reliable current measurement source anymore.
No it would not solve the problem of long-term SoC drift, best case it will allow a significant improvement that scales with the battery’s quiescent current.
Generally speaking, a good quality lithium battery should not have a significant quiescent load to begin with and if unavoidable, the primary current measurement source should be wired before that load. But reality is that many batteries have an internal BMS that does act as a load and is not accurate enough to measure that load/ act as primary current measurement source. Pretty much all JK BMS batteries for instance. In such situations, a better solution would be to place a Smartshunt in between the battery negative terminal (first cell) and the BMS (if accessible to begin with)
That is exactly what i want, i will give it a try…..
If I understand zero-current calibration correctly, you would have to generate a current draw that roughly corresponds to your battery’s standby consumption. You would then have to calibrate at precisely that moment. I imagine that would be difficult in practice.
Those who don’t try - loses
2 Likes
(I am just thinking out loud) Wouldn’t it be easier to implement this in node-red?.
if SOC > 98% battery is full and keep this soc (because the battery is probably balancing). if SOC < 98% create your own soc value based of ampere-counting with some offset. This would keep the current values in the vrm accurate, while allowing a more precise soc. Offsetting the current shunt could lead to the system thinking it is charging. Do you also compensate for the power draw of the cerbo?
1 Like
Sometimes I get the feeling that mastering Node-RED is a prerequisite for being a Victron customer 
. But putting that aside, my Cerbo is connected to the distribution rail beyond the shunt, so power consumption is irrelevant for me anyway.
With respect to Dieter’s idea, yes it would. I’m almost ready with a proof of concept flow that works when you have a BMV Smartshunt as primary battery monitor. Like this post if you want me to DM you for a private share (not willing to put it out publicly) after I’ve run it through a bit of cycle testing.
I get the frustration @Sarowe1990 , but I would argue that state of charge is the task of the BMS. Battery companies failing to implement this correctly is not Victron’s fault. SOC determination for LFP batteries is just hard because of the flat voltage curve. On top of that, manufacturers are limited in algorithm complexity because of the low compute power of the BMS.
@UpCycleElectric thanks for wanting to share 
, but I have no need for such a node-red flow as of now.
1 Like
Correct
Incorrect. The issue is not primarily compute power although hardware limitations might play a role. The issues are: 1) lack of customer demand, 2) inability to upgrade firmware, 3) lack of ADC precision and then possibly 4) lack of memory/compute power. All-in-all, both the technical issues as well as the solutions are really quite trivial and have been solved years ago in the EV industry. A 2012 Renault Kangoo EV for instance has hardly any issues with keeping up with tracking a reasonably reliable SoC for over 13 years without any need to intervene manually. What is interesting is that Victron now has provided a (relatively) user friendly path to overcome these issues retrospectively by means of Node-RED and virtual (battery) devices.