[Ovmsdev] Leaf 30kwh GIDs behaviour on 0x5bc
ovmsdev at caederus.org
Sun Mar 10 18:18:11 HKT 2019
On Sun, Mar 10, 2019 at 04:32:16AM +0000, Anko Hanse wrote:
> Was not happy with the behaviour I was seeing on CAN msg 0x5bc and the GIDs, Battery Energy Available and SOC_newcar we are deriving from them.
> For some reason it was randomly either show the expected value, and at other times would go to gids=375.
> Note that gids=375 is a special number: energy = gids * GEN_1_WH_PER_GID = 375 * 80 = 30 kwh !!!
> So I decided to trace more info on this CAN msg in my 30kwh leaf.
> - nl_gids actually toggles between current_gids and max_gids
> - d & 0x10 is the flag that indicates which of these two is in the current message.
> So on a 30kwh leaf we can derive m_gids, m_battery_energy_available AND m_battery_energy_capacity all from the 0x5bc message!
Well spotted; that's good news!
> So improved handler code for the 0x5bc message should be something like:
> if (nl_gids != 1023)
> if ( (m_battery_type->AsInt(BATTERY_TYPE_2_24kWh) == BATTERY_TYPE_2_30kWh) && // <-- Not sure if we need this or if d & 0x10 is always 0 anyway on older models ????
> (d & 0x10 == 0x10) )
> m_battery_energy_capacity->SetValue(nl_gids * GEN_1_WH_PER_GID, WattHours);
> else ...
My logs only ever have that bit as zero, so I think there is no need
for the battery type check. In fact, I think we should flip it around,
i.e. deduce that the battery type is BATTERY_TYPE_2_30kWh from the
presence of this bit, instead of relying on the active poll as it is now.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the OvmsDev