LEAF CANbus decoding. (Open discussion)

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.


Well-known member
Sep 13, 2010
Broken Arrow, OK
The CANbus network in the LEAF is the central nervous system, connecting all the major modules and relaying information between them. This thread is a place for like-minded hackers to share information on the LEAF's CANbus topology, message contents, experiments, and gleaned information from the car data systems.

The LEAF Service Manual (LAN section in particular) has thorough information regarding the connectivity, pinouts, and functional blocks on the CANbus. However, it does not describe the actual message packets. Specific diagnostics and operations are documented only for the CONSULT III+. By studying the CANbus directly, it is possible we can extract more information than the car displays to the user, and possibly perform some operations done by the CONSULT tool.


Data Link Connector
There are three CAN (Controller Area Network) network pairs brought out to the 16-pin DLC (Data Link Connector), labeled (M4) in the service manuals. This connector is located above the driver's left knee, and is sometimes referred to as an OBD or SAE J1962 connector. Be very careful about buying OBD "code scanner" products, as they generally use an unrelated OBD data bus (ISO 9141-2 "K-Line" or "L-Line") for low-speed communication, and are useless for monitoring the CAN bus.

This image shows the pinout of the female (car) connector:

Primary CAN Bus, "CAN communication circuit"
The primary CAN bus is on the standardized (J2284) connector pins, CAN-L (14) and CAN-H (6). Most off-the-shelf CAN car adapters will use this wire pair exclusively.

This bus carries traffic between the VCM, DLC, BCM, ABS, Steering, and Dash/Nav. It has most of the interior operations, displays, and controls.

EV CAN, "EV system CAN circuit"
The second bus is the "EV CAN". This is on Discretionary pins in the DLC: EV CAN-L (12), EV CAN-H (13).
This bus has communication including the VCM, HVBAT, OBC, and TCU.

Note that VCM is on both the CAN & EV-CAN busses and can gateway traffic between them. The chart on page LAN-33 has a detailed list of each signal, and which bus/module transmits/receives it.

Because the OBC, Motor, and HVBAT are on the EV CAN bus only, this has been the primary area of my interest. To connect to this bus, you will likely have to make your own J1962 cable, as it is not the 'default' CAN bus for diagnostic tools.

There is a third less-documented CAN bus between the Audio-Video Navigation unit and the "multifunction switch". (The multifunction switch is the physical button panel around the A/V screen.. Map, Eco, Menu, etc.)
AV-CAN-H (11)
AV-CAN-L (3)

CHAdeMO Quick Charge
The CHAdeMO DC quick charge port (on cars so equipped) has an additional CAN connection to the On Board Charger. Anyone know more about the pinout here?

Pin 16 has constant +12v DC power from the battery. It is protected by a 10A fuse #13.
Pin 8 has switched power when the Leaf is ON, protected by 10A fuse #3. This is a nonstandard pin assignment, and most commercial devices use the constant power found on Pin 16.

120 Watts is enough power to melt small-gauge wire, so an additional fuse is recommended for any DIY project.

Pin 4 is Chassis Ground, and Pin 5 is Signal Ground. Note that CAN is a differential bus, and has no need for a Ground reference. Indeed, if you can power externally, isolation is preferred. It appears that 4 & 5 are both wired to battery ground in the Leaf.

The TCU and Navigation unit are connected via USB 1.0. This is the link used to update Carwings information feeds, Charger location updates, etc. This data may not be on CANbus at all. (The TCU also has logic-level RS-232 available on its connector harness, apparently unused by the Leaf.)
If you have an interest in hacking in this area, the Service Manual is a mandatory $20 ante, of course.

There are quite a few Internet primers on CAN-bus itself. ISO and SAE mandate certain behavior for OBD use, but the LEAF isn't necessarily subject to any of that. ISO11898-1 descirbes the physical link.

