[Ovmsdev] Leaf 2016 30Kwh flapping SOC

[Mark Webb-Johnson]

My 2c:

This seems to be a hot topic amongst Nissan Leaf owners. Am I correct in that the displayed SOC doesn’t show degradation?

In general, OVMS has tried to remotely show exactly what was on the car dashboard. We went to some extreme lengths in the original Tesla Roadster code to meet that requirement (for example the km/miles conversions were not accurate in the car implementation, so we tried to mimic the car’s inaccurate algorithm in our approach).

Absolutely no objection to adding vehicle specific metrics. A GID value (for Nissan Leaf) is the obvious example, but also other indications of battery health. We have SOC%, SOH%, and CAC currently as global metrics.

Regards, Mark.

> On 2 May 2018, at 6:41 AM, Robin O'Leary <ovmsdev at caederus.org> wrote:
> 
> On Wed, May 02, 2018 at 07:39:57AM +1200, Tom Parker wrote:
>> We can make the SOC calculation configurable so that you can choose to use
>> the instrument panel SOC or an SOC based on the new car battery size. When I
>> took over the leaf support I wanted to use the instrument panel soc too, see
>> Tom Saxton's reply which convincingly dissuaded me wanting to switch:
>> http://lists.openvehicles.com/pipermail/ovmsdev/2016-May/002993.html (this
>> discussion that was before I knew SOC was available so I had some no longer
>> relevant ideas about how to actually implement it).
>> 
>> Now we have the easier to configure v3 platform and more users wanting to
>> use the instrument panel SOC I'll make it configurable. I should be able to
>> get that done tonight.
> 
> This picks up on the same discussion we started earlier when I tried to
> make the same change.  But we seem to be arguing as if there has to be
> one ideal metric, when we really need several of different metrics for
> different purposes.
> 
> There is utility in having a vehicle metric for the dash SOC% because that
> is how the car reports on progress during charging---it's going to stop at
> 100% (or 80%) and slow down in a predictable way at the number increases.
> 
> There is also utility in having another vehicle metric which represents
> the amount of available energy in the battery---though I see no good
> reason why that should be expressed as a percentage of some arbitrary
> number I've had to set in the first place; it seems fundamentally better
> to use a standard unit like kWh.  Is there a metric for that already?
> 
> Once we know available energy, we can derive other useful things like
> estimated range, and those calculations can be vehicle-independent,
> because they just use values in standard units like kWh, W/km etc.
> It seems much more reasonable for this to be where the user can choose
> to apply their own scaling preferences, rather than having that in the
> code for any specific vehicle.
> 
>>> And now to a different thing:
>>> 
>>> The app supports unlocking and locking of doors. The feature doesn't seem
>>> to be implemented for the Nissan Leaf.
>>> 
>>> I have all the CAN-codes needed to make this work. Please let me know if I
>>> can contribute.
>> 
>> I'm uncomfortable doing this on my own car, but I'm very happy to have the
>> feature implemented. I think it should be hidden behind a configuration
>> option, so you can choose whether the standard functionality allows the car
>> to be unlocked, but that is a different and not Leaf specific conversation.
> 
> Yes, I'm also not sure I would always want this enabled, so it would be
> good to have a config option to enable it, but it's something I would
> like to help work on.
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev