CHAdeMO was once a much favoured solution for DC fast charging, especially with Japanese vehicles such as the Nissan Leaf. The ability to deliever DC power into a battery meant reduced charging times which for those owning an EV is essentially when planning a long journey. CHAdeMO gave the opertunity to deliver up to 62.5kW by 500V at 125A direct current. A revised CHAdeMO 2.0 specification allows for up to 400kW by 1000 V at 400 A direct current and this has updated again to CHAdeMO 3.0. This sees a slight change to the connector but offers between 500kW and 900kW of power at 1kV - 1.5kV and 600A.
CHAdeMO has been slightly pushed aside as many VM's favor the Type 2 CCS which is slowly becoming the 'standard' especially in Europe. You can find out more on Type 2 communication in the EV guided test section in PicoScope 7 Automotive and also in Steve's awesome post on PLC here - topic22904.html.
CHAdeMO is considerable differnet to CCS. Apart from the 2 high voltage DC connections that's about where the similarities end. From the number of pins and the gerneral size of the connector, one of the main differences is that CAN forms part of the communication between the vehicle and the EVSE, which not only allows more data to be transferred it also allows the ability of V2G, vehicle to grid. We have seen that CAN can be transimitted in single wire mode as like Tesla which you can see here - topic22544.html but it is not appearing on many vehicles at the moment.
By using both digital and analogue signals both the charger and the vehicle have the ability to stop charging meaning there is always a backup fail safe should one fail. This then brings up the question, if there is a problem with charging is it the EVSE or the vehicle? With 2 fail safes and now a network this makes answering the question more difficult.
A joint adventure for Pico and HEVRA we have spent some time analysing the signals in order to better understand what happens when connecting a CHAdeMO EVSE to a vehicle. This article is for educational purposes only and shouldn't be used as a guided test. As with everything EV related please ensure you have the appropriate training, equipment and PPE. Whenever measuring whilst connected to the mains we should always be using the correct CAT rated equipment. The following measurements were all done in a controlled environment.
An overview of the circuit is required and below we have redrawn the charger and the vehicle. This drawing is for illustrative purposes only and there may be some differences in the future.
2. Charge signal 1
4. Charge permission
5. HV DC Negative
6. HV DC Positive
8. CAN H
9. CAN L
10. Charge signal 2
The numbers here represent the pin numbers for the connector. We then connected the scope to see what happens to each of these circuits when connecting to an EVSE. For ease current was used for high voltage cables.
Channel A - Proximity
Channel B - Charge Signal D1
Channel C - Charge Signal D2
Channel D - CAN H
Channel E - CAN L
Channel F - Charge permission
Channel H - DC Current
There is a lot going on here so we will break it down into stages.
Step 1 - Charger not connected
With the charger not connected we can see that the only voltage present is the 12V signal from the proximity circuit. As we are connected to the vehicle side and this is the only 12V supply present as all other supplies come from the charger.
Step 2 - Charger connected, not charging
With the charger now connected we now see the following -
Ch A Proximity - is pulled down to around 1.7V.
Ch B Charge signal 1 - comes up slightly to to around 0.6V. This may be due to the charger and the vehicle now connected and a slight change in the ground level.
Ch C Charge signal 2 - voltage comes up to around 11V. This is strange as the circuit diagram found does not show where this could come from. We believe it to be a form of self check to ensure there isn't a short on charge signal 1 contactor
Ch D/E CAN H & CAN L - Some intial data to establish communication
Ch F Charge permisson - around 11V which is from the charger indicating that charging is not possible. Vehicle will pull this voltage to ground when it's ready to charge.
Step 3 - Charger connected - not charging
Ch A Proximity - remains at 1.7 before raising slightly before switching off prior to charging. This slight rise in voltage is believed to show the DC/DC charging coming online to begin charging the 12V battery. It was strange to see the vehicle switch off proximity circuit during charging but due to the charge signal relays all sharing the same ground we could potential end up with a voltage difference which would cause a current flow and potential to damage an ECU. By switching this circtuit off prevents any issues.
Ch B Charge signal 1 - is now switched allowing 12V to be present at one side of the HV contactors. The vehicle still has control over the contactors via the switch between charge signal 2 and the relays.It is not quite clear when the vehicle activates this switch.
Ch C Charge signal 2 - as charge signal 1 is activated we can see the voltage jump up slightly to 12V. This would indicate that the vehicle has switched the path for the contactors. Further along the line we can see that the EVSE will activate the switch to provide this circuit a path to ground allowing current to flow. This will then activate the contactors in the vehicle for the HV circuit.
Ch D/E CAN H & CAN L - data starts up again when charge signal 1 is activated and communication remains till the charger is either completed or interupted.
Ch F Charge persmission - after a period of communication the vehicle switches the path to ground and so allowing charging to commence.
Step 4 - Charger connected - charging
Ch G DC current - once the charger and the vehicle are satisfied that all conditions for charging have been met, the EVSE ramps up the current flow into the vehicle.
Step 5 - Charger connected - charging stopped via EVSE
As mentioned ealier both the vehicle and the EVSE has the ability to stop the charge at any point. One thing to note with CHAdeMO is that once charger is completed, the connector can be removed. This means if you're waiting at a charger and the vehicle completes it's charge, you can remove the connector without the owner being present. This is unlike CCS where the charger remains locked to the car even if charging is complete.
Ch A Proximity - once the current has stopped we see the proximity circuit come back to 1.7V. This happens at the same time as the charge persmission circuit is switched off at the vehicle.
Ch B Charge signal 1 - after both the proximity, charge permission AND charge signal 2 have altered state, the EVSE turns off the switch for the 12V signal.
Ch C Charge signal 2 - after proximity and charge persmisson have switched, the EVSE switchs off the control and so removes the path to ground from the vehicle HV contactors. This causes the voltage to rise back up to the match charge signal 1. What we notice here is that the when charge signal 1 is switched off as well, the voltage level of charge signal 2 drops slightly. We do beleive this to be some form of monitoring for stuck relays/switches.
Ch F Charge persmission - as with poximity the vehicle signals that charging has ended by removing the ground to the charge permisson signal so the EVSE is informed that the car acknowledges the stop request.
Step 6 - Charger removed
By removing the charger connector we see the proximity, Ch A, jump back up to 12V and all other circuits return to 0V. We notice that communication is now silent till the vehicle shuts down.
A lot to take in here I know but I hope it helps in understanding the way the EVSE and the vehicle communicate. I will post again here soon once I've confirmed a technique for checking the CHAdeMO communications with the EV kit which looks at just using a diff probe and current clamps to ensure the correct CAT rating is met during the measurement.
Following on from the information above another day of testing commenced at Gridserve in Braintree with Pico and HEVRA. We had a number of questions left unanswered from that adventure with the first being the 12V on charge signal 2 after connecting a charger to the vehicle. According to all the drawings that a quick search for CHAdeMO brings up there shouldn’t be a 12V signal at charge signal 2 so where is it coming from?
As with all our forum posts on EV they are purely for educational purposes and should not be used as a guide to repair or troubleshoot electric vehicle faults.
If we look at the above image and focus on Ch C, green, which is charge signal 2 as the CHAdeMO connector is physically connected to the vehicle. It instantly jumps up to around 11V. Considering our placement within the circuit, the only source of voltage is from the ECU on the vehicle. However, we have seen research that mentions the signalling inside the ECU is done using photo couplers. This would mean there is no voltage source from the vehicle, so how come we have 11V present? If photo couplers are used then the only place it can come from is the EVSE. We measured the charge signal 2 to ground at the CHAdeMO connector to find we did indeed have 11-12V. This would then mean the drawings are wrong! An update below here is what we are thinking is actually going on.
Highlighting charge signal 2 we can see now how this would create the signal we are seeing in the waveform above. If we move to the next step in the waveform where charge signal 1 is activated there is a small increase at this point which may well also show that the two are connected.
Finally in order to activate the relays, the quick charge relay is activated and then charge signal 2 is switched to connect to the ground in the EVSE which allows the current to flow in order to control the high voltage contactors.
Clearly there is more going on as we still have the charge start/stop request as well as the CAN communication which is another area we were keen to investigate further. The following information is based on Gen 2 Nissan Leaf.
Fortunately there are a number of documents out there already on the CAN messaging with CHAdeMO one of which is a helpful video from Vector - https://youtu.be/3IRavoysOi0. Here an important slide helps us to better understand the communication between the vehicle and charger as it identifies the ID’s which are associated with the charger and the vehicle.
This can be confirmed by using a current clamp on the CAN network as described in the following forum post - topic22527.html.
One thing we have noticed is that data is sent out in a certain sequence at what would appear to be a timed interval. As with all scope analysis, spotting the patterns is what helps us get the direction we need and we can see the repeating messages in the above capture. From the Vector presentation we can see that ID’s 100, 101 and 102 are from the vehicle and 108 & 109 is from the charger but we have some extra ID’s in our decode table. As we have the current clamp connected we can attribute the direction to the source of the message. For those in the positive direction, messages are from the vehicle and those in a negative direction are from the EVSE. Our table is now expanded slightly to the following.
Clearly the vehicle is sending out a lot more information than in the documentation we’ve found but what is it for?
One suggestion is that as this is a Gen 2 Nissan Leaf these ID’s could be related to V2G, Vehicle 2 Grid. We believe this to be the case as prior to any analogue communication starts we can see CAN activity which can be seen in the below capture taken from the same vehicle during the first adventure into CHAdeMO.
Going a step forward then and decoding this data we see that 700 is consistently polled after initial connection. The theory is that this message is a shout from the vehicle to see if the charger connected is compatible with V2G. As the current is in the positive direction we can be sure this is from the vehicle.
700 does continue to appear when the charger is taking place along with ID’s 200, 110, 201 and 202 as well as 118 which is from the EVSE. Data does not change within this ID’s whilst the vehicle is charging which makes us think it’s something extra to what the vehicle and EVSE require in order to charge the battery.
As with all this decoded data, it’s great but what can you do with it if you don’t know how to convert it. Fortunately Steve Smith has been getting to grips with CAN loggers and Vehicle Spy in particular which you can see in action here -topic22955.html.
Whilst tools like this may seem slightly above what we need as technicians they are really useful when reverse engineering networks. Being able to see data as it appears on the bus at a bit level has some real advantages and combine that with a real measured data from Pico, as we have the ability to view the data in a way that makes it easy to see if something is changing.
Even without something like Vehicle Spy and the appropriate hardware, there are still things that you can do with Pico to start reverse engineering networks and data. A small network like CHAdeMO where we only have two ECU’s is great to start with. By using Pico’s export function we can manipulate the data with the likes of Excel and Google Sheets. I talk a bit about using Excel here - viewtopic.php?p=100659#p100659 but I want to talk through some of the advantages Google Sheets brings.
Google, like it or not, has some very useful apps. Things like Slides, Docs and Sheets bring the likes of PowerPoint, Word and Excel online with the ability to edit, share and collaborate with others anywhere in the world. It does also allow you to work offline so if the internet drops out it will save locally to then update when the connection is restored. Whilst it doesn’t have some of the powerful features we're familiar with, I’ve found Google Sheets works very well for this type of decoding work.
If you’ve worked with Excel, Sheets is very similar and you’ll be able to get up and running with it pretty quickly. Once you have some decoded data exported from Pico you can either open in Excel and copy and paste or import a file. I prefer to open and copy as the formulas within the workbook I’ve created require the same source. This is slightly different from Excel where you could import CSV data and then select what you need to import and then place in an existing worksheet. There may be a way to do this in Sheets but I’ve yet to find it. With your data imported it’s time to start filtering!
Now normally you could use the filter option and then use the drop down arrow to sort your data depending on what you select. This could be an ID for example so you'll have just the rows that feature the ID you have selected.
This can be useful for seeing if data changes but not really helpful if we want to do anything else with it. Enter the wonderful FILTER function! https://support.google.com/docs/answer/3093197?hl=en-GB
This remarkable function helps to filter out the data for you row by row depending on the conditions you create and return just the data you require.
In the above example the formula reads as follows -
=FILTER(‘Import from Pico’!I:I, ‘Import from Pico’E:E=A1)
What we are asking the software to do is return a value from the range of data in column I of the worksheet ‘Import from Pico’ which is our data field from our decode table. It should only return the data if the range in column E, which is the ID field from the decode table, matches the value in A1, which in this case is 100. The result is we now have the data field from the imported decode table from the ID 100 as a full list without having to copy and paste! What I really like about sorting the data in this way is that all you need to do now is duplicate the worksheet and the only thing you need to change is the value in cell A1.
For the next step I have used the exported data from the following PSDATA capture where CAN and HV current have been captured.
With the ID’s and subsequent data separated out into their own worksheets, we now need to separate out the data bytes. If you didn’t know anything about how the data is changed to be represented as real values, we can just look at the hex bytes individually to see if anything relates to what we have measured, in our capture HV current. I’ve chosen ID 109 as it has a lot of data which is changing which helps to relate to any raw measurement we have taken.
If the data isn’t split correctly use the separator option and change to space.
Most data is formatted into a decimal value before any scale or offset is applied. I’ve found it’s always best to export in HEX and then convert to a decimal as it’s easier to join HEX bytes when data requires 2 or more bytes to create the decimal value. An example of this would be engine speed which requires 2 bytes to be converted to a decimal before the scale and offset is applied.
To convert the bytes we use the HEX2DEC function. This works in the same way as Excel and can be easily filled using the auto fill.
Now with our decimal converted data bytes we can apply a graph to these columns.
Apart from some relatively straight lines we can see that the yellow trace, column L, appears to be very similar to our current profile!
To add the graph to an image of PS7 please see Steve’s post on how to do this topic22857.html.
Fortunately the Nissan Leaf though seems to be one of the most reversed engineered vehicles out there and amongst the vast number of spreadsheets on the internet someone has picked apart the data on the CAN for CHAdeMO. This would have to be standardised between all manufacturers in order to connect to any CHAdeMO connector.
Rather than go through all the data I will just focus on showing how to combine two bytes with the exported data. Both Steve and I touch on this in the following posts viewtopic.php?p=100659#p100659 and viewtopic.php?p=102835#p102835. This has been done in Excel where we make use of the function CONCATENATE to join two cells together. It’s basically the same function but in Google Sheets I’ve used the JOIN function which I guess makes more sense!
This is where exporting in HEX makes this part easier as we join two bytes together and then perform a HEX2DEC function on this result. Sticking with ID 109 and with the data we found online we now know that the bytes 55 & 1, as seen highlighted below, is for the output voltage of the EVSE.
Due to the formatting of data in CAN there are typically just 2 ways it can be interpreted. Where parameters consist of 2 or more data bytes, the least significant byte is transmitted first which means we start with the most significant byte that needs to be swapped around. If there is ever any uncertainty try it both ways.
If we use the above data in its current format 55 1, join and remove the space 551 and then convert to a decimal we get the following - 1361. As this value is for voltage I think we could assume it isn’t supposed to be 1361V, well not right yet anyway maybe in the future. If we now reverse the byte order to 155 and then convert to a decimal we have 341. Without any offset or scaling we could assume this would be our voltage from the EVSE.
To put this into a formula we get the following: HEX2DEC(JOIN("", C2, B2))
Breaking the formula down we are asking the software to perform a HEX2DEC function on the JOINed value with the space removed, "" for cells C2, B2. The ordering of the cells is important as we need to flip the bytes around.
Filling the remainder of the cells and then plotting the column as a graph we can now see how the voltage is changing over time.
If you’ve made it this far, thanks for staying with me! To make this a much simpler process and generally easier on the eye we can get the software to work through all this without having to split up the data field. This involves us using the MID function which allows us to return specific individual values depending on their position in the cell. Counting is important with this one as it’s very easy to get the wrong byte position!
If we take the first data field 02 55 01 00 00 24 FF FF. We are interested in bytes 55 & 01. By using the MID function we have to count from the left, the position of the first value we would like to return followed by how many values to return moving to the right once there. As we know we need to swap the byte order around we need to start with 01. The beginning 0 position if we count from the left, including the space, is a count of 7 and as we want to include the next value, then length is 2. This results in 01.
Doing the same for the 55 we have the formula MID(A2, 4,2).
To complete the formula that will do all this for us we just have to build it up to combine the different elements. Using the MID function to identify the bytes we want to use. JOIN puts them together and removes the space and finally HEX2DEC converts the hexadecimal value to a decimal.
By applying the same MID function for the current byte we found earlier we have the formula
Then we can plot both of this results as a graph.
This method can then be applied to the rest of the ID’s where the byte order and any scale or offset is known.
I hope this helps in some way and shows that despite Pico not being a dedicated CAN logger we can still do a lot with some fairly simple(ish) formulas and can be helpful with our diagnosis to compare serial and analogue signals.