[Ovmsdev] Charge time prediction

Thu May 17 14:14:00 HKT 2018

Am 16.05.2018 um 14:56 schrieb Mark Webb-Johnson:
> 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.

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.

Using them in that way provides a continuous configurable charge time estimation for the user.

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.

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.

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.

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.

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.

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.

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.

Regards,
Michael

> 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.
>
> I think there is certainly more that algorithm could be used for, but it is Tesla Roadster specific.
>
> Perhaps what we need is a generic interface in vehicle.{h, cpp} for a charge time predictor. Something like:
>
>     int OvmsVehicle::MinutesToCharge(
>       Chargemode,
>       Watts,
>       StartSOC or StartRange,
>       TargetSOC or TargetRange,
>       Temperature)
>
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> Regards, Mark.
>
>> On 16 May 2018, at 6:17 PM, Robin O'Leary <ovmsdev at caederus.org <mailto:ovmsdev at caederus.org>> wrote:
>>
>> On Wed, May 16, 2018 at 08:19:13AM +0800, Mark Webb-Johnson wrote:
>>> If we don’t know current + voltage available from the charger, then
>>> how can we predict charge time? Or is the current + voltage for the
>>> Twizy always the same (fixed?).
>>
>> It's still useful to show charge time estimate(s) even when charging
>> isn't in progress.  We can't be sure what will happen, but we can still
>> make reasonable guesses in various ways:
>>
>>    - show several estimates covering a range of charger capabilities
>>      (this is what the Leaf does on the dash)
>>
>>    - assume the charge continues with the same parameters as it left off
>>      (is this what OVMS did before the change discussed?)
>>
>>    - use past location data and history to predict what will happen
>>      (wishful thinking!)
>>
>> It seems to me that there is a strong case for having an "estimates"
>> module to off-load this kind of thing from vehicle-specific modules.
>> It gets so much more complicated when you go beyond what the vehicle
>> module can report as objective fact (the battery capacity is X, the
>> charger current is Y) and in to more subjective territory, where people
>> have different ideas of what works best for them.  We've already hit
>> that in the Leaf code with the SOC metric.  I think there needs to be a
>> clear separation.   To please everyone, the "estimates" module is likely
>> going to need a load of tunable parameters that shouldn't be replicated
>> in the vehicle modules.  Maybe it could be completely general, like the
>> script-driven metric generator for OBDII?
>>
>>> I think it is important to clear these prediction values when they
>>> are no longer useful or correct, and relying on individual vehicle
>>> modules to do it seems incorrect.  We should be able to do this in a
>>> standard way. But, I see your point about an interrupted charge (I
>>> guess in that case we can presume a new charge would resume and the
>>> predictions would be roughly correct, so long as vehicle and charger
>>> state did not change).
>>
>> Not sure I see your reasoning here.  Even when the car is not plugged in
>> to a charger, wouldn't you still want to see some estimated charge times?
>>
>>> How about we clear these when the vehicle charge port is detected
>>> closed? (in addition to the existing ‘charge done’ condition)
>>
>> That wouldn't help the Leaf, which doesn't seem to have a sensor for
>> the charge port door, so we are currently faking that from the charge
>> detect logic.
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180517/931ac1ab/attachment.htm>