Michael, Thanks for the explanation. That makes good sense. Given that at least three vehicles support SOC MIN and MAX, I’ve gone ahead and made standard metrics for those. I haven’t modified all the vehicle modules to store them, but think that can be done for at least Roadster, Kia Soul and Twizy (and maybe Nissan Leaf). Can the maintainers of those modules set appropriately? Should be very simple. I’ve also created a generic textual v.b.health metric that can be used to record a textual indication of vehicle health (perhaps the calculations behind v.b.soh). Very vehicle specific. I’ve then modified the Tesla Roadster module to store v.b.soc.min and v.b.soc.max, and to calculate v.b.soh (based on %cac remaining x %soc inbalance). Maybe tune it later, but I think it should give a pretty good rough indication of health. That is all in an edge release ready to go out tonight. Regards, Mark.

On 24 May 2018, at 12:12 AM, Michael Balzer <dexter@expeedo.de> wrote:

Mark,

I introduced this originally, it's meant to be (1), the overall indication of battery health.

As the wikipedia article says, there is no general industry definition on how to calculate this.

On the Twizy, the SOH is given by the BMS, while the CAC is calculated by the OVMS by monitoring the charge process and counting coulombs. The BMS SOH is the (normally invisible) limit for the usable capacity, as the Twizy always shows a range of 0-100% SOC regardless of the SOH. It's also the base for any warranty replacement of the battery (if it's rented you'll get a new one when SOH is below 75%).

The BMS is proprietary and without any available documentation, it's a complete mystery how it calculates the SOH.

While the capacity would normally be the major factor in a SOH, the Twizy BMS (LG Chem) has actually other ideas on this. For example it's been at 100% for the first three years, then at 99% for another two years, while my CAC value showed the actual degradation (long term linear with cycles). It's then begun to drop rapidly over a short period of time and is now close to my CAC level. My cells are still pretty good balanced under load as well as open circuit, the balance also degraded more or less linearly. There are also no obvious temperature indications that could explain the SOH curve.

Generally I recommend to use this for the value the car provides, if any.

If the car doesn't provide an SOH, any calculation that fits…

...

An overall indication of battery health? 100% being perfect, and 0% a brick?

…will do.

...

Kia Soul seems to be closest to the implementation I was thinking of. Find out the difference between SOC LIM MIN and LIM MAX, and use that as an indication of imbalance in the pack. But Nissan Leaf seems to be more like (CAC/160)*100 (where 160 is the CAC for a brand new vehicle).

Or should we just add SOC_MIN and SOC_MAX if these are used in many cars? Or an imbalance percentage?

Or should we combine the both (so CAC/160*100 gives us percentage capacity loss, and SOCMAX-SOCMIN/SOCMAX*100 gives us imbalance of the pack, then we perhaps multiply the two together to give an overall indication of health)?

If breaking down SOC into the peak min and max cell values I suggest also adding the average and peak standard deviation, plus either the average cell SOC or the number of cells to derive that.

Interior resistance of cells would be another option for standard metrics of cell health, but seems to be rarely available (and needs a reference).

I've got the cell module voltages and temperatures on the Twizy. I record their peak values and deviations under load and calculate the standard deviation. This monitoring shows only a minor difference against the values I recorded five years ago. I'm pretty sure if I also had the internal resistance, that would give a much clearer image.

Regards, Michael

Am 23.05.2018 um 16:42 schrieb Mark Webb-Johnson:

...

What is MS_V_BAT_SOH used for?

For Tesla Roadster, as well as SOC, we have SOC LIM MIN and SOC LIM MAX. I want to make those available.

Kia Soul seems to use:

StdMetrics.ms_v_bat_soh->SetValue( 110 - ( m_b_cell_det_max->AsFloat(0) + m_b_cell_det_min->AsFloat(0)) / 2 );

Nissan Leaf uses:

StandardMetrics.ms_v_bat_soh->SetValue(ah / newCarAh * 100);

Twizy uses:

