LEAF CANbus decoding. (Open discussion)

[Coffee_Slurry]

Regarding ID 5B9, here's a full charge cycle from about 20% to 100%:

07FF07FF28  ***** NEW ****** @   0m 0.553s                
014A07FF28 ^00000006B5000000 @   0m 1.575s                
014A67FF28 ^0000000000600000 @   0m 2.086s                
114A67FF28 ^0000001000000000 @   0m 3.108s                
194A67FF28 ^0000000800000000 @   1m 39.686s                
192C67FF28 ^0000000066000000 @   2m 8.812s                
190E67FF28 ^0000000022000000 @  14m 41.997s                
210E67FF28 ^0000003800000000 @  19m 5.152s                
20F067FF28 ^00000001FE000000 @  29m 22.414s                
28F067FF28 ^0000000800000000 @  39m 44.789s                
28D267FF28 ^0000000022000000 @  56m 36.019s                
30D267FF28 ^0000001800000000 @  65m 17.220s                
30B467FF28 ^0000000066000000 @  83m 49.110s                
38B467FF28 ^0000000800000000 @  92m 8.848s                
389667FF28 ^0000000022000000 @ 114m 12.289s                
409667FF28 ^0000007800000000 @ 124m 8.094s                
407867FF28 ^00000000EE000000 @ 144m 35.468s                
487867FF28 ^0000000800000000 @ 153m 8.490s                
485A67FF28 ^0000000022000000 @ 171m 49.071s                
505A67FF28 ^0000001800000000 @ 178m 17.421s                
503C67FF28 ^0000000066000000 @ 198m 0.343s                
583C67FF28 ^0000000800000000 @ 200m 22.395s                
583267FF28 ^000000000E000000 @ 206m 24.172s                
582867FF28 ^000000001A000000 @ 215m 47.785s                
581E67FF28 ^0000000036000000 @ 225m 13.955s                
601E67FF28 ^0000003800000000 @ 236m 47.871s                
601467FF28 ^000000000A000000 @ 237m 49.700s                
600A67FF28 ^000000001E000000 @ 249m 20.546s                
67FF67FF28 ^00000007F5000000 @ 276m 50.495s

So not a lot of updates to the value itself, and a sudden jump from 0x600A to 0x67FF

 

[evnow]

I suggest looking at values at just 3 charging times. Start of charging, 80% charged and 100% charged. Use timed charging to stop at 80% and take reading.

Get a dump of all the codes and write a little program to narrow the ones you want to look at closely.

 

[robtwn]

Charging session with battery showing 1 red bar and
10-miles remaining. Low Battery previously indicated.
Charge proceeds until normal full-battery cutoff.
This data is for ID=1DA on the EV-CAN buss.
The timestamp is first, HHMMSS.milliseconds.
All messages have 8 valid data bytes, numbered
D1 (on the left) through D8 (on the right).
On this ID value, messages occur every 0.010 sec.,
so for convenience of presentation, many are omitted
when the D1 value does not change.
We also noted that the low 4-bits of D7 make
the transition from 0->1->2->3 in each successive
message. It also appears that the D8 value changes
significantly less rapidly when compared with the previous
message of the same D7 value. The first message shown
below is the 130-th from the start of the session, initiated by
plugging in the J1772 connector, and it's timestamp is roughly
200-ms into the session. The entire session record of this single
ID address is nearly 2-million records, is available on request.
The (12-byte record) binary file of this entire session is nearly 38 MB.

