<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>