It's not a complicated LAN. Unfortunately, it has few consumer applications, so test equipment and adapters tend to be proprietary, esoteric, and expensive. Each bus is a differential pair of signals, and no ground is required for some (isolated) adapters. Unshielded twisted-pair wire is generally sufficient for connections. I use standard CAT5 ethernet, and have not used termination when plugging into the DLC.

Both of the CANbus networks operate at 500kbps. This isn't particularly demanding.
(From what I can tell, the Primary CAN is more 'saturated' with messages than the EV CAN.)
The EV CAN contents can (barely) fit into a 230kbps RS-232 stream, so some of the CAN-to-RS232 adapters may work.

The USB-connected adapters are preferred, since they tend to have 1Mbps+ bandwidth available.

Adapter examples are:
  • ValueCAN or NeoIV from Intrepid Systems
  • Acacetus CAN-uVCCM (limited to 56kbps! useless here)
  • Lawicel, both RS-232 and USB available
The messages on the LEAF EV CAN bus seem to be all repeating/periodic... with 2, 10, or 100 repetitions per second.

The LEAF appears to use "standard" 11-bit CAN frames exclusively. (no 29-bit extended frames)
So the Identifiers could range from 0 to 0x7FF.
Along with the Identifier, the LEAF attaches one to eight bytes of payload data. (ie, "the meat")
I haven't seen any RTR transmissions (a special case), with ID and length but no data, but my equipment could be missing those altogether.

Putting the messages into groups, there are the highest-frequency ones, which appear every 10ms:
ID 11A: 8 11800055400002CB 
ID 1D4: 8 F707000200066061 
ID 1DA: 8 0F000000000083AE 
ID 1DB: 8 0020C1EA00000080 
ID 1F2: 8 68646000003F0002
This one message appears every 20ms:
ID 284: 8 0000000000009319
These are every 100ms:
ID 380: 8 0204202100000028 
ID 50A: 6 0601001F0000 
ID 50B: 6 000000000000 
ID 50C: 6 000000005DC8 
ID 54A: 8 3C00700F0000006E
ID 54B: 8 0008800004000001
ID 54C: 8 FFFF000000F8FF00
ID 54F: 8 420000000B800829
ID 55A: 8 005445005F4382F0
ID 55B: 8 C8C0AA00BAC0218B
ID 56E: 1 86
ID 5BF: 8 000000003800001B
And these are slower.. 500ms:
ID 5B9: 5 585A60F028
ID 5BC: 8 3A812B3EC80620F0
ID 5C0: 8 C0787CF2C8D80000

And, that's really it.. these are all the messages on the EV BUS while driving.
Only 22 messages of 8 bytes or less. Further, we know most or all of the functions on the bus from the LAN chapter. As far as reverse-engineering goes, this isn't a long shot... or Legendary Difficulty.
OK. This is all cool and everything but what do we want to do with it?

More precision on SOC is a given. I'd like to get some battery balance info and be able to better monitor the comings and goings of coulombs over the next 3 years. Perhaps better charging control, but really I'm not often needing anything more than 80%. I'd like all this info logged on some device that I can query via WiFi when the LEAF is parked in my driveway.
So maybe two CAN interface chips tied to a Gumstix
I added a little CAN-bus card to this Arduino controller board I've had for awhile.
Logging EV and Car CANs to a laptop has been pretty straight forward. Packets are flying at up to 1 msec separation but I haven't had time to try and suss out the individual packet IDs. I probably only care about a handful of IDs anyway. The MBytes add up fast when driving a short time. I only need to listen for now but eventually we'll want to query the LEAF for specific stuff or to display SOC on a built in display.

Perhaps I can start to decode the relevant data but it would be nice if it's not all duplicated effort. Got EV-bus ID mapping?
So, for state of charge, I'm sniffing around for values that go UP while charging, and DOWN while driving, more or less.

During charge, most of the EV CAN messages contain the exact same values throughout, or they contain values that vary rapidly.

The ones that are neither seem the most interesting.

