Decyphering iMiEV and iON CAR-CAN message data

[priusfan]

As you are using an OBDLINK LX, you should send the following sequence:
"ATZ" & Chr(13) ' reset dongle
"ATSP6" & Chr(13) ' CAN 11 bits @ 500k
"ATE0" & Chr(13) ' Echo OFF
"ATH1" & Chr(13) ' Header ON
"ATL0" & Chr(13) ' no crlf
"STFAP 374, FFF" & Chr(13) ' put pass filter B_SoC
"STM" & Chr(13) ' read frames

You should receive only frames with id 374, they look like this:
374 B8 BC 00 00 43 3F 4E 00
the SoC is in the second data byte BC
BC converted to dec = 188
formula to apply:
SoC= (X- 10) / 2
SoC= 89% (188- 10) / 2

What you started to develop is not the right way to start with....

Xavier

 

[Ghost128k]

many thanks for the code!
i try it with the raspberry as soon as posible and tell the results.
Thanks again.

 

[Serhge]

how to solve a problem ?

https://ibb.co/N2Kr4R5

 

[kiev]

What was the length of your CAN data capture--i suspect you either need a longer time slice or need to hold the last value until it is updated.

The cell PIDs are not sent out in any order, nor at any regular frequency--some seem to show up more than others. i don't know if this is due to PID ranking (lower number PIDs have higher priority), or due to controller (no need to report a value that hasn't changed from the previous scan cycle).

 

[Serhge]

Such a mistake is not just me.
Perhaps there is an error in the work with the order of blocks and the number of cells.
it is not clear in what config and how to fix

 

[CZeroOwner]

You are right Serhge. This is an error in the presentation. The battery contains 22 blocks of 4 cells. The blocks are arranged in 12 modules, 10 with 2 blocks and 2 with one block each. The temperature sensors are between cells in each block. That means 66 temperature readings for 88 cells. I just released a new version of OBDZero version 3 which presents the voltages and temperatures in a way that corresponds to this arrangement of cells and sensors. This also brings OBDZero in line with other programs such as Canion. If anyone has been collecting cell data I can send a list that shows how to convert the old OBDZero cell numbers to the new system. All the voltage and temperature reading should be in the files they just need renaming. You can also send the data in e.g. a comma separated text and I will try and convert it.

kiev is also right. Not all cell PIDs are captured by OBDZero in each program cycle. It takes up to 20 cycles or about 2 minutes before all of the cells have been outdated.

 

[israndy]

I am the proud owner of a new CANServer, a product that plugs into the OBD and provides a WiFi connection to the car and a MicroSD to capture CAN data. Sadly it was designed for the Tesla, and comes with a .dbc for those cars.

I am able to capture data just fine, but I am looking for information on what the messages mean so I can build a display that will show what is going on in the car.

I see the apps for Android, but unfortunately I have an iPhone, and like I said, a WiFi interface not Bluetooth. But it seems that someone knows what all this data means and how to read it.

 

[zzcoopej]

I see the apps for Android, but unfortunately I have an iPhone, and like I said, a WiFi interface not Bluetooth. But it seems that someone knows what all this data means and how to read it.

What are you looking at achieving? We may be able to collaborate if you are trying to do something different to what's already out there.

 

[franciscoshi]

I am trying to add cruise control to an Imiev.
I have been trying to control the inverter but the EV-ECU gets upset.
What I have found so far is that the EV-ECU sends the torque command on ID 285 and the inverter sends back its torque setting on ID 288
So what I have done is I change the data but remember what the EV-ECU sent and then when I get the reply from the inverter I replace it with what the EV-ECU requested. This seems to work but only for a short time then the EV-ECU comes up with an error code saying the inverter has a problem.
So I am guessing that there must be something else that the EV-ECU is checking that has to match the torque command. Maybe the motor current?
Does any one have any ideas?

 

[CZeroOwner]

Here is a list of the PID conversions in the OBDZero app. Most of the useful conversions were found by others on this tread before I started looking.

Note 0
Each PID contains 1 to 8 bytes. The first byte is numbered 1 and the last byte is numbered 8. When on/off information is code it is coded in the bits of a byte, a bit equal to 1 means on, except brake on/off where 2 equals on. The bits are numbered in the table above by positional value in the byte i.e. 1, 2, 4, 8, 16, 32, 64, 128. The low nibble in a byte is the number represented by the 4 least significant bits and the high nibble is the number represented by the 4 most significant bits.