Notice the fast ramp up of value of D1.
175809.352 01 00 00 00 00 01 03 9A
175810.882 03 00 00 00 00 01 00 9E
175810.892 18 00 00 00 00 01 01 5A
175810.902 33 00 00 00 00 01 02 81
175810.912 4D 00 00 00 00 01 03 FB
175810.922 5D 00 00 00 00 01 00 81
175810.932 72 00 00 00 00 01 01 C9
175810.942 83 00 00 00 00 01 02 9B
175810.952 90 00 00 00 00 01 03 67
175810.962 98 00 00 00 00 01 00 55
175810.972 A0 00 00 00 00 01 01 78
175810.982 A4 00 00 00 00 01 02 6E
175810.992 A7 00 00 00 00 01 03 E2
175811.002 A9 00 00 00 00 01 00 C2
175811.012 AB 00 00 00 00 01 01 49
175811.023 AD 00 00 00 00 01 02 51
175811.032 AF 00 00 00 00 01 03 DA
175811.052 B0 00 00 00 00 01 01 08
175811.072 B1 00 00 00 00 01 03 80
175811.112 B2 00 00 00 00 01 03 89
175815.442 B3 00 18 00 00 01 00 FF
180017.354 B4 00 18 00 00 01 00 EA
180822.835 B5 00 18 00 00 01 03 E7
181652.706 B6 00 18 00 00 01 01 61
182541.966 B7 00 18 00 00 01 02 6C
183531.443 B8 00 18 00 00 01 01 4B
184506.091 B9 00 18 00 00 01 01 4C
185545.497 BA 00 18 00 00 01 01 45
190639.602 BB 00 18 00 00 01 03 CD
192517.275 BC 00 18 00 00 01 00 D2
194943.741 BD 00 18 00 00 01 02 5A
201457.028 BE 00 18 00 00 01 02 53
203801.382 BF 00 18 00 00 01 00 DB
205858.063 C0 00 18 00 00 01 02 AC
211854.468 C1 00 18 00 00 01 00 24
213854.924 C2 00 18 00 00 01 03 27
215604.737 C3 00 18 00 00 01 01 AF
221126.556 C4 00 18 00 00 01 03 35
224551.284 C5 00 18 00 00 01 01 BD
231603.954 C6 00 18 00 00 01 00 31

stable at these values (D1 is C6, D6 is 01)
231651.702 C6 00 18 00 00 01 03 3B
231642.713 C6 00 18 00 00 01 00 31
231646.763 C6 00 18 00 00 01 01 B4
231653.412 C6 00 18 00 00 01 02 BE

until this change in D6 (01->00)
234223.475 C6 00 00 00 00 00 03 D7
234223.485 C6 00 00 00 00 00 00 DD
234223.495 C6 00 00 00 00 00 01 58
234223.505 C6 00 00 00 00 00 02 52

about 1-sec later, a very fast drop off in D1
234224.515 C6 00 20 00 00 00 03 73
234224.525 C6 00 20 00 00 00 00 79
234224.545 C4 00 20 00 00 00 02 F8
234224.555 C3 00 20 00 00 00 03 68

and by 0.1-sec later, D1 is down to 16
234226.625 16 00 00 00 00 00 02 ED

shortly thereafter, D7 has the high bit set
234226.805 14 00 00 00 00 00 80 E5

until this last entry in the charge session
234327.172 02 00 00 00 00 00 81 02

Regards the K-line issue: my OBD too also fails to connect to the LEAF. I wasn't too surprised!
While I'm no expert, I've been told that for OBD to work on K-line cars, the L-line is REQUIRED
for hadshaking, so this may have something to do with my device not working.

 

[turbo2ltr]

I previously thought the K line went to the TCU, but someone said it doesn't, so maybe it was the VPS box. I'm quite certain it was one of those two.

And yes, the L line is required for OBDII comms. K is optional. I think nissan just uses the K line for their consult.

Nice find Rob. I had not seen that. Not sure what it is though. The problem with all this stuff is you need some context to figure out scaling.


It is common to find parameters mapped and multiplexed in a single CAN message. When D7 is 0, D8 is the value for parameter X. When D7 is 1, D8 is the value for parameter Y, etc. If you split them out, I bet you'll see a pattern.


At this rate you guys will be able to make your own SOC gauge pretty soon. But it's fun watching...and learning. You guys are finding stuff I didn't.

 

[Coffee_Slurry]

Interesting 1DA messages!

I suspect the last byte is a checksum. I ran the previous seven through some CRC and CCITT algorithms, but nothing matched.

My pattern is similar to yours:

ID 1DA: 8 BB00180000010000  @   2m 48.592s                 
ID 1DA: 8 BC00180000010000  @  14m 10.630s                 
ID 1DA: 8 BD00180000010000  @  34m 1.211s                 
ID 1DA: 8 BE00180000010000  @  58m 57.947s                 
ID 1DA: 8 BF00180000010000  @  83m 13.335s                 
ID 1DA: 8 C000180000010000  @ 105m 9.866s                 
ID 1DA: 8 C100180000010000  @ 125m 26.048s                 
ID 1DA: 8 C200180000010000  @ 145m 3.981s                 
ID 1DA: 8 C300180000010000  @ 160m 52.153s                 
ID 1DA: 8 C400180000010000  @ 172m 22.989s                 
ID 1DA: 8 C500180000010000  @ 201m 39.211s                 
ID 1DA: 8 C600180000010000  @ 235m 54.879s                 
ID 1DA: 8 C700180000010000  @ 262m 18.995s                 
ID 1DA: 8 C600180000010000  @ 276m 49.229s