CAN_BYTE(5) on ID 0x424

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)?

The definition here seems to lean towards #2 (capacity related), but seems arguable:

https://en.wikipedia.org/wiki/State_of_health <https://en.wikipedia.org/wiki/State_of_health>

State of health (SoH) is a figure of merit of the condition of a battery (or a cell, or a battery pack), compared to its ideal conditions. The units of SoH are percent points (100% = the battery's conditions match the battery's specifications).

Typically, a battery's SoH will be 100% at the time of manufacture and will decrease over time and use. However, a battery's performance at the time of manufacture may not meet its specifications, in which case its initial SoH will be less than 100%.

As SoH does not correspond to a particular physical quality, there is no consensus in the industry on how SoH should be determined. The designer of a battery management system may use any of the following parameters (singly or in combination) to derive an arbitrary value for the SoH.

Internal resistance / impedance / conductance Capacity Voltage[2] Self-discharge Ability to accept a charge Number of charge–discharge cycles

In addition, the designer of the battery management system defines an arbitrary weight for each of the parameter's contribution to the SoH value. The definition of how SoH is evaluated can be a trade secret.

Kia Soul seems to be closest to the implementation I was thinking of. Find out the difference between SOC LIM MIN and LIM MAX, and use that as an indication of imbalance in the pack. But Nissan Leaf seems to be more like (CAC/160)*100 (where 160 is the CAC for a brand new vehicle).

Or should we just add SOC_MIN and SOC_MAX if these are used in many cars? Or an imbalance percentage?

Or should we combine the both (so CAC/160*100 gives us percentage capacity loss, and SOCMAX-SOCMIN/SOCMAX*100 gives us imbalance of the pack, then we perhaps multiply the two together to give an overall indication of health)?

Thoughts?

Regards, Mark

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev

a) Can we agree on a slightly different naming scheme? I suggest adding an indicator for the cell level semantics to the "soc.min" and "soc.max" names, e.g.

Yes, something like that is better. I did consider it, but couldn’t come up with a good name. These min/max limiting values are normal at some sort of sub-module level. Cells grouped into sub-modules, sub-modules grouped into modules, and modules making up the battery pack. Voltages are normally available at the sub-module level, not individual cell. In the Tesla Roadster these are called cells, bricks, sheets, and ESS. In the Tesla Model S/X/3 these are called cells, bricks, modules, and ‘pack’. How about v.b.m.soc.[min|max] (with the ‘m’ denoting module)? Or is ‘cell’ ok, even though we are not really talking about individual cells but bricks/sub-modules?

b) What is the technical definition of the "soc.min" metric? Normally I would expect "soc.min" to be identical to the overall pack SOC -- the Roadster certainly doesn't allow cells to be discharged below 0% SOC? What are typical values for "min" and "max" in reference to the overall SOC and voltage? I mean, if that's really a normalized cell voltage level, we shouldn't name it "soc".

Very good question. I wish I knew the answer. Here is an example from a Tesla Roadster: OVMS# metrics list v.b v.b.cac 156.988Ah v.b.health CAC 156.99Ah SOC 75% LIM 68% MIN 68% MAX 70% v.b.soc 75% v.b.soc.max 70% v.b.soc.min 68% v.b.soh 95.1741% Firstly: SOC LIM vs SOC. In it’s diagnostics screen, the Tesla Roadster displays these as “SOC: LIM 68% MIN 68% MAX 70%”, separately from the SOC displayed to the user. I guess the user SOC is dependent on current mode (primarily standard or range), and the SOC LIM/MIN/MAX is normalised to always be in one mode? 68% vs 75% is about 10% which seems about right for standard vs range mode. So, let’s just concentrate on SOC LIM/MIN/MAX. SOC LIM is the limiting SOC. For a discharge, the limit is based on SOC MIN, and for a charge it would be SOC MAX. But I am not sure if SOC LIM tracks that, or just always shows the minimum? I’ve only really looked at it after a charge has been completed (discharge mode), but have never seen it show anything other than SOC MIN. Anyway, we don’t publish SOC LIM. Fundamentally, SOC MIN/MAX is supposed to give us an indication of the imbalance in the pack. That will limit how high the pack can be charged, and how low it can be discharged. The overall goal here is to come up with a standard framework into which all cars can fit (and we can display in the Apps in a standard way). Individual car modules can also produced extra information they have available, but that doesn’t have to apply to all car types. I suggest we start from the premise that the car is measuring voltage to determine SOC (a simplification, I know, but let’s go with it). So in a simplified ideal car with 100 cells in series making up the pack, and a voltage range 300v (empty) to 400v (full), that would result in 0% to 100% SOC. 350v would be 50% SOC. Let’s assume those cells are grouped into bricks of 10 cells (again in series) and we can measure those, so we’d end up with brick voltages of 30v to 40v. We can then determine 10 brick SOCs (30v or less is 0% brick SOC, 40v is 100% brick SOC, and 35v is 50% brick SOC). We can then determine brick SOC MIN and MAX, as well as LIM (depending on charging/discharging). So, I think the technical definitions are: v.b.soc is the overall state of charge of the entire battery pack. It should show 0% for an empty, and 100% for a full pack. A sub-module soc is the state of charge of an individual sub-module in the pack. It should show 0% for an empty, and 100% for a full sub-module. v.b.m.soc.min is the sub-module soc of the sub-module with the lowest soc. This is the limiting factor for discharging. The SOC displayed to the user is based on this. v.b.m.soc.max is the sub-module soc of the sub-module with the highest soc. This is the limiting factor for charging. v.b.soh is an overall indicator for the health of the entire battery pack. It should show 100% for a new pack, and 0% for a completely dead and unusable pack. It should give some idea of the health, lifetime used, and degradation of the pack. Does that work? Regards, Mark.

On 25 May 2018, at 12:59 AM, Michael Balzer <dexter@expeedo.de> wrote:

Mark,

two questions…

a) Can we agree on a slightly different naming scheme?

I suggest adding an indicator for the cell level semantics to the "soc.min" and "soc.max" names, e.g.

v.b.cell.soc.min v.b.cell.soc.max

…or abbreviated…

v.b.c.soc.min v.b.c.soc.max

That way we can add further cell related metrics (e.g. ".cnt", ".soc.stddev") in a consistent name space.

b) What is the technical definition of the "soc.min" metric?

Normally I would expect "soc.min" to be identical to the overall pack SOC -- the Roadster certainly doesn't allow cells to be discharged below 0% SOC?

What are typical values for "min" and "max" in reference to the overall SOC and voltage?

I mean, if that's really a normalized cell voltage level, we shouldn't name it "soc".

Regards, Michael

Am 24.05.2018 um 04:20 schrieb Mark Webb-Johnson:

...

Michael,

Thanks for the explanation. That makes good sense.

Given that at least three vehicles support SOC MIN and MAX, I’ve gone ahead and made standard metrics for those. I haven’t modified all the vehicle modules to store them, but think that can be done for at least Roadster, Kia Soul and Twizy (and maybe Nissan Leaf). Can the maintainers of those modules set appropriately? Should be very simple.

I’ve also created a generic textual v.b.health metric that can be used to record a textual indication of vehicle health (perhaps the calculations behind v.b.soh). Very vehicle specific.

I’ve then modified the Tesla Roadster module to store v.b.soc.min and v.b.soc.max, and to calculate v.b.soh (based on %cac remaining x %soc inbalance). Maybe tune it later, but I think it should give a pretty good rough indication of health. That is all in an edge release ready to go out tonight.

Regards, Mark.

...

On 24 May 2018, at 12:12 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

Mark,

I introduced this originally, it's meant to be (1), the overall indication of battery health.

As the wikipedia article says, there is no general industry definition on how to calculate this.

