Fixing a bug that haunted ZE0 users for >10 months!
So today I got a huge weight of my shoulders. I fixed the last quickcharge bug that affected battery upgraded ZE0 Leafs. Why did it take me so long? Why was it so hard to fix? Lets dive in.
For those of you who don't know, there are significant differences between the AZE0 (2013-2017) and ZE0 (2010-2013) Leaf, when it comes to the software side. Nissan fixed a lot of bugs when they released the newer AZE0 Leaf, and the ZE0 was left behind. The ZE0 has bugs in the lookup tables for charging speed, and don't follow the cell characteristics at all. Some of you might have noticed this, when you fastcharge a standard 24kWh ZE0 Leaf, the charging speed gets FASTER once you heat up the battery on a massive trip. They clearly rushed the firmware on these early cars.
The problem then is that we need to replicate the odd behaviour of the control system when doing battery upgrades. This means slowing down certain periodic CAN messages (e.g. 100ms -> 500ms), cutting down the content, or converting it from one message to another. No big deal, just take lots of logs, analyze the content, and re-format it. It just takes time. Problem is, I haven't had access to a ZE0 Leaf until a month back when I bought one for my company, specifically to be able to make better software solutions.
So what was the bug?
The ZE0 Leaf was not fastcharging properly on older stations. This was a big problem for my customers. Not being able to charge at all stations after getting a 30/40/62kWh pack fitted seemed like a downgrade. Having to plan trips with Plugshare, and inspecting the charger type beforehand was a big hassle. I ofcourse informed all customers about this, and promised a fix however long it would take. It sure took a while...
So why is it so hard to fastcharge a ZE0 Leaf compared to the AZE0? One of the issues is that the early Leaf is NOT CHADEMO COMPATIBLE. You heard that right, the early Leaf is actually Chademo v0.9 only. Why?, It doesn't send SOC% on the QC-CANbus. The charger actually doesn't know what the state of charge is of the car, it has to calculate it from the "Wh current" and "Wh full" value. This is a big problem. Another hack that they did was to always send 60min charging time to the station, and not calculate it in the vehicle. Overall a very cobbled together solution.
The first issue we need to overcome, is that the VCM will then present the two Wh values to the charger. The VCM is locked to 24kWh max, so when you battery upgrade, you will need to spoof this Wh value, and scale it down from 40kWh down to 24kWh when fastcharging. Otherwise the station will see 100% once battery is roughly 55% charged.
The second issue then. The real bug. This is where it took many hours of debugging. During the start of the quickcharge, the older station types will do some handshaking with the car, and agree to what power will be supplied to the battery. The stations simply stated "Communication error"/"Current CMD timeout" on the battery upgraded Leaf. The current commanded got passed thru properly to the VCM, but for some reason the VCM did not apply this value that the battery requested. The solution came from looking at the logs. I'll be switching to some Leaf specific defines, that are available on the Leaf CANbus messages github-repo;
When succesful quickcharging is started
- LB_BPCMAX is initialized to 92.3kW (92.3kW signifies unavailable value, 3FFh)
- Unavailable value for LB_BPCMAX is held until chargers "Charge_StatusTransitionRequest" goes from 3->0->2 (stop,other,quickcharge)
- As soon as quickcharge state is entered, LB_BPCMAX goes to 0kW. This is held for 1s
- After one second has passed, LB_BPCMAX jumps to 20kW, and starts then to ramp according to algorithm
Failed QC: 0x000001dc 8 0x6e 3f 8f fd 01 38 c6 78
Successful QC: 0x000001dc 8 0x6e 3f ff fd e1 09 0d 2d
The problem was in frame.data[4]. 01 insteaf of e1. The 'e' signified 0b111, a maximum value of BPURATE. There is no documentation on this value available, it is simply 0-7 amount of "levels" according to a leaked document. But I know better now, and this value is actually a ramp-rate that the battery sends to the VCM. If the value is low, the VCM will override the current demand that the battery sends, and instead ramp slowly to this value. If you set it to max value, it will instantly follow the demand without ramping. I will be adding this information to my Github page. So after forcing a higher value to the bus, the quickcharging station started to fully function with the older battery upgraded Leafs. Oh, and as a bonus, the slowcharger started to ramp according to reference.
It finally works!
I have no clue if you found any interest in this, but this is the culmination of months and months of debugging, sending logs, testing things etc. I would like to thank one customer in particular for helping me with taking logs for this. Huge thanks to Per for having the patience to get thru this. All our vehicles will be better now!
Changelog for v2.32 of CAN-bridge BatteryUpgrade firmware
- All older QC-stations are now working with battery upgraded ZE0 Leafs (Major milestone)
- Slowcharging now ramps faster to target on ZE0
- Quickcharging now ramps faster to target on ZE0 (Example, previous sw took 7min to reach 45kW speed, now this is done in 5seconds)
Dala out