When i observed the operation of ZEVA system in my Mazda and Megane, i found out if i used its native current sensor with it i would simply get all information that is required for fast charging in the 4Hz period over CAN. Granted ZEVA CAN speed is at 250kBps, but that could be changed. Or i could simply talk to CHADEMO at 500kbps and 250kbps to ZEVA to get voltage and current data.
So i designed ESP32 VCU with 2 CAN bus outputs, 5 digital outputs, 4 digital inputs and 2 analog inputs.
JamieJones adapted Chademo code for ESP32 chip here:
https://openinverter.org/forum/viewtopi ... 797#p54797
https://github.com/jamiejones85/ESP32-Chademo
I also went and asked Ian from ZEVA some constructive questions https://www.zeva.com.au/index.php
Me:
I would like to implement Chademo fast charging on both cars. I have my ESP32 dual CAN board and i made software to communicate with Chademo station.
I would like to use existing signals with no additional sensors and your ZEVA CAN seems perfect for that.
I need reports for implementation:
Voltage
Current
Cell temps
SOC
Ian:
Yes, all the ZEVA devices will run fine on 500kbps CAN. It requires a firmware change though, which is just a bit troublesome (re-compiling code and reprogramming all devices).
With temperatures, I'm not sure what the Chademo protocol requires but generally one only cares about minimum and maximum temperatures, i.e may restrict charging if any are sub-zero or over some maximum like 60˚C.
Me:
I noticed in EVMS3 code you only deal with temperature from EVMS3 circuit. Do you also compile an array or sum of module temperatures that i could simply use as comparator for cell temperature warning?
Maybe i could change the EVMS3 temp variable to observe average of modules temperature and look for higher difference from one module and than transmitt that on CAN inside ID 30 where EVMS3 temp was transmitted before. Could i do that? How would you go about that?
Ian:
The EVMS handles battery temperatures separately from its own temperature input - see line 532+ of EVMS3.c. i.e it goes through all the temperatures received from BMS modules and checks if any are outside acceptable range. (Apologies for the hard to follow code. It grew over time and never got the refactoring it needed.)
Me:
You could possibly have the EVMS send out a new CAN message with that BMS temperature info (better to do a new message than change the contents in ID 30 in my opinion, to avoid possible unintended consequences), or have your device also listen in on the BMS modules' messages and implement some similar code in the ESP32.
Maybe would be better to simply transmitt both flags over CAN, undertemperature and overtemperature or maybe create some intermediate flags.
Chademo should work in between those flags and if they are breached would lower the charge rate or stop it altogether.
So i could simply add to already transmitting isolation report and headlight byte in line 763
data[6] = isolation + (headlightsOn<<7);
And add it with reporting the flags status in bits....
I could use isolation report as a flag and simply report it in its own bit....
I think this should work with minimal changes to the existing code
Do you rely on this information in other modules on the CAN bus of ZEVA BMS? Would i mess something up if i changed this?
Ian:
You might see some odd numbers on the monitor if you modify the contents of ID30, e.g isolation % would be off because the monitor expect all 7 low bits to be used for isolation, but it won't compromise system safety, and the monitor doesn't raise any errors itself, only displays info from the EVMS.
Me:
is ID30 telegram transmitted only when charger/enable is triggered or does this work even in BMS idle?
Ian:
ID30 should be sent at 4Hz anytime the EVMS has its CAN bus powered up (so including Idle state).