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.
Conclusion: - nl_gids actually toggles between current_gids and max_gids - d[5] & 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[5] & 0x10 is always 0 anyway on older models ???? (d[5] & 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.