[Ovmsdev] Leaf 2016 30Kwh flapping SOC

Robin O'Leary ovmsdev at caederus.org
Sun May 6 20:43:19 HKT 2018

On Thu, May 03, 2018 at 10:51:07PM +1200, Tom Parker wrote:
> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/110
> ... I also grabbed the instrument SOC from 0x1db and swapped
> the default source of the main SOC metric. What do you think?

The more I look at it, the more I'm going off the idea of having multiple
alternative sources of data and an option of which to promote to the
"standard" metric.  I think we must try follow Mark's original
objective to make the standard SOC metric show what is on the dash;
if we want a better metric representing absolute energy (which I do),
then there should be a different metric for that (and, indeed, there may
be more than one, such as KWh, GIDs, percent of new---though I would
suggest only kWh deserves to be a standard metric, while the others
would remain vehicle specific).

What particularly got me thinking along these lines is that I have been
reading some other metrics directly from the Leaf's own instruments,
like the distance range and time-to-charge estimates, and again I have
the problem of where to put them.  There is already code to calculate
these values independently, and I am sure some people will again prefer
the results of those calulations over the car's "guess-o-meter".  But it
seems increasingly ridiculous to repeat the same pattern for every one
(having two local metrics and a config option for which to display).
Surely the job of the vehicle code is just to accurately report what
the car says.

If we want to calculate better estimates, that doesn't seem to belong
in each vehicle module.  For example, both the Kia Soul and Twizy have
code to apply a temperature correction to the range, but they do it
differently.  Which way is better?  Is that really a vehicle-specific
difference, or is it just two independent tries at solving the same
tricky problem?  I suspect the latter, and that should be done in a more
centralized place where better techniques can be shared and more easily
fine tuned.

Would I be right to think that the original justification for making the
SOC behaviour configurable is so the scaled-to-new-SOC can be seen on
the phone app?   If so, then maybe what we are really missing is a way
to customise which metric(s) should be displayed on the phone app (and
perhaps other user interfaces like the web status page and dashboard,
which may have different capablilites).  Looking at a way to add that
seems like a better way to go than trying to narrowly solve each display
selection issue one by one in the vehicle code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180506/ebbb6a96/attachment-0002.sig>

More information about the OvmsDev mailing list