On the Twizy, the SOH is given by the BMS, while the CAC is calculated by the OVMS by monitoring the charge process and counting coulombs. The BMS SOH is the (normally invisible) limit for the usable capacity, as the Twizy always shows a range of 0-100% SOC regardless of the SOH. It's also the base for any warranty replacement of the battery (if it's rented you'll get a new one when SOH is below 75%).

The BMS is proprietary and without any available documentation, it's a complete mystery how it calculates the SOH.

While the capacity would normally be the major factor in a SOH, the Twizy BMS (LG Chem) has actually other ideas on this. For example it's been at 100% for the first three years, then at 99% for another two years, while my CAC value showed the actual degradation (long term linear with cycles). It's then begun to drop rapidly over a short period of time and is now close to my CAC level. My cells are still pretty good balanced under load as well as open circuit, the balance also degraded more or less linearly. There are also no obvious temperature indications that could explain the SOH curve.

Generally I recommend to use this for the value the car provides, if any.

If the car doesn't provide an SOH, any calculation that fits…

...

An overall indication of battery health? 100% being perfect, and 0% a brick?

…will do.

...

Kia Soul seems to be closest to the implementation I was thinking of. Find out the difference between SOC LIM MIN and LIM MAX, and use that as an indication of imbalance in the pack. But Nissan Leaf seems to be more like (CAC/160)*100 (where 160 is the CAC for a brand new vehicle).

Or should we just add SOC_MIN and SOC_MAX if these are used in many cars? Or an imbalance percentage?

Or should we combine the both (so CAC/160*100 gives us percentage capacity loss, and SOCMAX-SOCMIN/SOCMAX*100 gives us imbalance of the pack, then we perhaps multiply the two together to give an overall indication of health)?

If breaking down SOC into the peak min and max cell values I suggest also adding the average and peak standard deviation, plus either the average cell SOC or the number of cells to derive that.

Interior resistance of cells would be another option for standard metrics of cell health, but seems to be rarely available (and needs a reference).

I've got the cell module voltages and temperatures on the Twizy. I record their peak values and deviations under load and calculate the standard deviation. This monitoring shows only a minor difference against the values I recorded five years ago. I'm pretty sure if I also had the internal resistance, that would give a much clearer image.

Regards, Michael

Am 23.05.2018 um 16:42 schrieb Mark Webb-Johnson:

...

What is MS_V_BAT_SOH used for?

For Tesla Roadster, as well as SOC, we have SOC LIM MIN and SOC LIM MAX. I want to make those available.

Kia Soul seems to use:

StdMetrics.ms_v_bat_soh->SetValue( 110 - ( m_b_cell_det_max->AsFloat(0) + m_b_cell_det_min->AsFloat(0)) / 2 );

Nissan Leaf uses:

StandardMetrics.ms_v_bat_soh->SetValue(ah / newCarAh * 100);

Twizy uses:

CAN_BYTE(5) on ID 0x424

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)?

The definition here seems to lean towards #2 (capacity related), but seems arguable:

https://en.wikipedia.org/wiki/State_of_health <https://en.wikipedia.org/wiki/State_of_health>

State of health (SoH) is a figure of merit of the condition of a battery (or a cell, or a battery pack), compared to its ideal conditions. The units of SoH are percent points (100% = the battery's conditions match the battery's specifications).

Typically, a battery's SoH will be 100% at the time of manufacture and will decrease over time and use. However, a battery's performance at the time of manufacture may not meet its specifications, in which case its initial SoH will be less than 100%.

As SoH does not correspond to a particular physical quality, there is no consensus in the industry on how SoH should be determined. The designer of a battery management system may use any of the following parameters (singly or in combination) to derive an arbitrary value for the SoH.

Internal resistance / impedance / conductance Capacity Voltage[2] Self-discharge Ability to accept a charge Number of charge–discharge cycles

In addition, the designer of the battery management system defines an arbitrary weight for each of the parameter's contribution to the SoH value. The definition of how SoH is evaluated can be a trade secret.