Note 1
I believe that acceleration, rotation, wheel speed, and steering wheel position are all part of the electronic stability system but this is just guess. and I’m not sure of the conversion factors.

Note 2
The current to the 12 volt battery charger is very much a guess and I’m not at all sure of it.

Note 3
I’m fairly sure that that these two conversions are motor amps and regeneration amps. In order to find the conversion factors I have compared these with battery amps in and out. However because of many other factors this comparison is difficult and the conversion factors are uncertain.

Note 4
Until recently I have used the displayed speed (PID 412) as the speed of the car. However I now use the speed based on PID 215 because it indicates car movement 1 to 2 seconds before the displayed speed, it has a digit after the decimal point, and it is always in km/h. I received data from a car in the UK where the PID 412 speed was in mph. Knowing for sure whether the numbers are in metric or English units is necessary for the calculations the app performs.

Note 5
There are two values for the State of Charge (SoC). Both are computed by the car as part of a system for estimating the present 100% capacity of the battery aka State of Health (SoH). As such neither is more correct than the other.

Note 6
The battery amps in, the current to the battery can be both positive and negative. The sign is in relation to the battery so charging is positive and discharging is negative. However most of the computations in OBDZero are from the perspective of the motor and auxiliary functions. So for battery amps out calibrated, discharge is positive and charging is negative. The motor current is always positive and regeneration current is always negative. The heater current and the air-conditioning current are both positive. However this convention doesn’t apply to the charging unit current to the battery and the Chademo current to the battery both of which are positive. A description of the calibration of battery amps out can be found at:
http://myimiev.com/forum/viewtopic.php?f=25&t=763&p=36989&hilit=amps#p36989

Note 7
I have compared this conversion with the measured temperature for my location and the agreement is good but not perfect. The car’s outside temperature is often below the measured temperature when first starting the car but increases to the measured temperature while driving.

Note 8
The gear position is a bit complicated. The information is contained in PID 285. If byte(7) equals 12 then the position is either Park or Neutral with no indication of which. If byte(7) equals 14 and byte(8) equals 16 then the position is Drive. If byte(7) equals 14 and byte(8) doesn’t equal 16 then the position is Reverse. There is probably another PID where the gear position is more explicit, but I haven’t found it yet. Another thing, the iMiev has two more gear positions than the CZero and the iOn. Both these positions are shown as Drive in OBDZero.

Note 9
The coding of the individual cell information is not shown above. See
http://myimiev.com/forum/viewtopic.php?f=25&t=763&p=4898&hilit=cells#p4898

 

[stoatwblr]

I am trying to add cruise control to an Imiev.

How far did you get with this Franciso?

I've been getting occasional error messages about cruise control lines being low (the steering wheel resistor lines) - which is odd because they're not connected. That makes me wonder if the code is in the EV-ECU (or elsewhere) and pins simply need connecting up

 

[SilasAT]

Hey Folks,

Just wanted to share a potential discovery, it seems that PID 418 contains the gear shifter position.
The first byte (B0) translated to ASCII is the gear shifter position. The rest (B1-B7) just seem like constants.
0x50: P
0x52: R
0x4E: N
0x44: D

 

[KommyKT]

Here is a list of the PID conversions in the OBDZero app. Most of the useful conversions were found by others on this tread before I started looking.

The odometer is not valid: check with this values: FE 00 01 7D F4 00 21 12
This car is a 97780km in odometer
The valid conversion is byte(3)*65536 + byte(4)*256 + byte(5)

I searching for outdoor temperature. In this spreadsheet the outdoor temperature is only valid if car is cold start, I think this is another unit temperature, and has a few degrees difference from real temperature.

Gear values:
byte(1):

• 80 : P

• 82 : R

• 78 : N

• 68 : D

• 131: B

• 50 : C

I collect my used values (OVMS) in this GitHub repo: https://github.com/KommyKT/i-miev-obd2

 

[jalovick]

Hi,

I've just joined the forum and have had my i-MiEV for a few months now, and am looking to see what I can upgrade, in particular the on board charger, perhaps to a 11 kW or 22 kW unit.