ID 55A has multiple (4) increasing bytes, which revert to lower values now and then, as if there is some noise. They are not synchronized, have coarse resolution, three are similar in value (0x43 to 47), and change slowly, which makes me think this might be multiple temperatures?

ID 5B9 seems promising.. it contains an increasing value, which changes slowly while charging:
ID 5B9: 5 485A67FF28 @    217.412s
ID 5B9: 5 505A67FF28 @    566.920s
ID 5B9: 5 503C67FF28 @   1349.736s
ID 5B9: 5 583C67FF28 @   1476.971s
ID 5B9: 5 583267FF28 @   1915.903s
ID 5B9: 5 582867FF28 @   2482.067s

Curiously, it also seems to go up while driving:
ID 5B9: 5 5FFF67FF28 @    286.510s
ID 5B9: 5 5828609628 @    288.042s
ID 5B9: 5 5832609628 @    351.393s
ID 5B9: 5 583260B428 @    352.415s
ID 5B9: 5 583C60B428 @    538.378s
ID 5B9: 5 583C60D228 @    539.400s
ID 5B9: 5 585A60D228 @    600.706s
ID 5B9: 5 585A60F028 @    666.611s

Any guesses?
I'm increasingly convinced that ID 55A is temperature status of the battery or charger.

After two hours of charging, the values have largely stabilized. They were changing more rapidly in the first hour of charging.

An example payload looks like this:

Of these bytes, only three [] values are changing, increasing slowly with some noise around transitions.
They went up from 0x42 at start of charge.

The car was at room-temp before charging. It would be surprising if Fahrenheit was used as a scale, but that does map to 66F to 77F, which isn't unreasonable.
ID 5B9 (twice per second) does seem to be promising as something else increasing during charge.. very slowly.
07FF07FF28 @ 0          
014A07FF28 @ 1.575s          
014A67FF28 @ 2.086s          
114A67FF28 @ 3.108s          
194A67FF28 @ 99.686s                            
192C67FF28 @ 128.812s                            
190E67FF28 @ 881.997s                            
210E67FF28 @ 1145.152s                            
20F067FF28 @ 1762.414s                            
28F067FF28 @ 2384.789s                            
28D267FF28 @ 3396.019s                            
30D267FF28 @ 3917.220s                            
30B467FF28 @ 5029.110s                                  
38B467FF28 @ 5528.848s
The last time I charged, the first 16-bit value climbed to 67FF at full charge.
It could be a ratio.. with 67FF representing full charge.

If this was true SOC, I'd expect to see it increasing more often than eight minutes, though.
GroundLoop said:
ID 5B9 (twice per second) does seem to be promising as something else increasing during charge.. very slowly.
07FF07FF28 @ 0          
014A07FF28 @ 1.575s          
014A67FF28 @ 2.086s          
114A67FF28 @ 3.108s          
194A67FF28 @ 99.686s                            
192C67FF28 @ 128.812s                            
190E67FF28 @ 881.997s                            
210E67FF28 @ 1145.152s                            
20F067FF28 @ 1762.414s                            
28F067FF28 @ 2384.789s                            
28D267FF28 @ 3396.019s                            
30D267FF28 @ 3917.220s                            
30B467FF28 @ 5029.110s                                  
38B467FF28 @ 5528.848s
The last time I charged, the first 16-bit value climbed to 67FF at full charge.
It could be a ratio.. with 67FF representing full charge.

If this was true SOC, I'd expect to see it increasing more often than eight minutes, though.

Watt hours input to onboard charger?

67FF = 26623. Somewhat near what I have heard mentioned with respect to power needed to charge to 100%.

Over an 8 hour charge that would be about 55.5 watts a minute. ...if that is what it represents. But perhaps that is too simplistic. Just a thought.
1. "5B9": Somthing changing at about 5 or 6 minutes (or 8, after agressive driving) could be "estimated miles/km remaining".

