MiEV-CAN

Mitsubishi i-MiEV Forum

Help Support Mitsubishi i-MiEV Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Between GaryGid and PriusFan we should be able to figure this out.

I got my LeafCan V1 in the mail from LincoMatic this weekend. I'll need to take sometime and figure it out. Still need the OBD-II cable, that is on its way.
 
Great, I just got the OBDLink SX (USB to PC), which is on sale
for about $45 at Amazon, or $50 from the www.ScanTool.net site.

I will try using it with their included OBDwiz software on a Toyota Camry
to see if I can capture a full (no filters) log of the raw CAN Messages.

I want to use it in a READ-ONLY mode, where it will NOT try
to connect to other non-CAN pins on the OBD connector.

I also have 3 of the DIP version of their STN1110 chips, but I have
not yet had time to do anything with these DIP chips.

Did you have success logging ALL the CAN Messages?

More later, Merci
 
Bonjour,
on my side, yes, I can log all the messages.
to avoid bufferoverflow, you should change the default interface'speed from 115kbps to 500000bps (once only)
a) connect to your interface with a terminal @115kpbs
b) send the command "stsbr 500000"
c) reconnect @500000bps


see this thread

d)now, to monitor all the messages, send following sequence:
"ATSP6" ' CAN 11 bits @ 500k
"ATE0" ' Echo OFF
"ATH1" ' Header ON
"ATL0" ' no crlf
"ATS0" ' suppress spaces
"ATMA" ' Monitor All

if you get CanErrors, add the command ATCAF0

I sent to Gary a MP with a link to a big log and to an excel spreadsheet used for detailing this log.

I hope the iMiev is exactly the same as Peugeot iOn regarding CAN messages...
 
Gotten a little lost here. Are we talking about a Prius or a Peugot i-On? I've looked over the excel workbook and I see a page for each PID from 101 to 75B. What vehicle did this come from and what conditions was it taken?

Any info to catch us up would be great! Also, if anyone knows of a good primer on this CAN bus stuff, that would be helpful to the group. I've been reading stuff on the net and getting caught up the best I can.

Thanks for all the help on this.
 
garygid said:
Great, I just got the OBDLink SX (USB to PC), which is on sale
for about $45 at Amazon, or $50 from the http://www.ScanTool.net site.

I will try using it with their included OBDwiz software on a Toyota Camry
to see if I can capture a full (no filters) log of the raw CAN Messages.

I want to use it in a READ-ONLY mode, where it will NOT try
to connect to other non-CAN pins on the OBD connector.

I also have 3 of the DIP version of their STN1110 chips, but I have
not yet had time to do anything with these DIP chips.

Did you have success logging ALL the CAN Messages?

More later, Merci

How can we use the OBDLink SX in Read Only mode?
 
MLucas said:
Gotten a little lost here. Are we talking about a Prius or a Peugot i-On? I've looked over the excel workbook and I see a page for each PID from 101 to 75B. What vehicle did this come from and what conditions was it taken? .....
hello
Sorry if I was not clear,
the log above is from a peugeot iOn, it should be ( hopefully ) the same for an eMiev.
this log is just a passive monitoring of CAN frames...

(I started monitoring CAN on prius gen2 & gen3, but do not worry, I will not write about hybrid here).

the biggest difficulty, in the beginning, is to find/guess what is behind each byte for each PID;
this is why I analyse in excel, looking for changing bytes...
this is also why Gary developed a program for analysing CANlogs...
 
priusfan said:
the log above is from a peugeot iOn, it should be ( hopefully ) the same for an eMiev.
this log is just a passive monitoring of CAN frames...

Okay, got that part. Now is this every PID that your logging has isolated? What was occuring during this time frame, i.e. driving, charging, parked, etc.? Or is that not relevant?

I'm also looking through the 'recipe file' that Gary created for the Can-Do program. I'm going to assume at my expense that this is the list of variables discovered in the log files that Gary programmed against. Unsure of how the 'recipe' relates to the log files.

I guess I just need some pointers so I can start looking for patterns.
 
Great! I see you have charts on several of the worksheets but no descriptions of what they mean.

For example, PID 412. Does P1 directly correlate to your speed? It seems fairly consistent with a short five minute drive.

Can you identify any of the others that you have figured out? Never mind, I found your base worksheet that explains everything. Sorry about that.
 
here are some details (thx gary for translation) :
MsgID 0x373 (frequency 100/sec):
1. The battery current (A) bytes 2 & 3 ( num 0-7),
formula (B [2] * 256 + B [3] - 128 * 256) / 100
Extreme values observed: -164.18 + 76.54
2. Voltage: bytes 4 & 5
formula (B [4] * 256 + B [5]) / 10 V
Excursion between 343.2 & 389.7 V
3. From these two facts, it is easy to integrate kilowatts inbound / outbound

MsgID 0x412 (frequency 10/sec)
1. byte 1 Speed kM / H
2. Byte 3 & 4 Odometer kM (certainly also in byte 2)

MsgID 346 frequency 50:
1. In byte 7 is the kM remaining autonomy

MsgID 0x6E1, 6E2, 6E3, 6E4 frequency 25:
1. Byte [0] is an index ranging from 1 to 12.
2. Found in pairs of bytes 4 & 5 and 6 & 7
something that resembles the voltage 88 battery cells.
3. found 64 temperature sensors in bytes 1 2 3
(value obtained by removing ° C 50 °)
 
A bit of background for beginners:

1. Most modern cars have a number of micro-computers (uP) in them
that control many (or even most) of the car's functions.

