LEAF CANbus decoding. (Open discussion)

Gary,

I am planning to come down to the gathering tomorrow I will bring a few LCD's with me.
I will bring:
2 Line text (SPI or I2C) - I have one of these for you to go along with a prototype EVSE board.
1.8" Color LCD (SPI)
2.8" Color touch screen (8bit digital + Control)

The AVR can has both the I2C and SPI so if you can modify the firmware you should be able to add a display right to the AVR-CAN.

Chris

I updated the first post in this (long) thread with more detailed pinout information.
Please let me know if I missed anything or got it wrong.

I will bring my bag of CAN stuffs to the San Diego HTB meet-up.

Is there any chance we could persuade Leon or one of his minions to bring a CONSULT-III+?

Moved to the right forum and stickied.

Once this takes off, we could make a separate sub-forum.

Your data in the 1st Post looks good.
The drawing of the ODB connector is for the female socket in the car, as seen from the plug side.

I will have to look at LAN-33. Thanks.

We read real-time data from the EV CAN buss yesterday, and displayed extracted values on the laptop's screen. SOC, Motor and Regen Power (apparently), etc.

Tomorrow we will test today's coding to read all 3 CAN busses at the same time.

We will soon have a list of materials, and assembly instructions so that any interested person can read 1 to 3 CAN busses, and examine the data or watch the CAN-Do "dashboard".

Then, back to digging more meaning out of the data.

It is splendid to have a group working on this "exploration" project.

garygid said:

The drawing of the ODB connector is for the female socket in the car, as seen from the plug side.

Click to expand...

Good point! So noted.

But from the Plug-in side of the connector, not the "wiring" side.

Important note about the CAN-BUS Arduino Shield from sparkfun/skpang -- the DB9 pinout does NOT agree with the Lawicel and ValueCAN pinouts.
Arg.

Also, it may not be possible to do "bar graphs" on the Serial LCD, using the same 'custom bitmaps' trick as the Optrex displays.
I'm starting to think AT90 is the way to go if you don't need easy microSD and GPS.

GroundLoop said:

I'm starting to think AT90 is the way to go if you don't need easy microSD and GPS.

Click to expand...

While it would be nice to have a log that can be uploaded to a PC - but point in time numbers are probably good enough for now.

I know this is quite a mature thread already, but here is an interesting link for people interested in building their own
CAN decoder. Its in German, but there are detailed part-lists, circuits and libraries to build an Arduino-based CAN reader.
It looks like the parts come out to something ~ <$20 (without the CAN connector & display).

http://www.kreatives-chaos.com/artikel/can-testboard

Success!
Our FIRST drive while recording all three CAN-buss messages, AND seeing the changing data on the laptop's screen (on the CAN-Do "dashboard"). [EV-CAN, CAR-CAN, and AV-CAN messages.]

Equipment:
1. An "OBD" cable, ending with
2. Power, Ground, and two CAN signals (H & L) on a 9-pin "D" female connector. [One for each CAN buss]
3. An AVR-CAN Development Board for the Atmel AT90CAN128 (not 228, sorry) micro-processor. [One for each CAN buss]
4. An RS232 to USB connection (to a virtual Comm/TTY Port in in the PC). [one for each channel]
5. The CAN-Do program, version 1.3.3 or later.
6. Laptop or Netbook running XP or Vista (or Win7?).

Note: I bought a 4-port RS232 to one USB adapter that seems to work very well.

(Edited to fix error with 0x1DB byte field description)
Had a little time to play with the CAN codes today;

Based on turbo2ltr's hints and some info from Groundloop, Gary, Robert and others, looked at the ID 0x1DA.

Bytes D4 & D5 behave like RPM, when scaled. I logged data while on a drive. plotted the "RPM" field. Since the LEAF is a direct drive EV, we can go from RPM straight to MPH or even use it as an odometer as I show in the plot below.
Integrate the time-tagged, "RPM" field (blue curve) and scale to the gear ratio and tire dimensions to get miles traveled (red curve). Compares perfectly with odometer reading for this trip.
Putting the LEAF in reverse works too, RPMs go negative.



