I believe the balancing occurs higher than 80%, but I'm not sure. I'm still looking for a definitive breakdown of when it happens - what conditions trigger it.
I have been communicating with a Norwegian Tesla Fellow, whom confirms what Jason has stated earlier in this Forum, namely that Balancing Occurs whenever the BMS wants. And that matches my 'latest' data (It may however overcompensate a little, I will investigate!).
Current assumption (partly based on Jasons findings) is:
- Before an unknown date in 2016/17, Model S reuired charging to 93% to kick of the Bleading of (up to 100mA) from Over Voltaged bricks. Each blead Resistor CMS would be turned on for a calculated period of time, which could be days.
- Since 2016/17 Balancing takes place, when car has Rest'ed sufficient and have enogh data to perform an improvement.
My 'test's suggest that consistently cycling in narrow DoD at low SoC, does not present 'good' data to support the balancing. At least ImBalance can be slightly improved by intentionally cyckling with a larger DoD at higher SoC
Recap:
Issue:
A: My Voltage ImBalance is anywhere from 20 mV to 60 mV depending on SoC, but is lowest at my Mean SoC arguing that my car does balance:
B: Big ImBalance could be BMS unable to properly Balance, because some bricks could contain Paraistic Drain cells. (Weak Shorts from Dendrites). Then whenever car stands idle, some bricks will slowly discharge and next time balancing runs, it will take the other good bricks down to enforce the voltage balance. Weak shorts, could as well explain my CAC ImBalance of 4.1 Ah (now down from 4.3 Ah due to tests),
I semi ruled out parasitric cell by measuring all voltages over 1 - 2 days of idle and plotting the voltage drop over a few days - they do not dramatically point to weak shorts (the reason the graph looks so saggy is because the rounding is on one mV). A consitent Parasitic cell would consistently caue a High Delta:
C: My Voltage ImBalance does not match my CAC ImBalance. (It would be perfectly OK, if the Voltage Balance reflected 1/CAC relatively,, so that all weak Bricks are charged slightly higher than Strong Bricks, so that most goes to temination voltage at the same time. But my HigherThanAverage CAC Bricks are UnderCharged, so much that a strong/high Ah Capacity Brick goes to 'Stop Voltage' before bricks with lower CAC
Here are all Cell Voltages at very low SoC of around 5%, seems Module 2/Brick 12 takes the lead in a sprint towards3,2 Volts and will stop my drive:
I have calculated the Relative CAC for all bricks using the dV/dAh (slope) of dicharge from 93% to 31% (Hint, A wide and semi linear part of the Charge/Discharge Curve
and there I had to cheat in my formula so that the difference in CAC is proportional to the dV/dAh Squared, which I think is the problem.
Here are thus printet on top of each other CalculatedCACFromSMTMinimumCAC and CalulatedCACFromSMT MaxCAC. 'MinCalculatedFromMax' correctly results in one Brick having exactly the minimum value and 'MaxCalulatedFromMin' as well correctly 'finds' one brick with Max value. So I am pretty convinced that Tesla squares the dV in their CalculatedAmperagehourCapacity estimations.
To test whether my car balances:
A: Always when in long rest and sufficient data have been stored
B: Only balances when charged to 100%
C: Only balances when charging and above 80% SoC
I have performed those tests
So far I can ONLY conclude, that charging in a bigger SoC window than I normally use (Namely 100%, 93% and 93% MaxSlowFox instead of mostly 20% - 65% SoC) has reduced my ImBalance around 6 mV at the best SoC.
When I walk through older measurements and sums longer Vampire Drain periods I get anothe rpicture than previously shown (where the car is only Idle for 1-3 days). This is how it looks, when including 3, 4 and 7 days drain:
If you compare the upper curves (== LongDurationIdleVampyreVoltageDrops), they are true replicas of the CAC graphs.
But if the Voltage Drop was ONLY from real Vampire Consumption, then the strong CAC bricks will have the smallest Voltage Drops (Which one of the , 'ShortTimeVampireDrainVoltageDrops) in the bottom .
This I propose CAN BE:
X: Balancing taking place, with an error in the BMS Algorithm, namely that the CAC ImBalance could be exaggerated, My CalculateMaxCACFromMin and CalculateMinCACFromMax, suggest that there is a Power(2) in the calculation.
Y: Balancing in the very low SoC end where voltage drops faster and faster towards 'Empty' and so the Bricks already low will drop faster ref:
I will need to collect 'Vampire/Idle Voltage Drop much nearer the mostt linear section, which is between between 15% and 55% SoC (the dV/dAh peak is assumed to be somwhere between 55% and 60% because of NCA)
Super simple example: If one were to consider the charge curve a straight line from > 15% SoC untill 100%, as in below:
Then MY CAC ImBalance shoul dresulyt in 22,14mV at 100% I don't see why the CAC based on the Voltage Swing based on the very same Ah's being put in, needs anything squared when comparing Bricks, I think it is linear, but I CAN BE WRONG
One can argue, who really cares, it just over compensates up the balancing, which will be slightly over compensated back next time etc. etc.
I have left my car idle at 60% SoC, If all goes well, it will Vampire Drain a few percent and kick off balancing from 58% and downwards - which is in a llinear discharge section and far away from excessive dV/dAh in the very low SoC end.
I NEED TO KNOW!