Kia Soul seems to be closest to the implementation I was thinking of. Find out the difference between SOC LIM MIN and LIM MAX, and use that as an indication of imbalance in the pack. But Nissan Leaf seems to be more like (CAC/160)*100 (where 160 is the CAC for a brand new vehicle).

Or should we just add SOC_MIN and SOC_MAX if these are used in many cars? Or an imbalance percentage?

Or should we combine the both (so CAC/160*100 gives us percentage capacity loss, and SOCMAX-SOCMIN/SOCMAX*100 gives us imbalance of the pack, then we perhaps multiply the two together to give an overall indication of health)?

Thoughts?

Regards, Mark

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev

A better scheme would be to supply these as general / abstract "levels", i.e.

v.b.c.level.min v.b.c.level.max

So this can be either an SOC or an SOH or a normalized voltage or resistance level, whatever is appropriate and available for a vehicle. It just needs to be in the range 0-100%, so min and max can be put in relation. And we also should add…

v.b.c.level.avg v.b.c.level.stddev

I think that would work better than "soc". Comments?

OK. Done. Committed and pushed. That also leaves the namespace v.b.c.* for whatever we do with individual cell voltages and temperatures. My preference for that seems to be an OvmsMetricArrayFloat type (the AsString result of which could be a comma-separated list, but we can provide individual value set/get functions for OVMS code). Roadster has 99 cells, and I really don’t want to create 198 metrics for this. What do you think?

To check if I got this right: - "standard mode" means the battery will only be charged up to max 90% real, but the display makes that appear as 100% - the battery actually had 68% SOC here, but the display showed this as 75% - if you had switched to "range mode", the display would have dropped to 68%

Is that correct?

Again, a fictitious vehicle with cells in range 3v to 4v. Assuming “range” mode is the full pack, so 0% is 3v and 100% is 4v. Say “standard” mode hides the bottom and top 10% of the pack, now 0% is 3.1v and 100% is 3.9v. If you charge to 100% in standard mode, then switch to range mode, it switches to show 90% SOC. That is how the roadster behaves (although voltages and percentages are different). Regards, Mark.

On 25 May 2018, at 9:33 PM, Michael Balzer <dexter@expeedo.de> wrote:

Am 25.05.2018 um 03:31 schrieb Mark Webb-Johnson:

...

...

a) Can we agree on a slightly different naming scheme? I suggest adding an indicator for the cell level semantics to the "soc.min" and "soc.max" names, e.g. Yes, something like that is better. I did consider it, but couldn’t come up with a good name.

These min/max limiting values are normal at some sort of sub-module level. Cells grouped into sub-modules, sub-modules grouped into modules, and modules making up the battery pack. Voltages are normally available at the sub-module level, not individual cell.

In the Tesla Roadster these are called cells, bricks, sheets, and ESS. In the Tesla Model S/X/3 these are called cells, bricks, modules, and ‘pack’.

How about v.b.m.soc.[min|max] (with the ‘m’ denoting module)? Or is ‘cell’ ok, even though we are not really talking about individual cells but bricks/sub-modules?

My "cell" is your "sub-module".

I use "cell" and "module" from a logical rather than a physical perspective, with a "cell" being the smallest individually addressable / measurable unit of a battery pack, regardless of how many physical cells that actually consists of. A "module" is a group of "cells" sharing some functions / measurements, for example temperature sensors / control. A "pack" is n "cells" connected in series, so the weakest cell defines the pack.

So I think "cell" would fit better than "module", as we're trying to get the highest level of detail available here.

The physical cells in a logical cell normally can't be addressed individually, they build a macro cell. Especially if building from 18650 or other small units, monitoring the physical cells would be overkill and also wouldn't really help much in monitoring or securing the battery. Normally an 18650 based pack will even omit monitoring of the cell level fuses -- if they blow, they've done their job, the overall macro cell capacity drops and that will be measured by the BMS, that's sufficient.

On packs using prismatic or pouch cells, monitoring the physical cells could be done, and could help in better degradation diagnosis, but in reality also is not essential for security or performance monitoring. Physical cells put in parallel are selected carefully to match in terms of age, capacity and resistance. So they also degrade very closely unless one has a production fault, in which case the overall macro cell performance also drops sufficiently to detect the problem.