Next I looked at ID 0x1DB:
Three things of interest. This field seems to commutate through 0,1,2,3 identifiers. I wonder if this is identifies different battery pack "strings". The numbers track pretty well with some leading and lagging during high loads. But, I may be reading too much into the 0,1,2,3 thing.




A portion of the 8 bytes behave like current to/from the battery editD1D2); positive when charging and regen and negative when sitting with car "ON" or driving. "Volts" seem to reside in Byte D3 and the upper 2 bits of D4.
Direct correlation with acceleration/deceleration as shown in plot. I plotted a short segment of a drive where I got on the freeway and then took the next exit off.

My scaling for current and Volts is a total guess. First plot is "Amps" second is "Volts". Notice the 1/RC exponential voltage sag during regions of high power draw and voltage recovery during regen... seems plausible.








Still looking through the IDs for more hints... too much data...good times.

I'm ordering up an AT90 board this week.

I have to say the Serial LCD has been a real disappointment. It's too slow for a rapid (bar graph) display, frequently gets corrupted at 9600bps, and needs delays inserted between most commands.

I'm going back to the standard 4-bit Hitachi displays.

Aside from that, I do have a crude SOC gauge in my car now, showing 98.5%

sparky, nice plots and research!

The idea of a single message rotating through battery strings (0/1/2/3) is very interesting.
I may have to collect data differently.

Great work and graphs!

I will add these four values (Pack Volts and Amps, Speed/RPM and Trip-Distance) to my Dashboard tomorrow afternoon.

If you send me one of your Car-CAN message Log files, I will try to add reading support for that format in CAN-Do.

Also, I will try to reproduce the results from the data in my own Car-CAN buss logs.

Do the RPM (1DA) messages come at nice regular intervals so that "integrating" the indicated speed gives an accurate distance, or does one need to multiply by varying time intervals?

Again, super work!
Thanks, GaryG

There are a number of other messages that have a 0, 1, 2, 3 rotation.

Finding a 4 x 12 would be the number of modules, with two cell-pairs per module.

garygid said:

S
3. An AVR-CAN Development Board for the Atmel AT90CAN228 micro-processor. [One for each CAN buss]

Click to expand...

After hitting all my supplier sites, I have to conclude that this is a typo, and not some new hot Atmel CAN board with twice the flash. Aw.

Yes, 128, not 228 ... I fixed the post. Thanks, GL

garygid said:

Great work and graphs!
I will add these four values (Pack Volts and Amps, Speed/RPM and Trip-Distance) to my Dashboard tomorrow afternoon.
If you send me one of your Car-CAN message Log files, I will try to add reading support for that format in CAN-Do.
Also, I will try to reproduce the results from the data in my own Car-CAN buss logs.

Do the RPM (1DA) messages come at nice regular intervals so that "integrating" the indicated speed gives an accurate distance, or does one need to multiply by varying time intervals?

Again, super work!
Thanks, GaryG

Click to expand...

My pleasure!
I don't know how useful the distance estimator is. I mostly used it as a check of my interpretation of that data field (and 'cuz it was fun). I wasn't sure about the regularity of the 1DA packet so, I integrated as a function of my CAN time packets. But, I think your CAN reader has that built in. Also, I don't really generate "Car-CAN" messages but my own flavor (per Robert's very useful source code mod) that I prefer for debugging with Python. So, I doubt my logged data is much help at this point. Everything comes across the RS232<->USB in the same format (binary, with cksum syncing) but gets parsed into ID-based files in human readable ASCII.
As you noted, there's a lot of 0,1,2,3 action. Seems to be in nearly every 0x1XX packet I examine.

For trial plotting of 2-byte data "values" in CAN-Do, I intend to add the following:

1. D?, where the ? is a number 1 to 8 selecting a data byte, 0 for zero value
2. Mhh is two hex digits to Mask the selected data value
3. Sn is one signed decimal digit to shift (multiply by 2^n) the value before combining

Something like:
D4 MFF S0 + D3 M07 S8
(low 3 bits of D3 followed by all 8 bits of D4 => an 11-bit value)
or
D4 MC0 S-6 + D3 M3F S2
(low 6 bits of D3 with high 2 bits of D4 => an 8-bit value)

Then scale the graph by letting the user select the MAX and MIN values. If either is zero, the data could auto-scale.

Probably I need to add a selection of "signed" or "two's compliment" type values.