Decyphering iMiEV and iON CAR-CAN message data

Please use this thread to discuss the meaningful data
fields that we are discovering, or investigating.

Please use these conventions in these discussions:

1. The Message ID is always in 3 hex characters, like 5BC
2. Refer to the data bytes as D1, D2, D3, D4, D5, D6, D7, D8
3. Show how to decode and scale the data, if known.
4. By default, D4 means all 8 bits of D4
5. Then, D5[7-4] would be the top 4 bits of D5

List of known values:
Note: A (#) following the description = displayed
on CAN-Do v198 Dashboard.

412 [D2 = Speed, in km per hour (#)
412 [D3,D4,D5 as ((((D3 * 256) + D4) * 256) + D5) = Odometer, in km (#)

373 [D3,D4 as (((D3 * 256) + D4) - 32768) * -0.01 = Pack Amps Out (#)
373 [D5,D6 as ((D5 * 256) + D6) * 0.1 = Pack Volts (#)

----------
6E1, 6E2, 6E3, and 6E4 are a secquence that contains
cell voltages (88 voltages) and teperatures (66 of them).
See the details in a later post #13.

----------

Here is capture to a .can file this time.
https://www.dropbox.com/s/a83h90quf3rpxge/i-MiEV_CanDo196c.zip

Note: the SoC was at or very near 100% at the start of this trip.

Also a .txt file is also included to verify the data is good.

The bug with displaying the Dashboard while reading
an ".alc" file has been eliminated.

http://www.wwwsite.com/puzzles/cando/CAN-Do-v198.zip

is the updated program.
Enjoy, and any suggestions are welcome.

jjlink,
Nice driving log, just over 6 million Messages,
logging about 31 minutes of driving. Thanks.

I do not yet have a Recipe entry for "SOC", but maybe
you will share Recipes for the any items that you have
found. This is the thread for sharing any such Recipes.

With V198 of CAN-Do ...
Your 6-million message ".can" log file works fine,
and I saved it as an ".alc" file and that works fine also.

I graphed Speed, Pack Amps Out, and Pack Volts, and
it seems to work quite well.

Might 3731 be something like the Highest Cell Voltage, and 3732
be the Lowest Cell Voltage (either scaled or with an offset?)

You guys are making great progress.
Cheers, Gary

I would like to be able to display the cell voltage,
Min, Average, and Max on the Dashboard.

What CAN Messages and fields do I use for
those, please. I seem to remember that the
temperature information is also available, right?

As I recall, it was a series of messages, with some
index value, but I think that priusfan must have
the exact details now, since his very nice 2nd
app shows all 88 cell voltages.

How many temperatures are reported?

to get details from batt cells,
this is in frames 6E1, 6E2 , 6E3 & 6E4
D1 is an index from 1 to 12
so, you get arrays with 48 positions
but for each combination, there are 2 values

yes it is tricky

better to open my project (the one for the batt) with b4a or read using VB the module scanner.bas.

Ok, here is a 1 Hour charge capture. The car was down to 4 bars left when I started the charging cycle. The BMS spent the first 15 minutes planning the charge, then it actually started charging for the next 45 minutes. It created 4,135,275 records in that hour, so Gary you can figure 6 hours at 240v will create something like 24,811,650 records. At the end of the hour capture you should be able to see when I pressed the button on the charge handle and stopped the charge cycle, unplugged the J1772, opened the car door and stopped the capture.

Here is the CAN file:
https://www.dropbox.com/s/rz4y19szmre9vkz/i-MiEV_CanDo198_1HC.zip

:idea: For those that don't realize it you can see the active data logging activity on the ODBlink LED (it flashes) when activating individual devices in the car with nothing else going on. This makes it relatively easy to isolate what device in the car sends what data on the CAN bus. For example you can open the car door and see data on the CAN bus is getting logged. In this way it would be pretty easy to figure out what devices in the car relate to what data is being send on the CAN bus (just by switching things on/off and writing down what you did at that time in the capture.

Since Gary has got the CAN-Do program to the point where any of you could start capturing data with an inexpensive ODBlink device, you may want to try it. I can explain how to capture log files with the CAN-Do program, its not hard to do.

Here are some sources for the OBDLink SX Scan Tool:
http://www.amazon.com/OBDLink-SX-OBD-II-Scan-ScanTool/dp/B004IAGNNG
http://www.scantool.net/obdlink-sx.html

Of course it would be really cool if we could ditch the USB wire and use this BT device with the CAN-Do program:

STN1110 Bluetooth OBD-II Adapter
http://batman.homelinux.com/blog/bluetooth-obdii-adapter/

CAN-Do has an Event Logging feature.

You can set up about 10 Event Messages to insert real-time
into the log data, human readable descriptions of events
that you intend to log. Perhaps "Door Opened", "Headlights On",
or some other events.

While logging, a tap of a number key on the keyboard
will insert the "Event" message into the log data.
This can be helpful when looking for some indication of that
event in the CAN data during later analysis of the log.

Although use of these messages is not perfectly supported
yet, this Event feature worked the last time that I tested it.

As I recall, I think that I raised the number of in-memory
Log Messages from 20 million to 30 million in CAN-Do v199.

In any case, the logging "should" quit gracefully when the
In-Memory Logging limit is reached.

I intend to add a Log-to-File option, rather than just the
current Log-to-Memory function.

There is an option to have CAN-Do begin logging when
the program starts up, but that option is not yet very
useful to you, since the OBDLink Setup scripts are not
yet automated.

Gary, I'm ready to do the low SoC to full charge log capture sometime in the next three days. Should I wait for the log-to-file feature before doing it?

No, the v199 and v200 have dimensions for 30 million
log messages, so they should work OK.
At least, there is no real reason to not try it.

Also, Log to File is ... not progressing very quickly.

Ok, I will try it tonight assuming I run the battery down today. Thanks

Battery Pack Cell voltages and Module Temperatures

---------
6E1, 6E2, 6E3, and 6E4 are a secquence of messages that
contains cell voltages (88 voltages) and teperatures (66 of them).

Presumably, there are 22 modules, each with 4 cells and 3 temperatures.

----------
6E1 is immediately followed by 6E2, then a about 20 ms later,
there is a 6E3, imediately followed by a 6E4. This group of 4
messages all have the same Index (1 through 12), and 12 such
groups, each with an increasing Index, make a full Set of
messages that carry data for 88 voltages and 66 temperatures.

The Set repeats about twice a second, I believe.

All of these messages use D1 as the Index (01 to 0C), and they
all use bytes D5 & D6 for one voltage, and D7 & D8 as the other
voltage. Each voltage is multiplied by 100 and stored as a 2-byte
integer. Values typically range from about 250 to 400 (2.5 volts
to 4.00 volts). The 4 messags, with 12 Index values, and two
voltages in each one ... have space for 96 voltages, but they
actually contain only data representing 88 voltages.

Similarly, there is space for 4 * 12 * 4 temperatures, but there
are only 2 temps in most of these messages, and even then,
there are only 66 temperatures used.

The unused data is typically whole bytes of zero value, I think.
[edit to remove emoji]
6E1 [D1 is the Index, value 01 to 0C
6E1 [D2 is zero
6E1 [D3 and D4 are two one-byte temperatures
6E1 [D5 & D6 as ((D5 * 256) + D6) / 100 = a cell voltage
6E1 [D7 & D8 as ((D7 * 256) + D8) / 100 = a cell voltage

6E2 [D1 is the Index, value 01 to 0C
6E2 [D2 and D3 are two one-byte temperatures
6E2 [D4 is zero
6E2 [D5 & D6 as ((D5 * 256) + D6) / 100 = a cell voltage
6E2 [D7 & D8 as ((D7 * 256) + D8) / 100 = a cell voltage

6E3 [D1 is the Index, value 01 to 0C
6E3 [D2 and D3 are two one-byte temperatures
6E3 [D4 is zero
6E3 [D5 & D6 as ((D5 * 256) + D6) / 100 = a cell voltage
6E3 [D7 & D8 as ((D7 * 256) + D8) / 100 = a cell voltage

6E4 [D1 is the Index, value 01 to 0C
6E4 [D2, D3, and D4 are zero (no temperatures)
6E4 [D5 & D6 as ((D5 * 256) + D6) / 100 = a cell voltage
6E4 [D7 & D8 as ((D7 * 256) + D8) / 100 = a cell voltage


Note that not all of the space for voltages or temperatures
is actually used.

Motor RPM
I believe it is in 298 ; freq is 10fps

formula is
M_RPM= D7 *256 + D8 - 10000

relation to speed ( KM/H) looks like :
Speed = M_RPM / 55.34
It depends on rear wheel diameter; in europe the tyre ref is 175/55 R15 - 77T

I am planning to use this info to interpolate the distance (the odometer is too coarse).

How many filters can be used with the OBDLink?
You are using 4 now.

Will you make a "simul" version of the cell-voltage App?

Cheers, Gary

Last night I made a CanDo v200 capture of a full charging session. It started from turtle mode @ SoC of 10.5% (according to the Android app) with zero miles of range remaining. It charged up to 100%. It was nearly 25 million records as we expected.

Its here:
https://www.dropbox.com/s/rh5gpdivs3058 ... 00--FC.zip

Great work, I am looking forward to seeing this Log.

However, your link is broken, I think.

I'm ready to start logging. I finally got the Lincomatic LeafCAN working.

Your logs look like this: "10/14/2012 9:30:22 AM", 1B600C0FFC0FFC0FF00

Mine right now look like this: 88A6:1B6 8 00C0FFC0FFC0FF00

I'll clean this up to work with the Can-Do program. Gary, did you say you go the Can-Do to work with the RealTerm date format? If not, I can wip together a windows form app to process the date correctly.

Next question, what kind of log would you like next? I can do a charge from bottom, a charge from 50% (which is my normal right now), I can also do a 43 kilometer commute and I can include my GPS data as well.

ML...
First let's get the Logging working, then both your 50% charging,
your commute, and then your deep charging would be great logs.

If you log to RealTerm format, then CAN-Do is able to read that
file, but the messages only have 1-second time stamps, not the
millisecond time-stamps that CAN-Do supplies.

So, putting out the 11-byte one-channel format that the GID-Meter
uses, and logging direct to CAN-Do would be a bit better, IMHO.

I believe that you know the 11-byte format, and now that you have
modified the program, and accomplished good data output,
changing to the 11-byte format should be easy.

I think that you can still use RealTerm to log the binary format,
and use a HexEdit program to look at the captured binary data.

I do not know if the "lincomatic" hardware/firmware captures
All the CAN Messages, but it might.

With the GID-Meter's present firmware, some too-fast messages are lost.
The hardware is capable of getting them all, but the example firmware
that we used, in conjunction with the "standard" CAN-support library,
did not re-enable the receiver fast enough to catch messages that arrived
too soon after the preceding message. We need to re-write the firmware
to use an interrupt to very quickly dump the Message into a ring buffer.
Hopefully, that simple change should do it. If not, we can use more than
one of the hardware message buffers. We have already tried that.

For most LEAF-related monitoring applications, like the
SOC/GID-Meter, the messages monitored are frequently
repeated, so losing some is embarrassing, but not very
important for the application.

Only a few people are doing serious logging, to explore
the details of the data. Most are just extracting speed,
power usage, etc.

However, for investigating the iMiEV's CAN bus data,
it appears to be important to get All the messages.
The best solution we have for that, right now, is the
OBDLink SX devices (about $50 from ScanTool.net or
Amazon.com). Also, CAN-Do now appears to support
the OBDLink USB and Bluetooth tools moderately well.
However, CAN-Do continues to evolve.