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?

 

[garygid]

Jjlink,
This "distorted" data is coming from somewhere.
Have you looked at it with my new "(*) Errors"checkbox?

What driver, if any, did you install with the OBDLink?

Was it the one that came on the CD with the device?

See if there are any options in the Comm Port settings
for your data connection to the OBDLink SX.

If there is Serial Enumeration, make sure that you
have it un-checked.
If there is Latency, perhaps lower it

I can try to connect my OBDLink SX device
to my Win7 laptop.

 

[jjlink]

I had installed ODBwiz v2.13.1, I just uninstalled it for now.
I'm not sure where the MSCOM32.OCX came from. I will have to go to my backup disk to compare it to your copy.
Serial Emulation is off, I will check Latency and try the new "(*) Errors" checkbox when I test again this afternoon.

Thanks

Ok, I just did a quick 5 minute drive test with the new "(*) Errors" checkbox and it says I got 58 errors on 396,561 records. I believe it said 5 errors on the comm input error count. I used com27 rather that com10 this time, Serial Emulation is off, Latency was changed to 8 from 16.

Any other ideas?


58 msg-IDs by JJLINK, on Flickr

 

[garygid]

No great ideas, but I had to fuss with the settings
for a 4-port RS232-to-USB adapter that I use
before I could get totally good data with Vista.

Now, I am not absolutely sure that CAN-Do is not
causing the errors during input, but ... it is hard to test
when things happen so fast and so infrequently.
They could come from the OBDLink but I did not get
any errors like this with the LEAF and The USB-connected
OBDLink SX.

I have made a new CAN-Do v204 with a "Clean (*)" button to
"move" these error messages from the parent MsgID into another MsgID,
thereby "cleaning" the wrong-length data messages from the parent.

The new MsgIDs are DD0 through DDF, so that they are not confused
with the normal MsgIDs (which are 7FF and below).

This fuction looks at all your listed MsgIDs, finds the dominant
data length, and changes the MsgID of the "error" Messages
of length N to MsgID = 0xDDN, keeping the same N data length.

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

Try it on the "corrupted" 24 million charging log.
It helps in displaying ad graphing the data.

 

[garygid]

jjlink,
From your picture, I see that MsgID 200 has at least one (*) error.

You can try v204 on that log, to get familiar with what
the new functions do.

 

[garygid]

jjlink,
What is the Comm Port buffer size?

While gathering data, the Error field is in pink on the right
side of the Message-Count field. With a "Show Buffer Size"
(or similar wording) checkbox, one can see the maximum
number of bytes that were in the Comm Port buffer each
second, allowing you to judge if bytes might be getting lost
while logging.

Also, do not check the "Show Dashboard" checkbox while
logging, because that might be taking too much compute time,
but that would usually show up in the Max Buffer size, I
believe.

I will try to go through the code for capturing the logs,
and look for any data clobbering. Unlikely since you are
only running one channel of log-capturing, but I will look.

Cheers, Gary

 

[jjlink]

jjlink,
What is the Comm Port buffer size?

While gathering data, the Error field is in pink on the right
side of the Message-Count field. With a "Show Buffer Size"
(or similar wording) checkbox, one can see the maximum
number of bytes that were in the Comm Port buffer each
second, allowing you to judge if bytes might be getting lost
while logging.

Also, do not check the "Show Dashboard" checkbox while
logging, because that might be taking too much compute time,
but that would usually show up in the Max Buffer size, I
believe.

I will try to go through the code for capturing the logs,
and look for any data clobbering. Unlikely since you are
only running one channel of log-capturing, but I will look.

Cheers, Gary

Ok, for 238678 capture records, max buffer size shows as 888. This was just for a minute of driving. The max buffer size seem to grow pretty fast during this small amount of capture time.

Comm Port buffer size send/receive is 4096.

Yes, I just tried the "Clean (*)" button.

Thanks

 

[garygid]

I graphed the D8 byte (0xFF) of the DD0 through DD7 "Error (*)" MsgIDs
and they are sprinkled throughout the 6 hours of logging.

I looked at the CAR-CAN OBDLink format logging code,
and I did not find any errors, but there was a small
error in the EV-Comm version of the logging code,
which nobody has used yet. But, nothing that would
produce "distorted" messages.

I think the Max Buffer Used is just over one second.
However, I will add a Max Buffer Used for the whole
logging session, and the Error Count, to the message
at the end of the logging session.

 

[garygid]

jjlink,

The message that you got after clicking the Show MsgIDs button
does not count any errors, it is just telling you that there are 58
MsgIDs in the list that was just created.

The "(*) Errors" checkbox only works when one double-clicks
a a MsgID in the list, then it tels you about the "errors"
(of this non-dominant data length type) in the messages
in that have that one MsgID.

I will change the tool-tip to mention doube-click.

However, the part of the list that I can see shows that
MsgID 200 has at least one such error.
I will put out another version of CAN-Do is a short while.

Cheers, Gary

 

[garygid]

CAN-Do v205, mostly minor changes, some better messages, I hope.

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

Please let me know what you experience, mentioning the Version Number.

 

[jjlink]

CAN-Do v205, mostly minor changes, soe better messages, I hope.

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

Please let me know what you experience, mentioning the Version Number.

Thanks, I will try it first thing in the morning.