[Ovmsdev] Leaf 30kwh GIDs behaviour on 0x5bc

[Robin O'Leary]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20190310/8739886f/attachment-0002.sig>