electronpusher
Posts: 11
Joined: Sun Jun 25, 2017 3:11 am

Re: Decyphering iMiEV and iON CAR-CAN message data

Sat May 05, 2018 6:23 am

Very interesting discussion.

Has anyone managed to retrieve diagnostic codes?

Bobet21
Posts: 1
Joined: Sat Jun 16, 2018 7:41 am

Re: Decyphering iMiEV and iON CAR-CAN message data

Wed Jul 04, 2018 8:20 am

This is probably the most complete doc that exists, you can check out all existing DTC, but unfortunately you do not know how to get them

http://mmc-manuals.ru/manuals/i-miev/on ... dex_M1.htm

praxidice
Posts: 8
Joined: Thu Jun 14, 2018 7:02 pm

Re: Decyphering iMiEV and iON CAR-CAN message data

Fri Jul 06, 2018 2:11 am

Presumably Mitsubishi isn't prepared to provide the necessary information, even though the Minicab is the only comparable vehicle still in production ?

Can anyone advise how much information is provided to Mitsubishi dealers and authorized service agents ?

If perchance a service agent was prepared to spill the beans, would he have sufficient knowledge to advance the state of play to the extent that the missing pieces aren't so inaccessible ?

From another perspective. if it is completely unrealistic to get a handle on controlling how the existing software works, how crazy is the concept of generating a totally new operating system ? When its all said and done, its difficult to imagine a more basic EV than an iMiEV, consequently developing a replacement operating system must be a lot more do-able than it would be in the case of a Tesla. Is this idea pie in the sky ?

coulomb
Posts: 51
Joined: Sun Jun 10, 2018 8:32 pm

Re: Decyphering iMiEV and iON CAR-CAN message data

Fri Jul 06, 2018 6:08 am

praxidice wrote: From another perspective. if it is completely unrealistic to get a handle on controlling how the existing software works, how crazy is the concept of generating a totally new operating system ? When its all said and done, its difficult to imagine a more basic EV than an iMiEV, consequently developing a replacement operating system must be a lot more do-able than it would be in the case of a Tesla. Is this idea pie in the sky ?

It's a different set of reverse engineering problems, plus a lot of forward engineering.

You still have to reverse engineer what general purpose inputs and outputs connect to what functionality, for example. Some microcontrollers have of the order of 80 such I/O lines. Then you need the details of any extra-controller hardware, like the gain of every op-amp.

If we could get hold of the firmware, even in binary form, then patching to overcome things like VIN locking becomes possible, though hard. I can help with that. But getting hold of the firmware is often difficult. In two projects that I've been involved with, Elcon/TC chargers and PIP/Axpert inverter-chargers, I got lucky. Ways were found to read the firmware; in the case of Elcon chargers, this was done by two users on this very forum. But I don't think that they can do the same trick with the microcontrollers used in the iMievs (but I'd be very pleased to be proved wrong).

I'm not saying it's impossible or even too hard; it depends on the skill sets of the people available to get the work done.

praxidice
Posts: 8
Joined: Thu Jun 14, 2018 7:02 pm

Re: Decyphering iMiEV and iON CAR-CAN message data

Fri Jul 06, 2018 1:34 pm

coulomb wrote:
praxidice wrote:
If we could get hold of the firmware, even in binary form, then patching to overcome things like VIN locking becomes possible, though hard. I can help with that. .


In your opinion, do you feel that getting hold of the firmware is the most straightforward way to proceed ? I agree that its most likely to be get-able in binary form ... however .....

I have a few ideas bumping around and will pursue those,

coulomb
Posts: 51
Joined: Sun Jun 10, 2018 8:32 pm

Re: Decyphering iMiEV and iON CAR-CAN message data

Fri Jul 06, 2018 6:17 pm

praxidice wrote: In your opinion, do you feel that getting hold of the firmware is the most straightforward way to proceed ?

I'm very new at iMievs; I don't have one myself. My only connection is a friend of a friend is trying to transplant a complete iMiev drive train into a Citroën, and there are problems. I've always enjoyed reverse engineering binary software (disassembling, even decompiling at times). So I'm a bit naive and also biased. In my biased opinion, yes, disassembling the firmware is a good method. If you can get a binary image to me, I'll likely be able to extract useful information from it, and may even be able to prepare patched images to do various things. But it might take a long time, and it may prove hopeless in the end.

CZeroOwner
Posts: 5
Joined: Mon Jan 15, 2018 1:47 am
Location: Denmark

Re: Decyphering iMiEV and iON CAR-CAN message data

Mon Aug 13, 2018 6:20 am

I have noticed that my CZero seems to use more amps while discharging than it stores in the battery while charging. This must be wrong because it would eventually lead to negative values for the Ah remaining in the battery. At the same time, a possible error in the amps measurement is mentioned on the forum. I found what I believe is the amps error using a continuous data set for a trip involving driving, slow charging and fast charging. This trip is shown in the figure below.

Image
Figure: A trip of about 200 km with both slow and fast charging.

The data shown in the figure was collected with the OBDZero app. The app computed the battery amps at 4 to 5 second intervals using the formula provided on the forum by garygid:

PID 373 D3,D4 as (((D3 * 256) + D4) - 32768) * 0.01 = pack amps In
Note that I chose amps in rather than amps out with a corresponding change from -0.01 to 0.01

In Excel the data was sorted by date and time then the precise time step in hours between each measure¬ment set was computed. The amps were multiplied by the time step to obtain the Ah for each time step using this formula:

Ah = (Amps0 + Amps1)*h/2

Where Amp0 is the amps in one measurement and Amp1 is the amps in the next measurement, the time step h later. Then the accumulated Ah were computed as a running sum starting with 100% = 37.3 Ah. 37.3 Ah was the battery capacity shown by the EvBatMon on that day. The result is shown as the blue line in the figure. The downward trend in Ah compared to the SoC is easy to see.
By simply adding 0.66 amps to each measurement I was able to move the blue line so the two lines were on top of each other.

Image
Figure: The accumulated Ah after adding 0.66 amps to each amps measurement

As the amps are negative while discharging and positive while charging adding 0.66 effectively reduces the amps used while discharging and increases the amps stored. This balances the budget. Therefore adding 0.66 amps calibrates the amps measurement at least on my CZero.

Return to “Instruments - Radio/USB/Nav - CAN - Climate Controls - Remote”