[Ovmsdev] Leaf 2016 30Kwh flapping SOC

[ovms]

Tom, you are right. I used a standard cable, not a Leaf-specific cable. And the 0x50d is on the car-bus.
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.

My vote (if I have one) is to use the instrument SOC. It´s better from a end-user perspective.

-Stein Arne Sordal-


On 2018-05-02 15:06, Robin O'Leary <ovmsdev at caederus.org> wrote:
> 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 at lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev   


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180502/63726f5f/attachment.html>