This is related to feature requests #180 and #181 (automatic detection of model-year and battery size). For USA and EU style VINs we might have a method of deriving the year and battery size. Unfortunately cars made for the Japanese Domestic Market and frequently imported 2nd hand into Australia and New Zealand do not use a VIN but instead have some sort of serial number in the form of ZE0-123456 or AZE0-123456. I have posted a request on a NZ forum (www.geekzone.co.nz<http://www.geekzone.co.nz/>) for people to email me their JDM style VIN combined with year (and possibly month) and battery size. Note that LeafSpy-Pro also toggles with another VIN-like number, I'm interested in that too if people can get it. If not then just the ZE0- or AZE0- number is fine... Possibly any NZ OVMS users seeing this post can do the same and also email me those details or reply here. For privacy reasons I would suggest to mask the lowest digits of your VINs, i.e: AZE0-2003xx, Dec 2015, 30kwh, 230JT11122000xxx Hopefully that will give us some new insights... I very much hope our collective powers can confirm that ZE0-1xxxxx and AZE0-1xxxxx is 24kwh, AZE0-2xxxxx is 30kwh, AZE1-1xxxxx is 40kwh and possibly AZE1-2xxxxx will be 62kwh :-)
On Sat, Feb 23, 2019 at 07:01:33AM +0000, Anko Hanse wrote:
This is related to feature requests #180 and #181 (automatic detection of model-year and battery size).
... Note that LeafSpy-Pro also toggles with another VIN-like number, I'm interested in that too if people can get it.
That other number reported by LeafSpy is the HVBATT serial number, obtained from UDS query 0x79b.2184, reply from 0x7bb.6184. Here is a patch to implement that query (when the car is ready to drive) and report it as "xnl.v.b.serial": https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-...
If not then just the ZE0- or AZE0- number is fine... Possibly any NZ OVMS users seeing this post can do the same and also email me those details or reply here. For privacy reasons I would suggest to mask the lowest digits of your VINs, i.e:
AZE0-2003xx, Dec 2015, 30kwh, 230JT11122000xxx
Hopefully that will give us some new insights... I very much hope our collective powers can confirm that ZE0-1xxxxx and AZE0-1xxxxx is 24kwh, AZE0-2xxxxx is 30kwh, AZE1-1xxxxx is 40kwh and possibly AZE1-2xxxxx will be 62kwh :-)
Here are two results I have observed: 2015 24kWh UK SJNFAAZE0U60xxxxx 230UK114BM0xxxxx 2018 40kWh UK SJNFAAZE1U00xxxxx 230UK1189A0xxxxx Although it's interesting to know if there are deeper meanings in VIN or battery version numbers, I think we should avoid making the code depend on such indirect deductions. The xnl.modelyear config parameter only affects how we start the TCU, by sending either a 1-byte message on CAN1 for 2012--2015 or a 4-byte message on CAN2 for 2016 onwards. I suspect it does no harm to send both messages regardless, in which case, we could simply scrap the model year distinction. And if we really do want to take care only to send the correct message for the current model, can we perhaps more safely determine this automatically by watching which bus sees TCU traffic?
Prompted by the recent discussion about auto-detecting Leaf battery pack size, I was looking at the somewhat convoluted way the Leaf code is currently dealing with battery charge level and capacity to see why it was thought necessary in the first place. The Leaf's BMS gives us both an estimate of battery energy currently available (which we quaintly called "xnl.v.b.gids" and didn't convert to standard units), and estimated total battery energy capacity (which wasn't available at all). Perhaps this was discouraged by the lack of standard metrics for energy (*), which I find this quite surprising, given that these two values are so useful in basic calculations like: range = (energy available) / (driving efficiency) or charge time = (energy capacity - available) / (charge rate) So here is a pull request to expose those values as Leaf-specific metrics: m_battery_energy_capacity Float "xnl.v.b.e.capacity" kWh m_battery_energy_available Float "xnl.v.b.e.available" kWh https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/206 But I would go further and suggest that these deserve to be standard metrics so other vehicle modules can also report their own equivalent values. My hope is that we can then start improving the accuracy of range and charge time estimates for all vehicles; most already attempt one or both in their own ways, some more sophisicated than others. At least basing everything on standard energy units means there is a better chance that work already done by one model might be useful to another. -- (*) The only related standard metric I can see is ms_v_bat_cac, which is a measure of battery charge capacity (in Amp.hours), rather than energy. Although closely related, charge is less convenient to work with, as most calculations will also need to account for varying pack voltage.
Well done, the best possible solution! I had been searching for a way to directly get the battery capacity from the can bus, but had not found one. Hence my search for alternatives via the VIN. Even if I do a google now on 'leaf can bus 59e' I don't get useful hits. And no finds in the canmsgs google docs either... Makes me wonder what docs you have access to... Your solution means we could now completely get rid of the max_gids setting, and rework the code to use m_battery_energy_capacity instead. Also agree with your comment to remove the need for the modelyear setting by either just sending 2 command messages to the TCU or analysing its behaviour prior to sending the commands. As for the web-interface, we might want to still display the detected battery capacity there, just not as a changeable setting but as readonly info. -----Original Message----- From: Robin O'Leary <ovmsdev@caederus.org> Sent: Sunday, 24 February 2019 12:42 PM To: OVMS Developers <ovmsdev@lists.openvehicles.com> Subject: [Ovmsdev] Battery capacity metrics (for the Leaf, and in general) Prompted by the recent discussion about auto-detecting Leaf battery pack size, I was looking at the somewhat convoluted way the Leaf code is currently dealing with battery charge level and capacity to see why it was thought necessary in the first place. The Leaf's BMS gives us both an estimate of battery energy currently available (which we quaintly called "xnl.v.b.gids" and didn't convert to standard units), and estimated total battery energy capacity (which wasn't available at all). Perhaps this was discouraged by the lack of standard metrics for energy (*), which I find this quite surprising, given that these two values are so useful in basic calculations like: range = (energy available) / (driving efficiency) or charge time = (energy capacity - available) / (charge rate) So here is a pull request to expose those values as Leaf-specific metrics: m_battery_energy_capacity Float "xnl.v.b.e.capacity" kWh m_battery_energy_available Float "xnl.v.b.e.available" kWh https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/206 But I would go further and suggest that these deserve to be standard metrics so other vehicle modules can also report their own equivalent values. My hope is that we can then start improving the accuracy of range and charge time estimates for all vehicles; most already attempt one or both in their own ways, some more sophisicated than others. At least basing everything on standard energy units means there is a better chance that work already done by one model might be useful to another. -- (*) The only related standard metric I can see is ms_v_bat_cac, which is a measure of battery charge capacity (in Amp.hours), rather than energy. Although closely related, charge is less convenient to work with, as most calculations will also need to account for varying pack voltage.
On Sun, Feb 24, 2019 at 05:34:21AM +0000, Anko Hanse wrote:
I had been searching for a way to directly get the battery capacity from the can bus, but had not found one. Hence my search for alternatives via the VIN. Even if I do a google now on 'leaf can bus 59e' I don't get useful hits. And no finds in the canmsgs google docs either... Makes me wonder what docs you have access to...
I have no documentation; everything is speculation, based on many forum discussions and my own observations of the car I own (a 2015 UK-built 24kWh Acenta), so it is quite possible that my conclusions are wrong, or don't apply to other models. I would like others to check whether the value in 0x59e is a useful measure of capacity for them before we adopt it as a standard. ...
As for the web-interface, we might want to still display the detected battery capacity there, just not as a changeable setting but as readonly info.
Yes, although these are two different things, which may both be useful for different purposes. Unlike the fixed value of max_gids, the battery energy capacity metric varies over time: as well as a general decrease due to battery age, it also has short-term up and down swings as the BMS recalibrates after charging. Some people don't like this "randomness", and prefer to see calculations relative to a fixed base-line. There is something to be said for both approaches. As for the config page, for now, I would suggest structuring it so that the switches for the preferred SOC and SOH display metrics are paired with conditional settings for the corresponding full-scale value, maybe something like: SOC display: {xnl.soc.newcar} . (*) from dashboard display {=false} . ( ) relative to fixed value: {=true} . . [ ] (GID=80kWh) {xnl.maxGids} SOH display: {xnl.soh.newcar} . (*) from dashboard display {=false} . ( ) relative to fixed value: {=true} . . [ ] (amp.hour) {xnl.newCarAh}
Robin, pulled your code and did a quick test: xnl.v.b.e.available 21.76kWh xnl.v.b.e.capacity 20.8kWh xnl.v.b.gids 272 xnl.v.b.hx 79.59 xnl.v.b.soc.instrument 82% xnl.v.b.soc.newcar 76.4045% xnl.v.b.soh.instrument 92% xnl.v.b.soh.newcar 92.7% xnl.v.c.duration.full.l0 210Min xnl.v.c.duration.full.l1 90Min xnl.v.c.duration.full.l2 60Min xnl.v.c.duration.range.l0 4095Min xnl.v.c.duration.range.l1 4095Min xnl.v.c.duration.range.l2 4095Min 1. the xnl.v.b.e.capacity=20.8kwh does really not seem right for a 30kwh Leaf on 92% SOH... I'll give it another go after I have actually driven for a bit (now just tested in Drive-Mode, but parked). 2. Since my SOC.instrument was above 80%, the xnl.v.c.duration.range.l0 - l2 give a strange value that might have the meaning of 'Not Applicable'. You probably need to test on that value and set the time to 0 min instead. Apart from that I agree with your proposal for the config of xnl.soc.newcar, xnl.soh.newcar, xnl.maxGids and xnl.newCarAh. I will not pickup implementing that before we have more certainty on the energy capacity metric. -----Original Message----- From: Robin O'Leary <ovmsdev@caederus.org> Sent: Monday, 25 February 2019 2:08 AM To: OVMS Developers <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] Battery capacity metrics (for the Leaf, and in general) On Sun, Feb 24, 2019 at 05:34:21AM +0000, Anko Hanse wrote:
I had been searching for a way to directly get the battery capacity from the can bus, but had not found one. Hence my search for alternatives via the VIN. Even if I do a google now on 'leaf can bus 59e' I don't get useful hits. And no finds in the canmsgs google docs either... Makes me wonder what docs you have access to...
I have no documentation; everything is speculation, based on many forum discussions and my own observations of the car I own (a 2015 UK-built 24kWh Acenta), so it is quite possible that my conclusions are wrong, or don't apply to other models. I would like others to check whether the value in 0x59e is a useful measure of capacity for them before we adopt it as a standard. ...
As for the web-interface, we might want to still display the detected battery capacity there, just not as a changeable setting but as readonly info.
Yes, although these are two different things, which may both be useful for different purposes. Unlike the fixed value of max_gids, the battery energy capacity metric varies over time: as well as a general decrease due to battery age, it also has short-term up and down swings as the BMS recalibrates after charging. Some people don't like this "randomness", and prefer to see calculations relative to a fixed base-line. There is something to be said for both approaches. As for the config page, for now, I would suggest structuring it so that the switches for the preferred SOC and SOH display metrics are paired with conditional settings for the corresponding full-scale value, maybe something like: SOC display: {xnl.soc.newcar} . (*) from dashboard display {=false} . ( ) relative to fixed value: {=true} . . [ ] (GID=80kWh) {xnl.maxGids} SOH display: {xnl.soh.newcar} . (*) from dashboard display {=false} . ( ) relative to fixed value: {=true} . . [ ] (amp.hour) {xnl.newCarAh}
Robin, Good news: retested after a drive and the xnl.v.b.e.available corrected itself to the expected 30kwh ! Will keep an eye on it over the next weeks to make sure it is not one of these multiplexed thingies that switches in and out of the expected value.... 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 trace to see what data I receive in the 0x5bc message... xnl.bms.temp_int 21,23,255,23,21,0°C xnl.bms.thermistor 498,480,65535,480 xnl.v.b.e.available 30kWh xnl.v.b.e.capacity 20.8kWh xnl.v.b.gids 375 xnl.v.b.hx 79.17 xnl.v.b.soc.instrument 64% xnl.v.b.soc.newcar 105.337% xnl.v.b.soh.instrument 91% xnl.v.b.soh.newcar 92.4887% xnl.v.c.count.l0l1l2 166 xnl.v.c.count.qc 255 xnl.v.c.duration.full.l0 375Min xnl.v.c.duration.full.l1 135Min xnl.v.c.duration.full.l2 90Min xnl.v.c.duration.range.l0 4095Min xnl.v.c.duration.range.l1 4095Min xnl.v.c.duration.range.l2 4095Min -----Original Message----- From: Anko Hanse Sent: Monday, 25 February 2019 7:29 PM To: 'Robin O'Leary' <ovmsdev@caederus.org>; OVMS Developers <ovmsdev@lists.openvehicles.com> Subject: RE: [Ovmsdev] Battery capacity metrics (for the Leaf, and in general) Robin, pulled your code and did a quick test: xnl.v.b.e.available 21.76kWh xnl.v.b.e.capacity 20.8kWh xnl.v.b.gids 272 xnl.v.b.hx 79.59 xnl.v.b.soc.instrument 82% xnl.v.b.soc.newcar 76.4045% xnl.v.b.soh.instrument 92% xnl.v.b.soh.newcar 92.7% xnl.v.c.duration.full.l0 210Min xnl.v.c.duration.full.l1 90Min xnl.v.c.duration.full.l2 60Min xnl.v.c.duration.range.l0 4095Min xnl.v.c.duration.range.l1 4095Min xnl.v.c.duration.range.l2 4095Min 1. the xnl.v.b.e.capacity=20.8kwh does really not seem right for a 30kwh Leaf on 92% SOH... I'll give it another go after I have actually driven for a bit (now just tested in Drive-Mode, but parked). 2. Since my SOC.instrument was above 80%, the xnl.v.c.duration.range.l0 - l2 give a strange value that might have the meaning of 'Not Applicable'. You probably need to test on that value and set the time to 0 min instead. Apart from that I agree with your proposal for the config of xnl.soc.newcar, xnl.soh.newcar, xnl.maxGids and xnl.newCarAh. I will not pickup implementing that before we have more certainty on the energy capacity metric. -----Original Message----- From: Robin O'Leary <ovmsdev@caederus.org> Sent: Monday, 25 February 2019 2:08 AM To: OVMS Developers <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] Battery capacity metrics (for the Leaf, and in general) On Sun, Feb 24, 2019 at 05:34:21AM +0000, Anko Hanse wrote:
I had been searching for a way to directly get the battery capacity from the can bus, but had not found one. Hence my search for alternatives via the VIN. Even if I do a google now on 'leaf can bus 59e' I don't get useful hits. And no finds in the canmsgs google docs either... Makes me wonder what docs you have access to...
I have no documentation; everything is speculation, based on many forum discussions and my own observations of the car I own (a 2015 UK-built 24kWh Acenta), so it is quite possible that my conclusions are wrong, or don't apply to other models. I would like others to check whether the value in 0x59e is a useful measure of capacity for them before we adopt it as a standard. ...
As for the web-interface, we might want to still display the detected battery capacity there, just not as a changeable setting but as readonly info.
Yes, although these are two different things, which may both be useful for different purposes. Unlike the fixed value of max_gids, the battery energy capacity metric varies over time: as well as a general decrease due to battery age, it also has short-term up and down swings as the BMS recalibrates after charging. Some people don't like this "randomness", and prefer to see calculations relative to a fixed base-line. There is something to be said for both approaches. As for the config page, for now, I would suggest structuring it so that the switches for the preferred SOC and SOH display metrics are paired with conditional settings for the corresponding full-scale value, maybe something like: SOC display: {xnl.soc.newcar} . (*) from dashboard display {=false} . ( ) relative to fixed value: {=true} . . [ ] (GID=80kWh) {xnl.maxGids} SOH display: {xnl.soh.newcar} . (*) from dashboard display {=false} . ( ) relative to fixed value: {=true} . . [ ] (amp.hour) {xnl.newCarAh}
On Tue, Feb 26, 2019 at 05:29:18AM +0000, Anko Hanse wrote:
Good news: retested after a drive and the xnl.v.b.e.available corrected itself to the expected 30kwh ! Will keep an eye on it over the next weeks to make sure it is not one of these multiplexed thingies that switches in and out of the expected value....
Thanks for the feedback; it is interesting. It gives me confidence that xnl.v.b.e.available is useful for both battery sizes, but unfortunately xnl.v.b.e.capacity is not. We should continue looking for something better in the voluminous data returned by 79b/7bb queries.
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.
Does your car offer the option to turn "Long life mode (80% charge)" on and off? If that is not implemented, it would make sense that the corresponding estimates are not either. I'll add a check to ignore '4095' as an invalid value ...which reminds me of a coding question I've been meaning to ask those more familiar with the "metrics" mechanism: The vehicle modules, including the leaf, create their own metrics with code like this: m_charge_duration_full_l2 = MyMetrics.InitFloat("xnl.v.c.duration.full.l2", SM_STALE_HIGH, 0, Minutes); However, this also sets an initial value, which may give the false impression of knowledge where none exists (as with the 30kWh "range" estimates). Standard metrics are created differently, with no initial value: ms_v_charge_duration_full = new OvmsMetricInt(MS_V_CHARGE_DURATION_FULL, SM_STALE_MID, Minutes); Is there any reason why vehicle modules shouldn't also do it this way, leaving metrics in state NeverDefined until a real value is known?
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 "xnl.v.b.type": 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: https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-... Could people with older/newer/different capacity batteries let me know if these metrics seem correct, and if not, collect some logs? Thanks.
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... P.S. 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@caederus.org> Sent: Sunday, 3 March 2019 12:27 PM To: ovmsdev@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 "xnl.v.b.type": 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: https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-... Could people with older/newer/different capacity batteries let me know if these metrics seem correct, and if not, collect some logs? Thanks.
Correction: 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@hotmail.com> Sent: Sunday, 3 March 2019 5:53 PM To: Robin O'Leary <ovmsdev@caederus.org>; ovmsdev@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... P.S. 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@caederus.org> Sent: Sunday, 3 March 2019 12:27 PM To: ovmsdev@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 "xnl.v.b.type": 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: https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-... Could people with older/newer/different capacity batteries let me know if these metrics seem correct, and if not, collect some logs? Thanks.
On Sun, Mar 03, 2019 at 04:53:08AM +0000, Anko Hanse wrote:
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...
Hopefully there is limited scope for confusion, as naming them "enum battery_type" and "BATTERY_TYPEn..." should make clear they relate only to the battery, not the car as a whole, or model year. On reflection though, I think the naming could be simplified by not conflating the type (as it strictly relates to CAN bus communication format), with the capacity. Then the types may as well just be numbers 0,1,2... as they are reported in "xnl.v.b.type" with no deeper meaning. It is then tempting to add 1 to the enum values so they match this:
Gen 1.1 2011-2012, 24kwh Gen 1.2 2013-2017, 24kwh Gen 1.3 2016-2017, 30kwh
...
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)
Great! Do you get a sensible value in xnl.v.b.soc.nominal?
Yes soc.nominal seems to behave correctly on my 30kwh model: xnl.v.b.soc.instrument = 79% xnl.v.b.soc.newcar = 105.337% (I often see gids = 375 which is above the maxgids = 357....) xnl.v.b.soc.nominal = 75.1% After updating the module with your code (resulting in a reset of the metrics, I did again see: xnl.v.b.e.available = 22.4kwh Then a very short drive (<2km): xnl.v.b.e.available = 26.64kwh And after some more driving it corrected itself again to: xnl.v.b.e.available = 30kwh -----Original Message----- From: Robin O'Leary <ovmsdev@caederus.org> Sent: Monday, 4 March 2019 3:35 AM To: Anko Hanse <anko_hanse@hotmail.com> Cc: ovmsdev@lists.openvehicles.com Subject: Re: [Ovmsdev] Battery capacity metrics (for the Leaf, and in general) On Sun, Mar 03, 2019 at 04:53:08AM +0000, Anko Hanse wrote:
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...
Hopefully there is limited scope for confusion, as naming them "enum battery_type" and "BATTERY_TYPEn..." should make clear they relate only to the battery, not the car as a whole, or model year. On reflection though, I think the naming could be simplified by not conflating the type (as it strictly relates to CAN bus communication format), with the capacity. Then the types may as well just be numbers 0,1,2... as they are reported in "xnl.v.b.type" with no deeper meaning. It is then tempting to add 1 to the enum values so they match this:
Gen 1.1 2011-2012, 24kwh Gen 1.2 2013-2017, 24kwh Gen 1.3 2016-2017, 30kwh
...
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)
Great! Do you get a sensible value in xnl.v.b.soc.nominal?
On 23/02/19 8:01 PM, Anko Hanse wrote:
Hopefully that will give us some new insights... I very much hope our collective powers can confirm that ZE0-1xxxxx and AZE0-1xxxxx is 24kwh, AZE0-2xxxxx is 30kwh, AZE1-1xxxxx is 40kwh and possibly AZE1-2xxxxx will be 62kwh :-)
I have a model year 2016 24kWh JDM which reports AE0-20xxxx in OVMS. This suggests the leading 2 indicates the 2016 model year redesign rather than the 30kWh battery.
Indeed, that is also what I see in the responses I have gathered so far: ZE0- 2011-2012, 24kwh AZE0-0 and AZE0-1 2013-2015, 24kwh AZE0-2 2016-2017, 24 or 30kwh (starting production late 2015) ZE1- 2018-now 40kwh (and probably also 60kwh from 2019 onward) That the AZE0-2 VINs contain both 24 and 30kwh models is further confirmed by this site I received from a helpful person on Geekzone.co.nz: https://www.japan-partner.com/check-manufacture-year.php Try out some random VINS starting with AZE0-2, and you will get both 24kwh and 30kwh results (although they seem to be produced in batches) So the JDM style VIN can not be used to determine battery size. It can only be used as an indication of model year groups (but then you will also need to get similar groupings for UK and USA style VINs). An Auckland based EV battery specialist suggested to me that the LBC Part Numbers (as returned by a poll to 0x79b with pid 0x83) might be our most reliable bet to distinguish pre-2016 models from later models. For example the part numbers for the LBC are 293A0-3NA0D for a 2011-2012 (3NA0A and 3NA0B also seem to have existed but should all have been replaced by the 3NA0D fix by now) 293A0-????? for a 2013-2015 (to be determined) 293A0-4NN0A for a 2016-2017 293A0-????? For a 2018- (to be determined, but also do not need to know) These numbers do not seem to differ between JDM, USA or UK made cars. And we only need to recognize the 2011-2015 ones so we know to send the 1 byte command over bus1, all others have the 4 byte command over bus2. So no code changes expected when new models come out. A remaining issue is to decide what component to get the Part Number from. Possibly the Batter Control is not the right one. For commands to the Climate Control you would want to identify the Climate Control (is that the TCU ?). For lock/unlock you would want to identify whatever module handles those. But maybe the LBC or the VCM Part Number is good enough... The part numbers are documented by Nissan on pages like (for the ZE0-): https://nissan.7zap.com/en/er/leaf/ze0/1+1011+65535/e/291/ From: Tom Parker <tom@carrott.org> Sent: Tuesday, 26 February 2019 6:51 AM To: ovmsdev@lists.openvehicles.com Subject: Re: [Ovmsdev] Callout for JDM Nissan Leaf VINs On 23/02/19 8:01 PM, Anko Hanse wrote: Hopefully that will give us some new insights... I very much hope our collective powers can confirm that ZE0-1xxxxx and AZE0-1xxxxx is 24kwh, AZE0-2xxxxx is 30kwh, AZE1-1xxxxx is 40kwh and possibly AZE1-2xxxxx will be 62kwh :-) I have a model year 2016 24kWh JDM which reports AE0-20xxxx in OVMS. This suggests the leading 2 indicates the 2016 model year redesign rather than the 30kWh battery.
participants (3)
-
Anko Hanse -
Robin O'Leary -
Tom Parker