Decyphering iMiEV and iON CAR-CAN message data

[garygid]

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.

[jjlink]

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

[garygid]

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.

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

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

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

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

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

[priusfan]

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).

[garygid]

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

[jjlink]

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

[garygid]

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

However, your link is broken, I think.

[MLucas]

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.

[garygid]

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.

[garygid]

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.