then the middle '18' becomes '20' and a rapid descent through the values C7 -> 01 in 50 seconds or so.
Same patterns in the D6/D7 bytes as you saw.

 

[garygid]

The D1 might be current flow, as controlled by the charger?

Compare with a 120v (12A max) charge.

 

[garygid]

I am writing a "CAN-Do" message log-reader and analysis helper program that can read in about 6 million messages in a couple of seconds. It is for Windows OS, at least XP and VISTA. It is an evolving work-in-progress.

As soon as I get it cleaned up a bit more, I am willing to post for download my most recent versoin of it, along with a test file or two, for interested parties.

As is, for your private, non-commercial use only.

If you can run my Sudoku Help-U-Solve ".exe" file (my source was Visual Basic 6) program, then you can probably run this CAN-Do program.

I will try to post some links here soon, maybe the Help-U-Solve download link tomorrow.

 

[Coffee_Slurry]

Sounds very cool.
What input does it use? (A specific CAN adapter, or a text file input?)

 

[garygid]

It presently just reads our CAN-LOG file. However, I intend to make it gather and log data (from 3 USB virtual serial ports), and also show interesting values in real time.

Our typical 12-byte binary record (in hex):
30 40 23 61 D1 D2 D3 D4 D5 D6 FF FF

0x3040 = 12.064 seconds
0x2361 = 6 data bytes, ident 0x123 (0x6123 as low byte first)
[or, 0x61 0x23, high byte first)
then, the 6 data bytes and two FF bytes to make a 12-byte record.

Perhaps our "standard" record should include two more leading bytes for hours and minutes, perhaps as 0xHHMM for 0 to 255 hours in the first byte and 0 to 59 (one byte unsigned integer) minutes in the 2nd byte?

Note: Zipping these files will reduce their size quite a bit.

 

[garygid]

We have 3 CAN-adapters, one for each CAN bus, that we have "programmed". They put out RS232 type serial data, via 3 Serial-to-USB adapters, to a UNIX logging program we made. I think it now logs only one CAN buss' data at a time, but we intend to make it log all 3 busses at once, probably into 3 time-stamped CAN-log files.

I intend to try to fold the same function into my CAN-Do (for Windows) program.

Others might have different adapters, and if they extract the messages to a serial RS232 type format, I can try to support several popular adapters.

The RS232 to USB (to virtual Comm Port under windows) adapters are only a few $ each.

What CAN readers are you successfully using, and what are the hardware and software interfaces?

 

[Coffee_Slurry]

I really liked my Intrepid Systems "ValueCAN" USB adapter, since it could handle a fully loaded 1Mbps bus, but it died on me. This is the second one that died this way, so I'm not inclined to buy another. (The hardware is likely fine, but it can no longer get out of the PIC bootloader, as if it lost its programming.) Doesn't seem to be supported any more. The bundled software is pretty nice, and I wrote my own Linux library for it. If only they were cheaper.

I have an Acacetus CAN-uVCCM, which is a fine isolated RS-232 adapter with a versatile serial protocol. Its fatal flaw is that it maxes out at 57600bps RS-232, which is nearly useless on today's system. Still, if you set up the filters appropriately or just use it as a test sender, it works well.

I have a pretty old (2004) Lawicel CAN232 adapter. This one works reliably, and has the unique ability to run at 230kbps on the serial side. This is the one I'm using now, and the serial format is well-documented:
http://www.can232.com/downloads.htm
In combination with an FTDI USB-RS232 adapter that can do 230kbps, it works great.

I see that Lawicel now sells a CANUSB, which has an integrated USB chip for higher bitrates.

I have an Atmel ATDVK90CAN1 kit somewhere and a Proconx.com XNUT-105 CAN board for embedded stuff. If we can get some clarity on the SOC messages, I'd probably build a mobile display out of that.

So this is all old gear from 2003-2005. What are the cool kids using these days? I imagine there's an Arduino CAN variant by now?

 

[Coffee_Slurry]

Perhaps our "standard" record should include two more leading bytes for hours and minutes, perhaps as 0xHHMM for 0 to 255 hours in the first byte and 0 to 59 (one byte unsigned integer) minutes in the 2nd byte?

