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! Am still running a trace on 0x59e to see what the exact behaviour there is, but probably we can ignore that message for the 30kwh model. Below trace results show: - d[0]...d[7] raw values, - xm is a typo for the mx multiplexer variable as used for the estimated charge time (d[5] and d[6]) - cur_gids is the nl_gids value (d[0] and d[1]) - exp_gids is an indication of expected gids: 375 * SOC / 100 (without taking SOH into account) - SOC is soc_instrument. During charging: V (3689688) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 78 b7 10 1f ff, xm=0 cur_gids=375 exp_gids=131 soc= 35%[0m V (3689788) v-nissanleaf: CAN1 0x5bc = 1d 80 f0 78 b7 00 a0 f0, xm=5 cur_gids=118 exp_gids=131 soc= 35%[0m V (3689888) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 78 b7 11 03 2a, xm=8 cur_gids=375 exp_gids=131 soc= 35%[0m V (3689988) v-nissanleaf: CAN1 0x5bc = 1d 80 f0 78 b7 01 64 92, xm=11 cur_gids=118 exp_gids=131 soc= 35%[0m V (3690088) v-nissanleaf: CAN1 0x5bc = 5d c0 50 78 b6 12 5f ff, xm=18 cur_gids=375 exp_gids=131 soc= 35%[0m V (3690188) v-nissanleaf: CAN1 0x5bc = 1d 80 50 78 b6 02 bf ff, xm=21 cur_gids=118 exp_gids=131 soc= 35%[0m V (3690288) v-nissanleaf: CAN1 0x5bc = 5d c0 50 78 b6 13 1f ff, xm=24 cur_gids=375 exp_gids=131 soc= 35%[0m .. and so on with cur_gids=118 and SOC slowly climbing During driving: V (338837) v-nissanleaf: CAN1 0x5bc = 4d 00 f0 64 b7 00 1f ff, xm=0 cur_gids=308 exp_gids=348 soc= 93%[0m V (338937) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 64 b7 10 a0 3c, xm=5 cur_gids=375 exp_gids=348 soc= 93%[0m V (339037) v-nissanleaf: CAN1 0x5bc = 4d 00 f0 64 b7 01 00 96, xm=8 cur_gids=308 exp_gids=348 soc= 93%[0m V (339137) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 64 b7 11 60 d2, xm=11 cur_gids=375 exp_gids=348 soc= 93%[0m V (339237) v-nissanleaf: CAN1 0x5bc = 4d 00 f0 64 b7 02 5f ff, xm=18 cur_gids=308 exp_gids=348 soc= 93%[0m V (339337) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 64 b6 12 bf ff, xm=21 cur_gids=375 exp_gids=348 soc= 93%[0m V (339437) v-nissanleaf: CAN1 0x5bc = 4d 00 f0 64 b6 03 1f ff, xm=24 cur_gids=308 exp_gids=348 soc= 93%[0m .. and so on with cur_gids=308 and SOC slowly decreasing Parked overnight: V (14108065) v-nissanleaf: CAN1 0x5bc = 5d c0 8c 64 b6 10 1f ff, xm=0 cur_gids=375 exp_gids=206 soc= 55%[0m V (14108165) v-nissanleaf: CAN1 0x5bc = 2d 80 8c 64 b6 00 a0 b4, xm=5 cur_gids=182 exp_gids=206 soc= 55%[0m V (14108265) v-nissanleaf: CAN1 0x5bc = 5d c0 8c 64 b6 11 02 58, xm=8 cur_gids=375 exp_gids=206 soc= 55%[0m V (14108365) v-nissanleaf: CAN1 0x5bc = 2d 80 f0 64 b7 01 63 66, xm=11 cur_gids=182 exp_gids=206 soc= 55%[0m V (14108465) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 64 b7 12 5f ff, xm=18 cur_gids=375 exp_gids=206 soc= 55%[0m V (14108575) v-nissanleaf: CAN1 0x5bc = 2d 80 f0 64 b7 02 bf ff, xm=21 cur_gids=182 exp_gids=206 soc= 55%[0m V (14108675) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 64 b7 13 1f ff, xm=24 cur_gids=375 exp_gids=206 soc= 55%[0m ... and so on with no changes to cur_gids and SOC 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 { m_gids->SetValue(nl_gids); m_battery_energy_available->SetValue(nl_gids * GEN_1_WH_PER_GID, WattHours); // new car soc -- 100% when the battery is new, less when it's degraded uint16_t max_gids = MyConfig.GetParamValueInt("xnl", "maxGids", GEN_1_NEW_CAR_GIDS); float soc_new_car = (nl_gids * 100.0) / max_gids; m_soc_new_car->SetValue(soc_new_car); // we use the instrument cluster soc from 0x1db unless the user has opted otherwise if (MyConfig.GetParamValueBool("xnl", "soc.newcar", false)) { StandardMetrics.ms_v_bat_soc->SetValue(soc_new_car); } } }
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.
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%[0m V (308378) v-nissanleaf: CAN1 0x5bc = 00 00 10 b7 00 00 00 00, cap_gids=267 cap_e=21360 soc= 84%[0m V (308878) v-nissanleaf: CAN1 0x5bc = 00 00 10 b7 00 00 00 00, cap_gids=267 cap_e=21360 soc= 84%[0m 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%[0m V (12268588) v-nissanleaf: CAN1 0x5bc = 00 00 10 b6 00 00 00 00, cap_gids=267 cap_e=21360 soc= 72%[0m V (12269088) v-nissanleaf: CAN1 0x5bc = 00 00 10 b6 00 00 00 00, cap_gids=267 cap_e=21360 soc= 72%[0m 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@caederus.org> Sent: Sunday, 10 March 2019 11:18 PM To: Anko Hanse <anko_hanse@hotmail.com> Cc: OVMS Developers <ovmsdev@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 ...
participants (2)
-
Anko Hanse -
Robin O'Leary