Decyphering iMiEV and iON CAR-CAN message data

[garygid]

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.

What format data is your LeafCan sending?

What program are you using on Win8 to capture the data?

Since each message that you describe is in the hex-text format
of MMMD1D2D3D4D5D6D7D8 then all of your messages should
be of odd length, with three MsgID hex digits and 2xN hex characters
for the N bytes of data. Of course, this is just counting the visible
characters, and ignoring any line-feed or carriage-return.

So, it looks like the one 6-character message is an error of
some sort.

I do not understand your "DLC 2" description of the 5-character
10100 message, which would be a MsgID of hex 101 with one data
byte of 0x00 (zero).

But, it does appear that you are capturing data.

If this data is punctuated with a line-feed character,
that is the OBDLink format, and you should be able
to use CAN-Do to capture the data, and it will add
time-stamps, insert Date-Time pseudo-messages,
and count any even-length message as an error,
instead of including it in the logged messages.

The latest version of CAN-Do is v205, which should
give you a message at the end of the capture with
the total number of errors, and the Max Bytes Used
in the Comm buffer.

Cheers, Gary

Have you tried to get this data into CAN-Do?

 

[jjlink]

Here is this mornings test capture with CAN-Do v205:


Capture by JJLINK, on Flickr

 

[garygid]

I guess that we should make a capture with RealTerm,
read that file into CAN-Do, and see if we get the same
kind of data-length errors.

 

[jjlink]

Gary, I checked and its getting errors in RealTerm. I see the red Error light come while capturing.

I used COM27:

It was initially set up 115,200 baud, 8,N,1.

The "Serial Enumerator" was NOT checked.

Buffer size is 4096.

Latency is at 1, is that to low a setting?

with these commands sent to it:
stsbr 500000
500000 (reconnect at 500000)
ATSP6
ATE0
ATH1
ATL0
ATS0
ATCAF0
ATMA

I loaded into CanDo:


RT-Capture1 by JJLINK, on Flickr


RT-Capture1a by JJLINK, on Flickr

The log file is here:
https://www.dropbox.com/s/xj5pa75wglprn7b/RTcapture1.zip

Any Ideas?

Thanks

 

[garygid]

Try latency of 4.

 

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

What format data is your LeafCan sending?

What program are you using on Win8 to capture the data?

....

The latest version of CAN-Do is v205, which should
give you a message at the end of the capture with
the total number of errors, and the Max Bytes Used
in the Comm buffer.

Cheers, Gary

Have you tried to get this data into CAN-Do?

Q1. I'm not sure the format, I just matched what you were sending in your Can-Spy program and this is the result.

Q2. RealTerm

Q3. No, I have not yet run Can-Do on this data. Is there a newer Recipe file?

 

[garygid]

Are you sending Ascii Hex characters, two per byte, or
are you sending binary bytes, one per data byte?

I send 11 binary bytes, three for the Sync and MsgID,
and always 8 bytes for the data, since I pad the data
out to 8 bytes, if needed, with 0xFF bytes.

That does not match what you are showing for
the messages. You show variable length, no Sync
byte, and no Data Length value (a nibble that I send).

LeafCAN sends different log data than the GID-Meter
sends. It sends Hex-character messages similar to
what you are sending, but LeafCAN adds two
checksum bytes, right?

Or am I totally confused (again)?

 

[jjlink]

Try latency of 4.

I'm still seeing the errors.

 

[FiddlerJohn]

I am impressed. This group is making great progress, and I want to help.

I have the premium i-MiEV with 10200 happy miles, an OBDLink SX, and a dual core Intel T3400 2.17 GHz Acer Aspire Laptop with 4GB RAM and 32 bit Vista7.

I currently have two issues:
1. The OBDLink connects thru the USB to blink the OBDLink yellow light, but the OBDwiz application never connects to the OBD ECU CAN Bus. The Automatic Protocol setup checks all rates including 500 kBaud at 29 bits but never connects -- NO DATA.

2. Running CAN-DO gives:
"Component "MSCOMM32.OCX" or one of its dependencies not correctly registered: a file is missing or invalid"

