<div>Tom, you are right. I used a standard cable, not a Leaf-specific cable. And the 0x50d is on the car-bus.</div>
<div>I have now swapped to a Leaf-specific cable, and tried to change the code to look for 0x50d on the car bus, but I apparently did something wrong. No data from the car-bus is received now.</div>
<div> </div>
<div>My vote (if I have one) is to use the instrument SOC. It´s better from a end-user perspective.</div>
<div> </div>
<div>-Stein Arne Sordal-</div>
<div class="syno-mc-signature"> </div>
<div> </div>
<div class="">
<div>On 2018-05-02 15:06, Robin O'Leary <ovmsdev@caederus.org> wrote:</div>
<blockquote class="syno-mc-blockquote" style="padding-left: 5px; margin-left: 5px; border-left: #c8d2dc 2px solid;">
<pre>On Wed, May 02, 2018 at 11:55:19PM +1200, Tom Parker wrote:
> On 02/05/18 01:08, ovms wrote:
> >*case 0x50d**:*   //Changed this from 5bc. 50d is the instrument SOC
...
> >SOC now shows exactly the same in the app as the instrument-panel does,
> >and is not flapping. (I know the instrument-panel is different from the
> >true SOC)
...   
> I wasn't able to reproduce this. On my car and in the CAN bus captures I've
> got, there is no 0x50d frame on the EV bus. Now that I'm back in the house,
> I see that 0x50d is present on the Car CAN bus, but I don't have any data on
> what's there.

The top 8 bits of the first byte are the instrument SOC% (on MY2015),
but it only updates when the car is on, not when charging.

Incidentally, the only other thing I have noted for 0x50d is that there
are two bits in d[6] which seem to be related to the charge port latch.

> Should I be looking at 0x50d on the car bus to faithfully display what the
> instrument cluster displays? I'll check tomorrow.

I think it's just a direct repeat of the value in 0x1db, which is more
useful because it also updates when charging:

    case 0x1db:
    {
      // sent by the LBC, measured inside the battery box
...
      StandardMetrics.ms_v_bat_current->SetValue(nl_battery_current / 2.0f);

      // state of charge percentage, as shown on dash info panel
      uint8_t soc = d[4] & 0x7f;
      if(soc != 0x7f)
        {
        StandardMetrics.ms_v_bat_soc->SetValue(soc);
        }

> My notes indicate that 0x55b on the EV bus contains the state of charge, and
> I've implemented this at https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/master...carrott:nissan-leaf-soc-instrument?expand=1
> along with a configuration option to choose how to show the SOC.

> However 0x55b doesn't work how I expected on my 2016 24kWh car, I see
>   
> xnl.v.bat.gids                           140
> xnl.v.bat.soc.instrument                 56.3%
> xnl.v.bat.soc.newcar                     49.8221%
>   
> but the instrument cluster displays 52%. Could it be displaying 56.3 - 5 =
> 51.3 rounded up to 52?

Yes, the value in the top 10 bits of 0x55b is interesting since it has
a few more bits of resolution and updates when charging or driving, but
is actually measuring something slightly different from the instrument
SOC%---usually not by much, but sometimes a couple of points.

> Assuming we get this working, should we default to using the instrument
> cluster state of charge, or the "new car" state of charge? I'm guessing we
> should go with the instrument cluster value, which is a change from previous
> behavior on the leaf but is in keeping with Mark's "re-implement the broken
> calculations by the car".

That would have my vote too.
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
</pre></blockquote>
</div>