<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><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 face="Andale Mono" class="">int OvmsVehicle::MinutesToCharge(</font></div><div class=""><font face="Andale Mono" class="">  Chargemode,</font></div><div class=""><font face="Andale Mono" class="">  Watts,</font></div><div class=""><font face="Andale Mono" class="">  StartSOC or StartRange,</font></div><div class=""><font face="Andale Mono" class="">  TargetSOC or TargetRange,</font></div><div class=""><font face="Andale Mono" class="">  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="">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="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>