...

...

b) What is the technical definition of the "soc.min" metric? Normally I would expect "soc.min" to be identical to the overall pack SOC -- the Roadster certainly doesn't allow cells to be discharged below 0% SOC? What are typical values for "min" and "max" in reference to the overall SOC and voltage? I mean, if that's really a normalized cell voltage level, we shouldn't name it "soc". Very good question. I wish I knew the answer. Here is an example from a Tesla Roadster:

OVMS# metrics list v.b v.b.cac 156.988Ah v.b.health CAC 156.99Ah SOC 75% LIM 68% MIN 68% MAX 70% v.b.soc 75% v.b.soc.max 70% v.b.soc.min 68% v.b.soh 95.1741%

Firstly: SOC LIM vs SOC. In it’s diagnostics screen, the Tesla Roadster displays these as “SOC: LIM 68% MIN 68% MAX 70%”, separately from the SOC displayed to the user. I guess the user SOC is dependent on current mode (primarily standard or range), and the SOC LIM/MIN/MAX is normalised to always be in one mode? 68% vs 75% is about 10% which seems about right for standard vs range mode.

To check if I got this right: - "standard mode" means the battery will only be charged up to max 90% real, but the display makes that appear as 100% - the battery actually had 68% SOC here, but the display showed this as 75% - if you had switched to "range mode", the display would have dropped to 68%

Is that correct?

...

So, let’s just concentrate on SOC LIM/MIN/MAX. SOC LIM is the limiting SOC. For a discharge, the limit is based on SOC MIN, and for a charge it would be SOC MAX. But I am not sure if SOC LIM tracks that, or just always shows the minimum? I’ve only really looked at it after a charge has been completed (discharge mode), but have never seen it show anything other than SOC MIN. Anyway, we don’t publish SOC LIM.

Fundamentally, SOC MIN/MAX is supposed to give us an indication of the imbalance in the pack. That will limit how high the pack can be charged, and how low it can be discharged.

The overall goal here is to come up with a standard framework into which all cars can fit (and we can display in the Apps in a standard way). Individual car modules can also produced extra information they have available, but that doesn’t have to apply to all car types.

I suggest we start from the premise that the car is measuring voltage to determine SOC (a simplification, I know, but let’s go with it). So in a simplified ideal car with 100 cells in series making up the pack, and a voltage range 300v (empty) to 400v (full), that would result in 0% to 100% SOC. 350v would be 50% SOC. Let’s assume those cells are grouped into bricks of 10 cells (again in series) and we can measure those, so we’d end up with brick voltages of 30v to 40v. We can then determine 10 brick SOCs (30v or less is 0% brick SOC, 40v is 100% brick SOC, and 35v is 50% brick SOC). We can then determine brick SOC MIN and MAX, as well as LIM (depending on charging/discharging). So, I think the technical definitions are:

v.b.soc is the overall state of charge of the entire battery pack. It should show 0% for an empty, and 100% for a full pack.

A sub-module soc is the state of charge of an individual sub-module in the pack. It should show 0% for an empty, and 100% for a full sub-module. v.b.m.soc.min is the sub-module soc of the sub-module with the lowest soc. This is the limiting factor for discharging. The SOC displayed to the user is based on this. v.b.m.soc.max is the sub-module soc of the sub-module with the highest soc. This is the limiting factor for charging.

v.b.soh is an overall indicator for the health of the entire battery pack. It should show 100% for a new pack, and 0% for a completely dead and unusable pack. It should give some idea of the health, lifetime used, and degradation of the pack.

Does that work?

If I got it right v.b.soc is also always the SOC that is shown to the user by the car. That may be a logical value, not the real physical SOC.

The cell level values need not be compatible with the user SOC, they may be internal / physical values.

So I really don't think we should call them "soc", as that will confuse users even if they are SOCs, and can be completely misleading on a car that derives these values from voltages or something else.

