Nissan Leaf CAN bus Comms and IDs - hwthomas/ccs-chademo GitHub Wiki
Overview
This page gathers information about the Nissan Leaf (Later models - 2018 onwards) communications and the IDs relating to the main battery parameters needed by a CHAdeMO to CCS converter. The CCS end of the conversion is handled well by https://github.com/uhi22/PyPlc, but so far I have found less detail about the car CAN-bus interface.
As I have a Nissan Leaf Tekna+ (ZE1+ 2020) that is what is considered here.
As a start, see github repo by DalaTheGreat at https://github.com/dalathegreat/leaf_can_bus_messages
and the document referenced in it as Leaf2018-CAN.pdf which describes the request/reply mechanism used by Nissan (specifically CAN-bus Id's 0x79B/0x7BB for the Li-Ion Battery Controller) .
There is also a lot of historical information at the MyNissanLeaf forums LEAF CANbus decoding and Active EV-CAN sampling from which much of the following information is gleaned. Much of this information is from the early days of investigating the Nissan CAN-bus messages, and (although fascinating) is spread over a great many forum pages, which is very time-consuming to read.
Active Multi-message queries
The LEAF uses standard 11-bit CAN frames exclusively (no 29-bit extended frames). As well as repeated individual messages which are ongoing on the CAN-buses (and can be passively monitored), active queries can be sent which trigger a multi-message response from the controller being addressed.
LEAF active queries and replies use UDS over ISO-TP - the latter reference being particularly detailed and useful.
Each CAN message occupies 8 bytes, of which the first is the Protocol Control Information (PCI) byte, followed by up to 7 data bytes. The upper nibble of the PCI byte is used for the ISO-TP frame type, coded as follows:-
| Type | Code | Description |
|---|---|---|
| Single frame (SF) | 0 | The single frame contains the complete payload of up to 7 bytes |
| First frame (FF) | 1 | The First Frame of a longer multi-frame message packet. This contains |
| the length of the full packet, and the initial data packet | ||
| Consecutive frame (CF) | 2 | A frame containing subsequent data for a multi-frame packet |
| Flow control frame (FC) | 3 | The response from the receiver, acknowledging a First-frame segment |
The lower nibble is used for differing information, depending on the frame type
The example below is for the Leaf Tekna+ (2020) for the odometer reading in miles (or perhaps in the units to which the car is set. It does not appear to be always in kilometers, as stated in various places) See Leaf2018-CAN.pdf for the query definition.
Query: 743# 03 22 0E 01 FF FF FF FF
Reply: 763# 06 63 0E 01 00 64 6C FF
0x743 is the query address for the instrument cluster
The first data byte 03 is the ISO-TP header:
- 0 in the upper 4 bits means that this is a single ISO-TP packet
- 3 in the lower 4 bits means there are 3 UDS data bytes (22 0E 01):
- - 22 is the UDS service ID "Read data by local ID", which takes one 2-byte parameter
- - 0E 01 is the local ID, which the instrument cluster interprets as odometer in miles, as per car settings.
The remaining FF bytes are padding to 8 data bytes
0x763 is the reply address from the instrument cluster
The first byte 06 is the ISO-TP header:
- 0 in the upper 4 bits means that this is a single ISO-TP packet
- 6 in the lower 4 bits means there are 6 UDS data bytes (63 0E 01 00 64 6C)
- - 0E 01 is the same as in the query, with 0x41 added to the service ID to indicate it is a reply.
- - 00 64 6C is the odometer reading in hex, which converts to 25,708 (decimal) miles
The remaining FF byte is padding to 8 data bytes
Another multi-message query which can be readily checked is the car's VIN# from the VCM controller :-
0797 8 02 21 81 00 00 00 00 00 request (with flow control set accordingly)
with reply on 79A:-
10 15 61 81 53 4A 4E 46
21 41 41 5A 45 31 55 30
22 31 31 -- -- -- -- --
stripping off the sequence bytes (10, 21, 22, etc) the VIN# in hex is
53 4A 4E 46 41 41 5A 45 31 55 30 31 31 -- -- etc, which is 'SJNFAAZE1U011 ...' in UTF-8
Error replies
If the query is not recognised by the particular controller, an error rely will be sent back
For example, sending the following request to the instrument controller:-
Query: 743# 02 21 19 FF FF FF FF FF (incorrectly thought to be the odometer query) gave :-
Reply: 763# 03 7F 21 11 FF FF FF FF
The first byte 03 is the ISO-TP header:
- 0 in the upper 4 bits means that this is a single ISO-TP packet
- 3 in the lower 4 bits means there are 3 UDS data bytes (7F 21 11)
- 7F is the error indicator
- 21 is the request that caused the error
- 11 is the error type code (meaning is not known in more detail)
Leaf CAN-buses
This extract is from Mini-QC Rapid Charger forum page 20 -
My Names for the Jolomo pins (not official): (looking at the open end of the plug)
GP
x QR
x EC x
PP x x PM
x GD x
CL CH
BR
(my guesses/interpretations...
GP = Ground, Protective
QR = QC Ready, QC applies 12v
EC = Enable Charger (permission to charge), car pulls to ground.
PP = Power, DC Plus, isolated
PM = Power, DC Minus, isolated
GD = Ground, Disable car motion, Plug Proximity
CH = CAN-High
CL = CAN-Low
BR = Enable Battery Relay closure, to begin charging, Ground from QC
This is patterned after the info in these documents: The interface: http://chademo.com/05_interface.html The protocol: http://chademo.com/05_protocol.html
Apparently this is the sequence of operation (guesses) :
GP and GD are grounded when the plug is inserted.
CH and CL are biased but not yet being used.
PP and PM are unpowered, but will carry the charging voltage & current.
That leaves just 3 control lines (again my assumptions):
QR: the QC applies 12v if/when it is ready/available to do charging.
... (The car responds by starting CAN communication, sending car requirements.)
... (QC responds with charger capabilities.)
EC: the car pulls this line to ground to enable charging prestart testing.
... After successful pre-charging tests...
BR, the QC connects this line to ground to participate in closing the Battery Relay.
... The car closes the Battery Relay to "expose" the car's battery pack HV leads.
... (The car requests current, in amps.)
... (The QC "follows" the requests, and reports its status.)
Setup commands for ELM327
# End-of-line: 0x0D
# OK0x0D0D> will be returned after each command unless otherwise noted
# Turn on echo
ATE1
# Reset
ATZ
>0xFC
>0x0D0D
>ELM327 v1.5
>
# Turn off echo
ATE0
# Turn off linefeeds
ATL0
# Information
ATI
>ELM327 v1.5
# Sets the protocol to ISO 15765-4 CAN (11 bit ID, 500 kbaud)
ATSP6
# Turns on headers in the responses
ATH1
# Turns off spaces in the output
ATS0
# Turns off automatic formatting of CAN messages, allowing for raw CAN data to be seen
ATCAF0
# Read 12V battery voltage
# Sets the header for subsequent messages to 797 (Vehicle Control Module/VCM)
ATSH797
# Sets the Flow Control header to VCM, preparing the device for sending flow control frames to VCM.
ATFCSH797
# Sets the Flow Control data to "30 00 00". "30" is the Flow Control frame type indicating "Continue to Send", and "00 00" specifies no
separation time between frames.
ATFCSD300000
# Sets the Flow Control mode to 1, which means the ELM327 will send a flow control frame before starting the transmission of data
frames.
ATFCSM1
# ???Appears to be a request for data. The "02" is the length, but the rest is not covered in the data documentation
0210C0
# The below response is from the VCM (VCM response ID is 79A)
# No idea what it is though
>79A0250C00000000000
# Power switch status
03221304
# data[4]%128 == 0? The car was actually turned on here, soooo???
>79A0562130408FE0000
# Gear position
03221156
# data[4]==1 => park
>79A0462115601000000