GroundLoop
Posts: 1725
Joined: Mon Sep 13, 2010 9:31 pm

Re: LEAF CANbus decoding. (Open discussion)

Mon May 30, 2011 10:40 pm

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:

Code: Select all

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:

Code: Select all

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?

GroundLoop
Posts: 1725
Joined: Mon Sep 13, 2010 9:31 pm

Re: LEAF CANbus decoding. (Open discussion)

Tue May 31, 2011 11:57 pm

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:
00[4D][4B]005F[4A]5B08

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.

GroundLoop
Posts: 1725
Joined: Mon Sep 13, 2010 9:31 pm

Re: LEAF CANbus decoding. (Open discussion)

Wed Jun 01, 2011 12:04 am

ID 5B9 (twice per second) does seem to be promising as something else increasing during charge.. very slowly.

Code: Select all

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.

jimcmorr
Posts: 398
Joined: Tue Jan 11, 2011 8:41 am
Delivery Date: 02 Apr 2012
Leaf Number: 018747
Location: GA

Re: LEAF CANbus decoding. (Open discussion)

Wed Jun 01, 2011 8:16 am

GroundLoop wrote:ID 5B9 (twice per second) does seem to be promising as something else increasing during charge.. very slowly.

Code: Select all

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.
Jim M
res: 25APR10 #612239F1 Glacier Pearl SV
Ordered: 03Mar12 Cayenne Red SL
VIN: 18747 - pickup: Mon 2Apr12
22Apr14: over 20K mi / lost 1 capacity bar Mar 2014
It isn't 100% electric if you have to put gas in it.

User avatar
garygid
Gold Member
Posts: 12464
Joined: Wed Apr 21, 2010 8:10 am
Delivery Date: 29 Mar 2011
Leaf Number: 000855
Location: Laguna Hills, Orange Co, CA

Re: LEAF CANbus decoding. (Open discussion)

Wed Jun 01, 2011 8:46 am

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).
See SOC/GID-Meter and CAN-Do Info
2010 Prius, now for sale
2011 LEAF, sold in 2015
2018 Tesla Model 3
2014 Tesla S, Model 3 in 2019
PU: SDG&E
Solar PV: 33 x 225W -> 7 kW max AC
To Sell: X-treme 5000Li EV motorcycle

User avatar
garygid
Gold Member
Posts: 12464
Joined: Wed Apr 21, 2010 8:10 am
Delivery Date: 29 Mar 2011
Leaf Number: 000855
Location: Laguna Hills, Orange Co, CA

Re: LEAF CANbus decoding. (Open discussion)

Wed Jun 01, 2011 9:07 am

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?
See SOC/GID-Meter and CAN-Do Info
2010 Prius, now for sale
2011 LEAF, sold in 2015
2018 Tesla Model 3
2014 Tesla S, Model 3 in 2019
PU: SDG&E
Solar PV: 33 x 225W -> 7 kW max AC
To Sell: X-treme 5000Li EV motorcycle

User avatar
garygid
Gold Member
Posts: 12464
Joined: Wed Apr 21, 2010 8:10 am
Delivery Date: 29 Mar 2011
Leaf Number: 000855
Location: Laguna Hills, Orange Co, CA

Re: LEAF CANbus decoding. (Open discussion)

Wed Jun 01, 2011 9:36 am

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"?
See SOC/GID-Meter and CAN-Do Info
2010 Prius, now for sale
2011 LEAF, sold in 2015
2018 Tesla Model 3
2014 Tesla S, Model 3 in 2019
PU: SDG&E
Solar PV: 33 x 225W -> 7 kW max AC
To Sell: X-treme 5000Li EV motorcycle

GroundLoop
Posts: 1725
Joined: Mon Sep 13, 2010 9:31 pm

Re: LEAF CANbus decoding. (Open discussion)

Wed Jun 01, 2011 10:03 am

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.

robtwn
Posts: 2
Joined: Sat Feb 19, 2011 4:18 pm

Re: LEAF CANbus decoding. (Open discussion)

Wed Jun 01, 2011 10:51 am

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

GroundLoop
Posts: 1725
Joined: Mon Sep 13, 2010 9:31 pm

Re: LEAF CANbus decoding. (Open discussion)

Wed Jun 01, 2011 12:06 pm

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.

Return to “LEAF CANBus”