2. The "554" ... [5B08] msg changing values (on a 6-hour charge to 100%) climb to 55 54 59, which could be ºF, of 85, 84, and 89? I do not know the ambient temp for this data (6 million EV-CAN msgs).
For "5B9" on the 6-hour charge: the first byte goes from 0x11 to 0x67, in steps of about 0x08 (old firmware), thus about 12 steps. Mask with 0x38, it could be the number N of SOC bars to display (N times 8), going from 2 to 12?

The Low 3 bits of the first byte and the 2nd byte go up to 7FF, so they could be the fraction of the bar that is filled?
We have 3 CAN busses, and several people are capturing (or looking at) CAN-messages from at least the EV-CAN buss. The AV-CAN has much less on it, and the CAR-CAN buss probably has many of the things that a non-EV auto would have: Door locks, windows, turn signals, etc.

We are giving our EV-CAN log files the ".evc" file extension, and the "normal car" CAN-log the ".can" extension.

It will be beneficial to use a standard file format so that we can share log files easily.

The records should be of fixed length, and include a second & millisecond time stamp (or space for it).

We are using 12-byte records, with the first two bytes being seconds*1024 + msec, msec as 0 to 999 and sec as 0 to 59, with the high byte first. With no time stamps, these would be 0x0000.

The next two bytes are the NAAA, where N = number of data bytes (0 to 8) and AAA is the message's right-adjusted 11-bit "ident" code, with the low byte first. (unknown why, but we could change the order, if desired).

Then 8 data bytes, filling the last unused data bytes with 0xFF values.

Then, we have a once-a second (could be once a minute) time stamp, formatted as a Pseudo-Msg, with NAAA being 0xFFFF. It contains the nunber of seconds past the start of 1970, and the microseconds of the "stamp-msg". More details if we decide to adopt this as an "exchange" or logging format.

Other better/different CAN-log suggestions or "standards"?
That sounds like a very sensible format, Gary.. except for the little-endian ID. :)
Do you have a small example of such a file or a segment you can post?

I don't know if there is a 'standard' representation for CAN bus logs, like pcap, but I can check what Agilent or Tektronix uses.

I'm not picky. Indeed, I keep changing the representation to match whatever looks to be of interest at the time.

I have a full log of EV CAN from a 20% to 100% charge last night that I may be able to get more from.

Are there any free/open-source/public CAN analysis tools? That would be a good file format to converge on.
Regards the AV-CAN, it's available on DTC pins 11 (H) and 2 (L) as turbo noted. There is a very slight amount of traffic on this buss, at the usual rate of 500 kbps. With the system Ready but at rest, messages occur about every half second. I'll capture some traffic shortly.

Other DTC confirmed pin assignments are Grounds on pins 4 and 5, +12VDC continuous Battery on pin 16.

The System Diagram figure at the bottom of manual page LAN-6 talks about DDR1 (Tx, Rx) diagnostic signals, and DDR2 (K-line) diagnostic signals, and suggests that both are present on the DTC. If I'm reading EVC-83 and EVC-84 (about the VCM) correctly, DTC pin 7 goes to VCM pin 81, described on EVC-71 as the K-line. The K-line and L-line variety of CAN comes from earlier CAN standards ISO 9141-2 and 14230-4, and use low-speed async-type signaling. If those standards had been fully implemented in the LEAF, the L-line would appear on DTC pin 15, but according to LAN-44 it is unpopulated. So far, I have not found the K-line on any other control module other than VCM. It does not appear on the TCU.

DTC pin 8 is supplied +12VDC by the Power Switch On, as shown on EVC-83/84.

There is another "private" CAN buss on the Quick Charge connector, connected to the onboard charger. See TMS-19
Ah, I forgot about the CHAdeMO CAN port. Good point.
The K-Line isn't CAN at all, of course. It's a UART at an oddball handshake rate and then 9.6kbps.

Pin-7 (K) is required on ICE cars, with (L) being optional on 15. I have some ISO 9141-2 adapters I can try, but I wasn't expecting the Leaf to put anything interesting there. It might be amusing. I figured it was unpopulated since the ScanGauge doesn't connect.