Decyphering iMiEV and iON CAR-CAN message data

[jjlink]

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

However, your link is broken, I think.

This should work:

http://db.tt/DmMRO60d

or

https://www.dropbox.com/s/vgqow7feqdnxnw2/i-MiEV200.zip

[garygid]

I will try to look at your log tomorrow morning.
I want to see if you are getting all the messages.
First, I will look at the 6E1,2,3,4 series to see if
they are all there.

CAN-Do v202 is available, see
www.wwwsite.com/puzzles/cando/CAN-Do-v202.zip

Cheers, Gary

[MLucas]

I came in on turtle last night and so I decided to run a log with the cleaned up code. It looks like what the other captures look like, let me know if it is usable. I connected my tablet with my LeafCan and OBDII cable with the FTDI cable at 7:01 last night. It took me another minute to plug the charger in. If you scan the log you'll see the chatter in the beginning and then around 7:02 less DLC 2 messages are coming in with the much longer DLC 8 messages. Do we need these DLC 2 messages? I can filter them out if they are not necessary.

I let this run overnight until about 7:00 AM. There is a full twelve hours of logs. The charging stopped somewhere around 1:00 am. My car took on six hours worth of L2 charging last night, that would be about right.

I have not yet had the time to run this through Can-Do to see if it will work or not.

Here's where you can find the 5meg text file: https://www.amazon.com/clouddrive/share?s=aJGVSCsiQC0hLn1AwlE5QE

[garygid]

Well, the 24 million Log Messages look mostly good,
but there is a sprinkling of some kind of data errors.

For example, most of the MsgIDs as listed in the Main
Window have an asterisk (*) for their data length, which
means that there is more than one data length for that
MsgID.

These "errors" appear to be very infrequent, but
it would be good to understand where they come from,
and eliminate them, if possible.

Graphing the Pack Amps Out and Pack Volts, we can see a
"pause" in charging, about 15 minutes long, perhaps.

We can also see the data "spikes", that the "errors" are
causing, most likely.

I will try to add some code to CAN-Do so that we can see
better what these errors are. I should be able to display
the Messages with "unusual" data length values in context,
to see if there is a pattern to the bad-data messages.

However, this is a very helpful log, Thanks.

[garygid]

The Log I made using the OBDLink SX on the LEAF had
none of these "errors". I wonder if we are doing something
differently that might corrupt some of the data.

I connected a 6-foot extension cable to the OBD port, and
then connected the OBDLink SX directly to that cable, and
to a USB port on my Vista (32 bit) laptop.

The messages from the OBDLink SX do not have any error-checking
or Data-Length specified explicitly.

CAN-Do waits for a line feed <lf> character.
Then, after any <lf>, it assumes that the first 3 characters
are Hex for the MsgID, and remaining characters up to the
next <lf> are 2-characters per byte of data.

No data is OK, and 1 through 8 bytes of data is OK,
but if there are more than 16 data characters (8 bytes),
or an odd number of data characters, the message is
considered to be an error, and CAN-Do waits for the
next <lf> to get re-synchronized.

At the end of logging, you should see the count of the
messages logged, and a count of these "errors".

What are you doing that is not identical to my test?

[jjlink]

I'm using a OBDLink SX on USB as COM10 and no extension cables. The Laptop has Win7x64 w/core i5 @ 2.4GHz. I saw CanDo say 24,xxx records, however I don't remember it saying it had any error records.

[MLucas]

For me, I'm not using the OBDLink SX and using the LeafCan, instead with a Dell Duo convertable running Windows 8. I compared my logs with jjlink and they do look similiar with the same type of messages coming through. I analyzed my data for a pattern and it looks like there are common lengths of messages with mostly the same data. The messages with a length of 5 or what would come through the port as a DLC 2 are all 10100. There is one length of 6 in my data, 346271. The next length of 7 are all 3250100. Then come the 17 character length messages, 21000000000000000 and 41850000000000000. The rest are all the 19 character length messages.

I've noticed something interesting about the data I submitted. There is a repetition of messages up to the time I plugged the EVSE into the car. It appears to be an 18 message 'sentence' with the 3250100 message repeated twice at the end of the sentence, maybe its like a line termination. I'm thinking the 3250100 is not an error but part of the way the messages are being sent. This is all just a guess from looking at the data - I'm no expert on this but I am seeing a pattern. In my data, the first sentence repeats itself 18x (interesting). Here is one of these 'sentences':

1B600C0FFC0FFC0FF00
3250100
412FFFF002865000112
1B600C0FFC0FFC0FF00
3250100
38D0400000000000000
1B600C0FFC0FFC0FF00
3250100
3250100
1B600C0FFC0FFC0FF00
3250100
39B0003100400000000
3250100
1B600C0FFC0FFC0FF00
3250100
3250100

[priusfan]

bonsoir
from my observations , when ignition is on,
325 01 00 is always the same and comes exactly 50 times/sec

[garygid]

OK, here is a new version of CAN-Do (v203)
with a new Error Analysis checkbox on the Main Window.

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

This checkbox is labeled "(*) Errors" and when checked, it modifies
the list produced by double-clicking any MsgId is the list above.

Each MsgID has a N: before it, indicating the data-length
of messages with that MsgID. However, if the MsgID has
more than one length of data, an asterisk (*) is displayed
istead of a number (hex digit).

Usually, any sigle MsgID has only one data length associated
with its messages, but it is possible that there are some
messages with the same MsgID, but a different data length.

In the iMiEV, it appears that any MsgIDs with more than one
data-length are due to data or bus errors, and not intended.
To better investigate this, check the "(*) Errors" checkbox,
and then double-click any MsgID with the "*:" prefix.

Then, all those messages will be analized to find the domiant
(most frequent) data-length, what other data lengths are
found in these messages, and how many messages have
each of the discovered lengths.

When there are thousands of messages with the dominant length,
but only a few messages with different lengths, the few are very
lkely errors. Sometimes, these errors make it very difficult to
graph and analize the data.

I suspect that I will add a "Clean" function, replacing all these
"bad" Messages with the MsgID EEE or something like that.
For now, you can at least examine your data better.

[MLucas]

bonsoir
from my observations , when ignition is on,
325 01 00 is always the same and comes exactly 50 times/sec

The data I submitted was done without the ignition turned on. I was simply hooking up my equipment before I plugged in the EVSE for the night. The car was spitting out these messages even without any activity on my part like charging or ignition on. I noticed as soon as I plugged in the OBDII port from my LeafCan. That is the last step I do, I start by firing up the computer, then plugging in the FTDI cable followed by connecting that to my LeafCan. I removed the power wire from the FTDI cable so that the LeafCan only starts when the OBDII cable is plugged in.

Is anyone else seeing this?