[Ovmsdev] Battery capacity metrics (for the Leaf, and in general)

Anko Hanse anko_hanse at hotmail.com
Sun Mar 3 13:08:49 HKT 2019

I mixed up my 1.x numbering examples. 
FlipTheFleet actually only uses Gen 1.3 for the 30kwh models, the 24kwh are Gen 1.1 or 1.2

-----Original Message-----
From: Anko Hanse <anko_hanse at hotmail.com> 
Sent: Sunday, 3 March 2019 5:53 PM
To: Robin O'Leary <ovmsdev at caederus.org>; ovmsdev at lists.openvehicles.com
Subject: RE: [Ovmsdev] Battery capacity metrics (for the Leaf, and in general)

Just a remark about the naming of your constants.

The numbering of the generations is always confusing. We are used to Gen1, Gen2, etc for the 2011-2017 models. 
But Nissan itself seems to consistently call all of these Gen1 and only starts Gen2 at 2018. The confusion will even increase more whenever they will introduce a Gen3 in 202x...

Some, like FlipTheFleet, use a different naming scheme, more consistent with Nissan:

Gen 1.1   2011-2012, 24kwh
Gen 1.2   2013-2015, 24kwh
Gen 1.3   2016-2017, 24kwh or 30kwh
Gen 2.1   2018-

Others do not distinguish between 2013-2017 24 kwh models:

Gen 1.1   2011-2012, 24kwh
Gen 1.2   2013-2017, 24kwh
Gen 1.3   2016-2017, 30kwh
Gen 2.1   2018-

I do not have a preference myself, other than call anything before 2018 an Gen1.x and as of 2018 a Gen2. Using Gen2 for earlier models will lead to confusion/trouble later on...

Initial test with your ' leaf-chargetime' code looks good on my 30kwh Leaf (after a short drive):
xnl.v.b.type = 2
xnl.v.c.duration = 60;135;195Min      (only 'full', no 'range' values on my model)

Will check again during a slow charge. Quick charges are very rare for me...

-----Original Message-----
From: Robin O'Leary <ovmsdev at caederus.org> 
Sent: Sunday, 3 March 2019 12:27 PM
To: ovmsdev at lists.openvehicles.com
Subject: Re: [Ovmsdev] Battery capacity metrics (for the Leaf, and in general)

On Tue, Feb 26, 2019 at 10:54:23AM +0000, Robin O'Leary wrote:
> On Tue, Feb 26, 2019 at 05:29:18AM +0000, Anko Hanse wrote:
> > Bad news: the xnl.v.c.duration.range still are at 4095min for me, even though the SOC has now dropped below 80%. This is on a Dec-2015 30kwh model.
> ...I'll add a check to ignore '4095' as an invalid value  ...

I have added this check so such values are ignored.

As Mark commented, having 6 different charge duration estimates seemed a bit unwieldy, so I have combined them in to a vector "xnl.v.c.duration"
with 6 elements (which are labelled in the corresponding string vector "xnl.v.c.duration.label").

I noticed some other interesting things about 0x5bc:

The multiplex contains an extra value in index 0 while quick charge is in progress.  I added this as new metric "xnl.v.c.quick".
It seems more complicated than a simple estimate of minutes like the others; I haven't exactly figured it out yet.

It looks like Gen1 and Gen1 batteries report the charge duration estimates using different multiplex index values.  I had the idea that we could use this to identify the battery type, which I report in a new metric

	0	Gen1	24kWh
	1	Gen2	24kWh
	2	Gen2	30kWh

The size comes from the length of the PollReply_Battery() active request, so that only works when the car is on (ready to drive).

Another value present in 0x5bc is the SOC% value which we currently report as soc.instrument and default to showing as the standard SOC metric.
However, this value is not present on earlier models.  Looking for an alternative, there is another SOC%-like value in 0x5bb, which I have added as new metric "xnl.v.b.soc.nominal".
On my 2015 24kWh, soc.nominal is more erratic than soc.instrument, and can be different by a couple of percentage points, e.g. often showing 97% when soc.instrument shows 100% at the end of a charge.  Even so, the two are usually pretty close, and soc.nominal may be a better choice if it works for all models, so feedback would be welcome.

These changes are in branch:

Could people with older/newer/different capacity batteries let me know if these metrics seem correct, and if not, collect some logs?  Thanks.

More information about the OvmsDev mailing list