<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">Am 16.05.2018 um 14:56 schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:55A24900-5F22-43B5-BDFA-89B61E97CD0A@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
The original intent of that metric was to provide an estimate for
the charge time remaining on the current charge. That is why it
was cleared at the end of the charge.</blockquote>
<br>
This original intent of the three "minsremaining" car variables
wasn't documented and in my opinion is unnecessarily restricted. The
variables have been fully under control of the vehicle modules
before, and there were no separate car variables for a general
charge time prediction, so I have been using them in that more
general way.<br>
<br>
Using them in that way provides a continuous configurable charge
time estimation for the user.<br>
<br>
During an actual charge, the estimates can be done for the current
charger capabilities. During driving and parking, I use the charge
current limit configured by the user. That is configured as the
current level at the battery, so the input voltage doesn't matter.<br>
<br>
That way the user can for example check how long a charge at reduced
current level of i.e. a camping lot would take by simply setting the
charge current accordingly. The Android App displays the charge time
estimations at the bottom of the battery page, so getting an updated
estimation is a matter of three clicks.<br>
<br>
I always calculate and show all three times (full, sufficient range,
sufficient SOC), so the user can set the charge limits for the next
part of the route and/or the return to home and still see how long a
full charge would take.<br>
<br>
While supporting more than one range estimation would be nice, it
now already is perfectly sufficient for every day use, as you can
easily adjust the destination levels to check the times for other
routes.<br>
<br>
Being able to provide parallel estimations of multiple charge
destination levels for a set of user defined standard chargers would
be nice, but can overload the user with information and/or
configuration.<br>
<br>
The most user friendly solution would be using the OpenChargeMap
data on charge station capabilities to automatically provide all
estimations for all chargers currently in reach. The user still
would need a way to configure some standard chargers for cases not
covered by the OCM.<br>
<br>
But for now, setting one charger capability by setting the charge
current limit is already sufficient and convenient and doesn't
require too much interaction from the user.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<blockquote type="cite"
cite="mid:55A24900-5F22-43B5-BDFA-89B61E97CD0A@webb-johnson.net">
<div class="">The estimation of charge time remaining is
non-trivial. It depends on a large set of factors (such as
target SOC, temperature, charge mode, charge power, and
fundamentally the proprietary ramp up/down algorithm of the
vehicle manufacturer). To come up with the predictor for the
Tesla Roadster, we gathered several years worth of charging
records, from hundreds of different cars in the field in
different charging environments (powers, modes, temperatures,
etc). Tom then came up with a model to try to predict the charge
time behaviour, and then tested the model against the real world
data we had. It was pretty cool.</div>
<div class=""><br class="">
</div>
<div class="">I think there is certainly more that algorithm could
be used for, but it is Tesla Roadster specific.</div>
<div class=""><br class="">
</div>
<div class="">Perhaps what we need is a generic interface in
vehicle.{h, cpp} for a charge time predictor. Something like:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class=""><font class="" face="Andale Mono">int
OvmsVehicle::MinutesToCharge(</font></div>
<div class=""><font class="" face="Andale Mono"> Chargemode,</font></div>
<div class=""><font class="" face="Andale Mono"> Watts,</font></div>
<div class=""><font class="" face="Andale Mono"> StartSOC or
StartRange,</font></div>
<div class=""><font class="" face="Andale Mono"> TargetSOC or
TargetRange,</font></div>
<div class=""><font class="" face="Andale Mono"> Temperature)</font></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Individual vehicle modules could then implement that
as best they could (a simplistic implementation being just based
on battery kWh * (TargetSoc-StartSoc)/100). We could then
generically use it to show estimates for various scenarios, etc.
Along the lines of what Robin is talking about below.</div>
<div class=""><br class="">
</div>
<div class="">But for this specific metric
(MS_V_CHARGE_DURATION_FULL), that is intended to be an
indication for how long the current charge will take to
complete, and nothing more. Once the current charge is complete
(targetSOC reached), it should be cleared. If the charge is
interrupted, but the charger still connected, there is an
argument for it to remain visible (to show how long it will take
should the charge be resumed).</div>
<div class=""><br class="">
</div>
<div class="">The other two (MS_V_CHARGE_DURATION_RANGE
and MS_V_CHARGE_DURATION_SOC, derived
from MS_V_CHARGE_LIMIT_RANGE and MS_V_CHARGE_LIMIT_SOC) are a
historical relic in the conversion from v2 -> v3, and should
probably go. There are better ways of doing that.</div>
<div class=""><br class="">
</div>
<div class="">But, the question is how can we make this generic? I
really want things to work the same across as many vehicle types
as possible - keeping the implementation of vehicle support as
simple as possible.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 16 May 2018, at 6:17 PM, Robin O'Leary
<<a href="mailto:ovmsdev@caederus.org" class=""
moz-do-not-send="true">ovmsdev@caederus.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">On Wed, May 16, 2018 at 08:19:13AM +0800,
Mark Webb-Johnson wrote:<br class="">
<blockquote type="cite" class="">If we don’t know
current + voltage available from the charger, then<br
class="">
how can we predict charge time? Or is the current +
voltage for the<br class="">
Twizy always the same (fixed?).<br class="">
</blockquote>
<br class="">
It's still useful to show charge time estimate(s) even
when charging<br class="">
isn't in progress. We can't be sure what will happen,
but we can still<br class="">
make reasonable guesses in various ways:<br class="">
<br class="">
- show several estimates covering a range of
charger capabilities<br class="">
(this is what the Leaf does on the dash)<br
class="">
<br class="">
- assume the charge continues with the same
parameters as it left off<br class="">
(is this what OVMS did before the change
discussed?)<br class="">
<br class="">
- use past location data and history to predict
what will happen<br class="">
(wishful thinking!)<br class="">
<br class="">
It seems to me that there is a strong case for having
an "estimates"<br class="">
module to off-load this kind of thing from
vehicle-specific modules.<br class="">
It gets so much more complicated when you go beyond
what the vehicle<br class="">
module can report as objective fact (the battery
capacity is X, the<br class="">
charger current is Y) and in to more subjective
territory, where people<br class="">
have different ideas of what works best for them.
We've already hit<br class="">
that in the Leaf code with the SOC metric. I think
there needs to be a<br class="">
clear separation. To please everyone, the
"estimates" module is likely<br class="">
going to need a load of tunable parameters that
shouldn't be replicated<br class="">
in the vehicle modules. Maybe it could be completely
general, like the<br class="">
script-driven metric generator for OBDII?<br class="">
<br class="">
<blockquote type="cite" class="">I think it is
important to clear these prediction values when they<br
class="">
are no longer useful or correct, and relying on
individual vehicle<br class="">
modules to do it seems incorrect. We should be able
to do this in a<br class="">
standard way. But, I see your point about an
interrupted charge (I<br class="">
guess in that case we can presume a new charge would
resume and the<br class="">
predictions would be roughly correct, so long as
vehicle and charger<br class="">
state did not change).<br class="">
</blockquote>
<br class="">
Not sure I see your reasoning here. Even when the car
is not plugged in<br class="">
to a charger, wouldn't you still want to see some
estimated charge times?<br class="">
<br class="">
<blockquote type="cite" class="">How about we clear
these when the vehicle charge port is detected<br
class="">
closed? (in addition to the existing ‘charge done’
condition)<br class="">
</blockquote>
<br class="">
That wouldn't help the Leaf, which doesn't seem to
have a sensor for<br class="">
the charge port door, so we are currently faking that
from the charge<br class="">
detect logic.<br class="">
_______________________________________________<br
class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com"
class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>