I'm also active on the Open Inverter forums, and in case it is useful, some members have worked to decode the CAN for the Mitsubishi Outlander PHEV onboard charger, which I believe is very similar to the i-MiEV unit.

Details here:
https://openinverter.org/wiki/Mitsubishi_Outlander_DCDC_OBC

Jamie

 

[KommyKT]

Hi,

I've just joined the forum and have had my i-MiEV for a few months now, and am looking to see what I can upgrade, in particular the on board charger, perhaps to a 11 kW or 22 kW unit.

I'm also active on the Open Inverter forums, and in case it is useful, some members have worked to decode the CAN for the Mitsubishi Outlander PHEV onboard charger, which I believe is very similar to the i-MiEV unit.

Details here:
https://openinverter.org/wiki/Mitsubishi_Outlander_DCDC_OBC

Jamie

Thanks this is a very useful values, for newer cars, my is a 2011 Peugeot iOn but this not add this values, but a 2015 Miev is have and data is valid.

 

[kiev]

Hi,

I've just joined the forum and have had my i-MiEV for a few months now, and am looking to see what I can upgrade, in particular the on board charger, perhaps to a 11 kW or 22 kW unit.

How would you provide for cooling of the charger and pack with the higher power charging?

 

[jalovick]

I've just joined the forum and have had my i-MiEV for a few months now, and am looking to see what I can upgrade, in particular the on board charger, perhaps to a 11 kW or 22 kW unit.

How would you provide for cooling of the charger and pack with the higher power charging?

I'd likely replace the stock pump with a higher flowing unit, maybe with a small radiator. I haven't looked into it that much yet, step one is working out what actually fits! The other challenge is finding something that is a combined charger and DC to DC converter. There are some Chinese options, but I'd prefer to repurpose an OEM unit and use a CAN bridge to translate, as necessary.

Jamie

 

[CZeroOwner]

The odometer is not valid: check with this values: FE 00 01 7D F4 00 21 12
This car is a 97780km in odometer
The valid conversion is byte(3)*65536 + byte(4)*256 + byte(5)

I searching for outdoor temperature. In this spreadsheet the outdoor temperature is only valid if car is cold start, I think this is another unit temperature, and has a few degrees difference from real temperature.

Hi KommyKT

Thanks for checking my conversions!

Note that the equation in my post is (byte(3)*256+byte(4))*256 + byte(5) which is mathematically the same as yours.

As mentioned in the notes I too am uncertain about this being the outside temperature. However it is the temperature that I have found so far that mostly closely agrees with the outside temperature. I use the temperature to compute the air density used in the air resistance model. As such it has a limited affect on the results. In other words it is close enough for what I need. If we can find a temperature that has better agreement with the true outside temperature I will change it in the app.

Cheers
David

 

[CZeroOwner]

In my post above on conversions I show the battery 100% capacity in Ah as PID 374 byte(7)/2. (PID 374 also contains the SoC.) This conversion gives a value for the capacity with a resolution of 0.5 Ah. However CaniOn and EVBatMon both report the battery Ah capacity with a resolution of 0.1 Ah. I guess that these apps use another PID with the capacity coded in two bytes. I haven't been able to find these bytes. Does anyone know where they are and how they can be converted to the capacity?

 

[kiev]

Howdy David,

i don't know how they get to 0.1 resolution, i would guess that if it were an important data item that it would have a lower PID value. drcat posted these findings which you likely are already aware:

374 (D1 -10)/2 = SoC
374 D7/2 = C [Capacity]
373: (((D3 * 256) + D4) - 32768) * -0.01 = Pack Amps Out (#)
373: ((D5 * 256) + D6) * 0.1 = Pack Volts (#)

He is looking for the voltage reading of the capacitor rise in the MCU in order to spoof the CAN buss to solve the P1A15 DTC error. That value is in the data items list of the MCU, but maybe there is a separate buss between MCU and EVECU? such that it doesn't show on the OBDII port..?

He posted a great video of his setup in the DIY battery upgrade thread and has a github with code and examples, etc, see github/dkotin/can_2515 folder

Kolyandex posted about the first 2 bytes of PID 374:
1st byte is "Control SOC",
second byte is "Display SOC"

i take that to mean the control value to the EVECU and the value sent to the dash fuel gauge display.