A better scheme would be to supply these as general / abstract "levels", i.e.

v.b.c.level.min v.b.c.level.max

So this can be either an SOC or an SOH or a normalized voltage or resistance level, whatever is appropriate and available for a vehicle. It just needs to be in the range 0-100%, so min and max can be put in relation. And we also should add…

v.b.c.level.avg v.b.c.level.stddev

I think that would work better than "soc". Comments?

Regards, Michael

...

Regards, Mark.

...

On 25 May 2018, at 12:59 AM, Michael Balzer <dexter@expeedo.de> <mailto:dexter@expeedo.de> wrote:

Mark,

two questions…

a) Can we agree on a slightly different naming scheme?

I suggest adding an indicator for the cell level semantics to the "soc.min" and "soc.max" names, e.g.

v.b.cell.soc.min v.b.cell.soc.max

…or abbreviated…

v.b.c.soc.min v.b.c.soc.max

That way we can add further cell related metrics (e.g. ".cnt", ".soc.stddev") in a consistent name space.

b) What is the technical definition of the "soc.min" metric?

Normally I would expect "soc.min" to be identical to the overall pack SOC -- the Roadster certainly doesn't allow cells to be discharged below 0% SOC?

What are typical values for "min" and "max" in reference to the overall SOC and voltage?

I mean, if that's really a normalized cell voltage level, we shouldn't name it "soc".

Regards, Michael

Am 24.05.2018 um 04:20 schrieb Mark Webb-Johnson:

...

Michael,

Thanks for the explanation. That makes good sense.

Given that at least three vehicles support SOC MIN and MAX, I’ve gone ahead and made standard metrics for those. I haven’t modified all the vehicle modules to store them, but think that can be done for at least Roadster, Kia Soul and Twizy (and maybe Nissan Leaf). Can the maintainers of those modules set appropriately? Should be very simple.

I’ve also created a generic textual v.b.health metric that can be used to record a textual indication of vehicle health (perhaps the calculations behind v.b.soh). Very vehicle specific.

I’ve then modified the Tesla Roadster module to store v.b.soc.min and v.b.soc.max, and to calculate v.b.soh (based on %cac remaining x %soc inbalance). Maybe tune it later, but I think it should give a pretty good rough indication of health. That is all in an edge release ready to go out tonight.

Regards, Mark.

...

On 24 May 2018, at 12:12 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de>> wrote:

Mark,

I introduced this originally, it's meant to be (1), the overall indication of battery health.

As the wikipedia article says, there is no general industry definition on how to calculate this.

On the Twizy, the SOH is given by the BMS, while the CAC is calculated by the OVMS by monitoring the charge process and counting coulombs. The BMS SOH is the (normally invisible) limit for the usable capacity, as the Twizy always shows a range of 0-100% SOC regardless of the SOH. It's also the base for any warranty replacement of the battery (if it's rented you'll get a new one when SOH is below 75%).

The BMS is proprietary and without any available documentation, it's a complete mystery how it calculates the SOH.

While the capacity would normally be the major factor in a SOH, the Twizy BMS (LG Chem) has actually other ideas on this. For example it's been at 100% for the first three years, then at 99% for another two years, while my CAC value showed the actual degradation (long term linear with cycles). It's then begun to drop rapidly over a short period of time and is now close to my CAC level. My cells are still pretty good balanced under load as well as open circuit, the balance also degraded more or less linearly. There are also no obvious temperature indications that could explain the SOH curve.

Generally I recommend to use this for the value the car provides, if any.

If the car doesn't provide an SOH, any calculation that fits…

...

An overall indication of battery health? 100% being perfect, and 0% a brick? …will do.

...

Kia Soul seems to be closest to the implementation I was thinking of. Find out the difference between SOC LIM MIN and LIM MAX, and use that as an indication of imbalance in the pack. But Nissan Leaf seems to be more like (CAC/160)*100 (where 160 is the CAC for a brand new vehicle).