I wouldn't do it. The Lawicel format just uses a 16-bit millisecond count that wraps to zero every 60 seconds. That works fine, and stays compact and predictable for arbitrary length log files.

Something to consider is a sential or sync value somewhere.. if your parser gets out of sync with your data, can it ever re-sync?

I haven't seen anything other than 11-bit Identifier standard messages on the two Leaf busses (CAN & EV CAN) so far, but the Lawicel format allows for those.

I used to put a lot of effort into filtering and distilling the logs down into something manageable, but modern machines make that a bit pointless.. even my crude C code can crunch through a 40MB log in seconds.

 

[Coffee_Slurry]

When I do a remote (telematic) poll for status, the EV CAN bus wakes up and carries traffic for 6.4 seconds.

There are only ~3,526 non-repeat messages in that burst.
(I mean messages that are not identical to their previous data.)

I captured one at 50% charge, and one after a 100% charge.

This brought to light message 5BC as being different between states.
Ignoring the cyclic bytes (D6,D7,D8), check out the first two bytes (D1 D2).
I see them increasing during charge, and decreasing during drive.

There are other interesting things happening in that message during drive, but just the two leading bytes stand out in their behavior.

At ~50% charge: 0x2903
At 100% charge: 0x4643

Values change very slowly in the tail end of charge too.

Not all values are represented. The second byte seems to have only four values, so it could be a 10bit value adjacent to something unrelated.

If we look at it that way, as a 10-bit value, then a 50% charge is around 0xA4 and a 100% charge tops out at 0x119.

I did catch one instance of the value INCREASING one step while driving, which may be regen. It's rare.
ID 0x5BC... This one is worth looking at more.

 

[TomT]

One thought that has been nagging me:

We all know that the SOC values represented by the bars have changed with the new VCM firmware, particularly at the bottom end. The question is, have the actual SOC values on the buss changed or has the way the dash interprets those values changed? If it is the latter, it is no big deal but if it is the former then it has large implications for a standalone SOC meter since the calibration of said meter might then change every time Nissan does a VCM firmware update...

Thoughts on this?

 

[Coffee_Slurry]

It depends on where the SOC-to-Bars "interpretation" happens.

I have to think/hope that the true SOC (or maybe just Ah & Volts) is on the data bus somewhere, but it's possible that this data is totally retained in the OBC and only digested step-wise information is placed on the bus for modules to use.

The hint would be that the dash on the car and the dash on Carwings agree regarding the number of bars. If they were computed separately from raw SOC, you might see discrepancies on some cars that have or don't-have the update, right? So there might be both on the bus.

The ECO screen seems to have more resolution in the "power consumed" display than the stupid bubbles on the dash, so that's promising.

Another possibility is that detailed SOC and real-time performance are only transmitted when requested by the CONSULT tool. This means we won't see them by passive monitoring, but would have to spoof the same messages CONSULT sends to delve into the battery state and wear information. Given how few messages are on the bus, this starts to look pretty likely.

Some quality time with a CONSULT-III+ and a bus analyzer would be really useful. If anyone knows where I could rent one, that would be awesome.

 

[TomT]

I have a lot of driving to do today and will be coming home pretty much empty, so I'll grab some data points through the day and report back on what I find.

The hint would be that the dash on the car and the dash on Carwings agree regarding the number of bars. If they were computed separately from raw SOC, you might see discrepancies on some cars that have or don't-have the update, right?

 

[turbo2ltr]

I've posted about all this in other threads.

The update changed the way things are calculated a lot.

Old way: LBC calculated bars
New way: the VCM calculates the bars.

edit: corrected TLAs for nissan's convention.

 

[Coffee_Slurry]

Oooooo... check this out.. Arduino CANBus shield, with microSD:
http://www.skpang.co.uk/catalog/product_info.php?products_id=706

And cheap:
http://www.sparkfun.com/products/10039
http://code.google.com/p/skpang/

I have one on the way. (Note that you can't use the nice molded pre-made J1962 from SparkFun to connect to anything but primary CAN.)

This shield, an Arduino and a Serial LCD display seem like the lowest-cost DIY dash display.
Cheers!

 

[Coffee_Slurry]

I think we have a winner for SOC in the top 10 bits from Identifier 0x5BC:

A short drive with stops:

A charge from 20 to 100%:

 

[jimcmorr]

I am truely impressed! Do the flat spots in the top plot coincide with slow driving or complete stops?

Good job!