... remove the "-99" from the file name and usually replace the standard file in C:\windows\system32\
Enjoy, Gary

Removing "-99" and rebooting produced the same results.

Any suggestions?

I intend to delete the current "MSCOMM32.OCX" from the C:\windows\system32\ and add the new one (without the -99) again.

 

[priusfan]

1) Do NOT use OBDwiz , this app is not appropriate for electric cars.

2) about mscomm32.ocx, do not delete it, maybe rename it with a suffix like .ocx_old, so you can get it back if necessary.

but FIRST, follow this : method

 

[jjlink]

Once you have the "MSCOMM32.OCX" in place you can try RealTerm and/or Can-Do using these settings.

The COM port should be initially set up as 115,200 baud, 8,N,1.

The "Serial Enumerator" should NOT be checked.

Buffer size should be 4096.

Latency at 4.

with these commands sent to it:
stsbr 500000
500000 (reconnect at 500000)
ATSP6
ATE0
ATH1
ATL0
ATS0
ATCAF0
ATMA

The first check to do is with RealTerm and see if the red error light comes on every xx number of seconds while either capturing or just displaying the data as it scrolls by. If you don't see errors try capturing using Can-Do.

 

[garygid]

Sorry that I have not gotten a better version of CAN-Do posted,
but I have been trying to adjust to the daily X-Ray radiation therapy.

Hopefully, I will be able to get something posted in a week or two.
Cheers, Gary

 

[garygid]

I intend to try to get the latest CAN-Do tested today, and
hopefully post a link here.

For updating the Recipe file, and the iMiev dashboard screen,
what is the latest list of "discovered" CAN Message data variables?

 

[garygid]

Another week gone by, and I still need to get
the testing of the latest CAN-Do done.

However, Merry Christmas to all.

 

[JoeS]

I'm saddened that the iMiEV CAN investigations have stalled out. For myself, I'd simply like something to display the following:
1. Individual cell voltages (preferably all at the same time bargraph/numeric)
2. Traction pack total voltage
3. Numeric State of Charge
That would keep me happy...

Anything out there that can do this with what we know today?

 

[MLucas]

Don't fret, Joe. This project is still alive and well. Priusfan has an excellent solution using an Android based tablet and a bluetooth OBDII connector. I've recently revived my effort and currently working on developing a Windows application that will read and decypher the messages. I'm using a modified LeafCan that I bought from lincomatic and my Dell Duo tablet to run the Windows program. Not as elegant as Priusfan but its what I have to work with and I'm also a .NET Software Engineer and don't feel like learning another coding paradigm right now.

I ran a test on Wednesday, I was able to read the messages but had some display issues.

 

[jjlink]

Also Gary posted a new version v2.1.0 of his CAN-Do software to his website. It now supports the i-MiEV. I have downloaded and tried it. We should try updating its CAN-Recipe file with any known values that priusfan has discovered.

Here is a link to Gary's posting from the Leaf Forum -
http://www.mynissanleaf.com/viewtopic.php?f=45&p=282551#p282551

 

[MLucas]

I was able to succesfully run my windows program and monitor a few of the cars vitals; speed, autonomy (range), rpm, soc and odometer. This means I'm definitely reading data from the obdII port and I can confirm it with my instrumentation. Next, I need to work out some issues with reading the data from my FTDI USB cable, not a big deal but something I noticed last night while testing the system.

Then I can move into creating a workable interface. The image here is just a quick layout so I can test the FTDI capabilities. Thanks Gary, Priusfan, lincomatic and anyone else that I failed to mention that helped me with examples and advice. After I get this program a little further along the development path, I'll make it available to the forum here to use as you see fit.

 

[jray3]

Thank you, oh Data Gods from one who hopes to piggyback on your progress. Logging the car's vitals on different runs and comparing that to elevation and acceleration would produce some interesting charts.

 

[TestO]

Was googling for information regarding i-Miev CAN and find this information regarding i-Miev CAN Gateway.
http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf

Here we can see some message transmission intervals - that is a big clue and should help us narrow things down while decrypting CAN messages.