[Ovmsdev] Leaf 30kwh GIDs behaviour on 0x5bc

[Anko Hanse]

Had a look at my traces for msg 0x59e (m_battery_energy_capacity detection), and they did not reveal anything interesting on a 30kwh Leaf:

While driving:
V (307878) v-nissanleaf: CAN1 0x5bc = 00 00 10 b7 00 00 00 00, cap_gids=267 cap_e=21360 soc= 84%
V (308378) v-nissanleaf: CAN1 0x5bc = 00 00 10 b7 00 00 00 00, cap_gids=267 cap_e=21360 soc= 84%
V (308878) v-nissanleaf: CAN1 0x5bc = 00 00 10 b7 00 00 00 00, cap_gids=267 cap_e=21360 soc= 84%

And a bit later:
V (12268088) v-nissanleaf: CAN1 0x5bc = 00 00 10 b6 00 00 00 00, cap_gids=267 cap_e=21360 soc= 72%
V (12268588) v-nissanleaf: CAN1 0x5bc = 00 00 10 b6 00 00 00 00, cap_gids=267 cap_e=21360 soc= 72%
V (12269088) v-nissanleaf: CAN1 0x5bc = 00 00 10 b6 00 00 00 00, cap_gids=267 cap_e=21360 soc= 72%

Where cap_gid = d[2] << 4 | d[3] >> 4
And cap_e = cap_gid * GEN_1_WH_PER_GID

So all seems fairly constant at a non-relevant value.
Did not see this message while car was parked and did not do a charge yet...

So now adapted the code to derive m_battery_energy_capacity from msg 0x5bc on 30kwh models.
And now am ignoring msg 0x59e on 30kwh models.


> 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.

Followed your suggestion and also made battery type detection purely based on msg 0x5bc and no longer relying on the poll results.



-----Original Message-----
From: Robin O'Leary <ovmsdev at caederus.org> 
Sent: Sunday, 10 March 2019 11:18 PM
To: Anko Hanse <anko_hanse at hotmail.com>
Cc: OVMS Developers <ovmsdev at lists.openvehicles.com>
Subject: Re: Leaf 30kwh GIDs behaviour on 0x5bc

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 ...