I suggest to build upon the Twizy storage structure for this, extending it if necessary. That way I can also easily make the Twizy battery history chart in the Android App available for other vehicles. Here's a screenshot: https://dexters-web.de/g/custom/ovms/fn/Battery-Monitoring.png The Twizy battery records are explained in the V2 Twizy manual, page 23/24: https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/master/d... When deriving a "*-BAT-…" definition from these, I would change some value types from int to float and output all values using their default units (i.e. V, kW). I removed the cell count from the pack record some years ago to save space, that should again be added for the "*" records. Please have a look and tell me if you think something else is missing. Regards, Michael Am 25.05.2018 um 21:15 schrieb Geir Øyvind Vælidalo:
Really nice, Michael! 🙂
On the Kia Soul we get all 96 to 100 cell voltages, but the resolution is not that good: 0.02 V. We get the voltage and cell number for the two cells with the highest and lowest voltage, also with the lousy 0.02V resolution. At least we get the cell number and deterioration (%) for the best cell and worst cell, and that is what I actually use. On mykiasoulev.com <http://mykiasoulev.com> there is a group of people that created the SOH calculation I’ve implemented i OVMS. It matches the printouts from different car service reports quite well, so it is currently the best SOH number we have.
A common way to store (and display) the battery cell voltages would be great ;-)
Geir
25. mai 2018 kl. 15:55 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
Am 25.05.2018 um 03:55 schrieb Mark Webb-Johnson:
We definitely need some way to make these available in a standard way. I’m not sure that vehicle metrics is the correct way for that, though. Just too many numbers (99 for Tesla Roadster, for example) and maybe not available real-time (need to poll for them). Perhaps a standardised command would be a better approach for this?
Yes, lots of metrics. I know that ;)
OVMS# me li xrt.b. xrt.b.cell.01.volt.act 3.995V xrt.b.cell.01.volt.max 4.12V xrt.b.cell.01.volt.maxdev 0.01V xrt.b.cell.01.volt.min 3.795V xrt.b.cell.02.volt.act 3.985V xrt.b.cell.02.volt.max 4.11V xrt.b.cell.02.volt.maxdev -0.01V xrt.b.cell.02.volt.min 3.785V xrt.b.cell.03.volt.act 3.985V xrt.b.cell.03.volt.max 4.11V xrt.b.cell.03.volt.maxdev -0.005V xrt.b.cell.03.volt.min 3.785V xrt.b.cell.04.volt.act 3.98V xrt.b.cell.04.volt.max 4.105V xrt.b.cell.04.volt.maxdev -0.01V xrt.b.cell.04.volt.min 3.78V xrt.b.cell.05.volt.act 3.985V xrt.b.cell.05.volt.max 4.11V xrt.b.cell.05.volt.maxdev -0.01V xrt.b.cell.05.volt.min 3.78V xrt.b.cell.06.volt.act 3.98V xrt.b.cell.06.volt.max 4.105V xrt.b.cell.06.volt.maxdev -0.01V xrt.b.cell.06.volt.min 3.78V xrt.b.cell.07.volt.act 3.985V xrt.b.cell.07.volt.max 4.105V xrt.b.cell.07.volt.maxdev -0.01V xrt.b.cell.07.volt.min 3.78V xrt.b.cell.08.volt.act 3.985V xrt.b.cell.08.volt.max 4.115V xrt.b.cell.08.volt.maxdev -0.005V xrt.b.cell.08.volt.min 3.785V xrt.b.cell.09.volt.act 3.985V xrt.b.cell.09.volt.max 4.12V xrt.b.cell.09.volt.maxdev 0.005V xrt.b.cell.09.volt.min 3.785V xrt.b.cell.10.volt.act 3.99V xrt.b.cell.10.volt.max 4.12V xrt.b.cell.10.volt.maxdev 0.005V xrt.b.cell.10.volt.min 3.785V xrt.b.cell.11.volt.act 3.99V xrt.b.cell.11.volt.max 4.12V xrt.b.cell.11.volt.maxdev 0.01V xrt.b.cell.11.volt.min 3.79V xrt.b.cell.12.volt.act 3.99V xrt.b.cell.12.volt.max 4.12V xrt.b.cell.12.volt.maxdev 0.01V xrt.b.cell.12.volt.min 3.785V xrt.b.cell.13.volt.act 3.985V xrt.b.cell.13.volt.max 4.115V xrt.b.cell.13.volt.maxdev 0.005V xrt.b.cell.13.volt.min 3.785V xrt.b.cell.14.volt.act 3.995V xrt.b.cell.14.volt.max 4.125V xrt.b.cell.14.volt.maxdev 0.015V xrt.b.cell.14.volt.min 3.795V xrt.b.cell.15.volt.act 0V xrt.b.cell.15.volt.max 0V xrt.b.cell.15.volt.maxdev 0V xrt.b.cell.15.volt.min 0V xrt.b.cell.16.volt.act 0V xrt.b.cell.16.volt.max 0V xrt.b.cell.16.volt.maxdev 0V xrt.b.cell.16.volt.min 0V xrt.b.cell.cnt 14 xrt.b.cmod.01.temp.act 17°C xrt.b.cmod.01.temp.max 23°C xrt.b.cmod.01.temp.maxdev 1°C xrt.b.cmod.01.temp.min 16°C xrt.b.cmod.02.temp.act 16°C xrt.b.cmod.02.temp.max 23°C xrt.b.cmod.02.temp.maxdev 1°C xrt.b.cmod.02.temp.min 16°C xrt.b.cmod.03.temp.act 17°C xrt.b.cmod.03.temp.max 23°C xrt.b.cmod.03.temp.maxdev 1°C xrt.b.cmod.03.temp.min 16°C xrt.b.cmod.04.temp.act 16°C xrt.b.cmod.04.temp.max 23°C xrt.b.cmod.04.temp.maxdev -1°C xrt.b.cmod.04.temp.min 16°C xrt.b.cmod.05.temp.act 17°C xrt.b.cmod.05.temp.max 23°C xrt.b.cmod.05.temp.maxdev 1°C xrt.b.cmod.05.temp.min 16°C xrt.b.cmod.06.temp.act 16°C xrt.b.cmod.06.temp.max 23°C xrt.b.cmod.06.temp.maxdev -1°C xrt.b.cmod.06.temp.min 16°C xrt.b.cmod.07.temp.act 16°C xrt.b.cmod.07.temp.max 23°C xrt.b.cmod.07.temp.maxdev -1°C xrt.b.cmod.07.temp.min 16°C xrt.b.cmod.08.temp.act -40°C xrt.b.cmod.08.temp.max -40°C xrt.b.cmod.08.temp.maxdev 0°C xrt.b.cmod.08.temp.min -40°C xrt.b.cmod.cnt 7 xrt.b.pack.1.temp.alerts xrt.b.pack.1.temp.max 23°C xrt.b.pack.1.temp.min 16°C xrt.b.pack.1.temp.stddev.max 1°C xrt.b.pack.1.temp.watches xrt.b.pack.1.volt.alerts xrt.b.pack.1.volt.max 57.6V xrt.b.pack.1.volt.min 52.8V xrt.b.pack.1.volt.stddev.max 0.005V xrt.b.pack.1.volt.watches 1,2,4,5,6,7,11,12,14 xrt.b.pack.cnt 1 xrt.b.soc.max 100% xrt.b.soc.min 69.78%
But if they are available in real time, they provide a very cool battery monitor, that displays per cell voltage breakdowns during driving:
<kefminlpnpehmipb.png>
If metrics can use extram, 100 cells would be no problem.
Regards, Michael
Regards, Mark.
On 24 May 2018, at 10:28 PM, Robin O'Leary <ovmsdev@caederus.org> wrote:
On Wed, May 23, 2018 at 10:42:32PM +0800, Mark Webb-Johnson wrote:
What is MS_V_BAT_SOH used for? ... Which is it? An overall indication of battery health? 100% being perfect, and 0% a brick? Or battery capacity (100% being a new car, and 50% being one who’s range is only half that of a new car)? If the car provides its own SOH value, then we should report it, even if we don't know exactly what it means. In some cases, it may be important for warranty claims.
For the Leaf, the BMS-reported SOH seems more complicated than just a percentage of new capacity; e.g. increased internal resistance and cell imbalance are also factors.
If the car does not provides its own SOH value directly, then maybe it's better not to fake it; just show whatever values are available. Or perhaps it could be user preference which value best serves their particular purpose: total capacity depletion, cell imbalance ... or some combination.
...
Nissan Leaf uses: StandardMetrics.ms_v_bat_soh->SetValue(ah / newCarAh * 100); You may recall, we had a recent discussion in favour of changing the Leaf's ms_v_bat_soc and ms_v_bat_soh to report the values directly from the BMS.
We do now report SOC as both direct-from-car and scaled-to-new values in Leaf-specific metrics ("m_soc_instrument" and "m_soc_new_car") and we have a config preference for which one to copy to ms_v_bat_soc (defaulting to the instrument value).
We have not yet done that for SOH, but hopefully will do so soon, adding "m_soh_instrument" for the BMS value and moving the above calculation to "m_soh_new_car" . ...
Find out the difference between SOC LIM MIN and LIM MAX, and use that as an indication of imbalance in the pack.
Or should we just add SOC_MIN and SOC_MAX if these are used in many cars? Or an imbalance percentage? Having a way to report cell imbalance is a good idea, but trying to express it as two percentage values seems rather crude. The Leaf can report voltage for every cell, but (as far as I know) does not indicate the nominal voltage value (and I wouldn't be surprised if these differ between the three(?) generations of chemistry already in circulation), so converting each one to a % would be arbitrary. Also, the distribution of voltage values for the modules is often tightly grouped, with just a few outliers, so just picking the lowest and highest is a bit too simplistic. A better way would be to report all the cell voltage measurements directly, or at least some basic statistics (n, average, stddev).
How widely are such detailed values available for other vehicles? _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26