For example, in the olden days, many wires went from the front
to the back of the car, to light tail, brake, and backup lights, operate
the turn signal lights, and perhaps unlock the trunk, and light a
small light in there.

Now, there is a uP in the rear, that gets commands from a uP in the
front of the car. Just power, ground, and 2 wires for the communication
go to the rear uP, and that saves weight and many wires, and usually
makes for having smaller connectors. Yes, the fuses complicate things a bit.

2. In most modern cars, this commuication is done on one CAN bus,
which allows many of the car's uPs to all talk to each other. Most cars
emit pollution, so they are subject to more regulations than pure EVs.

In the case of the iMiEV, iOn, and C-?? the maker has apparently decided
to use only one CAN bus, and it is available at the On Board Diagnostics
(OBD) connector, usualy located near the driver's knees.

The LEAF is an exception, where two additional CAN buses are used,
and all three CAN buses come to the OBD connector. There is even another
CAN bus in the LEAF, used for Quick-Charging, that does not come to
the OBD conector at all. With some effort, we have logged all 4 of those
CAN buses simultaneously, and I wrote my CAN-Do program to help
me and others explore the data collected in the resulting logs.
A 6-chou charging of just the EV-CAN bus is about 6 million Messages.

For our discussion here, we will concentrate on the one CAN bus that
is often called the CAR-CAN bus. The iMiEV and other similar EVs seem
to have most of their internal communication done on this one CAN bus,
and we can, with some careful exploration and detective work, discover
what some of the data in the CAN Messages means.

We might discover a higher-resolution "fuel" number, that could be of help
in making decisions of when to drive, and when to seek re-fueling (charging).

3. The CAN Messages are short, quick messages that might be sent by
any one of the uP connected to the bus, and intended to be received by
another uP, or even (more rarely) by several uPs.

We can carefully "listen" to the CAN bus, try to record all of the Messages
that we "hear", but neither Write nor Receive the Messages, so that we
do not upset or change the operation of the vehicle.

At this point, we do not know enough to safely inject (Write) Messages.

4. A CAN Message has primarily a Message Identification, often called
MsgID or PID, and up to 8 Data Bytes. The MsgID is either 11 (or 29) bits,
and there are anywhere from 0 to 8 Data bytes, sometimes called Byte 0
through Byte 7, but I prefer to use D1 through D8 to be more human friendly.
It appears that the iMiEV uses the 11-bit MsgID, like the LEAF does.

Much more detail on CAN bus details, for those who want it:
http://en.wikipedia.org/wiki/CAN_bus

5. The effort to discover the meaning of the Data Bytes is considerable.
Much, much easier if the Manufacturer would tell us, but in general they do not.

To make thigs a lot easier for normal ICE vehicles, many standards have developed.
But the EV, not subject to smog tests or pollution regulations, is fairly free
to make their own conventions, much like the early days of computerized cars,
when almost nothing was standard, without even the OBD connector being required.

6. In EVs like the iMiEV, I am hoping that some of the conventions used (like RPM)
are the same as they are in ICE cars, just to avoid re-invention of all new firmware.
However, we might not be that lucky.

More Later. :D
 
PriusFan,
The RealTerm program added the time stamps and wrote the text Log, right?

Out of the OBDLink device:
1. What is the data stream, Hex or Binary (I suspect Hex)?

2. Is the Hex data 3 hex digits for the PID, 2xN Hex digits for N data bytes,
and then an end-of-line character?

Are there other useful options when trying to capture long Logs
of all of the CAN Messages?

3. What is the end-of-line in Hex 0x10 or ??

I think I will add the OBDLink Format to CAN-Do's choices of Logging
Data Streams. Is anybody interested in that?

Then, we could capture Logs with CAN-Do, and use a Recipe file
for iMiEV instead of the LEAF, and make a real-time "Dashboard"
page for the iMiEV.

Comments, Suggestions, ...?
Thanks, Gary
 
bonjour,
congratulation @gary for your clear report.
answers to your questions on obdlink:
1) hex
2) exactly
3) using the initial sequence detailed before, the EoL is 0D

realterm is a terminal program,
for a dialog with an obdlink , you must know the COM port and the Speed.
when you install the driver for the obdlink, windows will give the ComPort.
Realterm should find the existing ComPort, but you can check before.
the initial speed is 115200bps, to avoid bufferoverflow, it is necessary to adapt the interface to a much faster speed ( I explained a few post before how to do).

within realterm, there is the possibility to capture the flow in logfile, and an option to include a timestamp.

test of logging with a camry should work perfectly : toy uses can @500k & 11bits

I will try to find back a program I wrote, in vb6, a few years ago, for logging on hybrids, it would be much easier than using realterm...
 
I think I will try to add logging from an OBDLink type device into CAN-Do,
where one can specify and send an initialization AT type sequence, and
see the responces.

First, I will need to try the OBDLink (with a virtual Comm Port via a USB
connection) with a dumb terminal program.

Since CAN-Do can simultaneously log selected GPS data from a
compatible USB-attached, inexpensive GPS receiver, that would
make a nice combination to gather EV data.

Any thoughts or suggestions?
 
garygid said:
Are you going to try it with the included software?

What will you try to do with it?


I did try is as-is, and was a no go. So i tried it on my other car which has ICE issues (its a Ford).

Are there some settings I need to make so it doesn't make the warning lights come on with the i-MiEV?
 
Are there some settings I need to make so it doesn't make the warning lights come on with the i-MiEV?

YES & NO : never use a software made for gas cars with your iMiev.
the diag plug on Electric cars does not speak the same language as on standard cars.

I sent to gary the src of a small program I tested on mine for this interface...
 
Back
Top