Or should we just add SOC_MIN and SOC_MAX if these are used in many cars? Or an imbalance percentage?

Or should we combine the both (so CAC/160*100 gives us percentage capacity loss, and SOCMAX-SOCMIN/SOCMAX*100 gives us imbalance of the pack, then we perhaps multiply the two together to give an overall indication of health)? If breaking down SOC into the peak min and max cell values I suggest also adding the average and peak standard deviation, plus either the average cell SOC or the number of cells to derive that.

Interior resistance of cells would be another option for standard metrics of cell health, but seems to be rarely available (and needs a reference).

I've got the cell module voltages and temperatures on the Twizy. I record their peak values and deviations under load and calculate the standard deviation. This monitoring shows only a minor difference against the values I recorded five years ago. I'm pretty sure if I also had the internal resistance, that would give a much clearer image.

Regards, Michael

Am 23.05.2018 um 16:42 schrieb Mark Webb-Johnson:

...

What is MS_V_BAT_SOH used for?

For Tesla Roadster, as well as SOC, we have SOC LIM MIN and SOC LIM MAX. I want to make those available.

Kia Soul seems to use:

StdMetrics.ms_v_bat_soh->SetValue( 110 - ( m_b_cell_det_max->AsFloat(0) + m_b_cell_det_min->AsFloat(0)) / 2 );

Nissan Leaf uses:

StandardMetrics.ms_v_bat_soh->SetValue(ah / newCarAh * 100);

Twizy uses:

CAN_BYTE(5) on ID 0x424

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)?

The definition here seems to lean towards #2 (capacity related), but seems arguable:

https://en.wikipedia.org/wiki/State_of_health <https://en.wikipedia.org/wiki/State_of_health> <https://en.wikipedia.org/wiki/State_of_health> <https://en.wikipedia.org/wiki/State_of_health>

State of health (SoH) is a figure of merit of the condition of a battery (or a cell, or a battery pack), compared to its ideal conditions. The units of SoH are percent points (100% = the battery's conditions match the battery's specifications).

Typically, a battery's SoH will be 100% at the time of manufacture and will decrease over time and use. However, a battery's performance at the time of manufacture may not meet its specifications, in which case its initial SoH will be less than 100%.

As SoH does not correspond to a particular physical quality, there is no consensus in the industry on how SoH should be determined. The designer of a battery management system may use any of the following parameters (singly or in combination) to derive an arbitrary value for the SoH.

Internal resistance / impedance / conductance Capacity Voltage[2] Self-discharge Ability to accept a charge Number of charge–discharge cycles

In addition, the designer of the battery management system defines an arbitrary weight for each of the parameter's contribution to the SoH value. The definition of how SoH is evaluated can be a trade secret.

Kia Soul seems to be closest to the implementation I was thinking of. Find out the difference between SOC LIM MIN and LIM MAX, and use that as an indication of imbalance in the pack. But Nissan Leaf seems to be more like (CAC/160)*100 (where 160 is the CAC for a brand new vehicle).

Or should we just add SOC_MIN and SOC_MAX if these are used in many cars? Or an imbalance percentage?

Or should we combine the both (so CAC/160*100 gives us percentage capacity loss, and SOCMAX-SOCMIN/SOCMAX*100 gives us imbalance of the pack, then we perhaps multiply the two together to give an overall indication of health)?

Thoughts?

Regards, Mark

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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: 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

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

How about a new metric type OvmsMetricArrayFloat? Store an array of floats. If accessed as a string, returns it comma-separated. Regards, Mark.

On 26 May 2018, at 2:30 PM, Michael Balzer <dexter@expeedo.de> wrote:

Btw:

Am 25.05.2018 um 22:42 schrieb Michael Balzer:

...

OVMS# me li xrt.b.

To creare array like metrics without wasting RAM for the names, have a look at my script gen_metrics_names.sh (in twizy/tools).

But don't try to add 100 cell metrics while the metrics are still in internal RAM, that won't work.

Regards, Michael

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev