priusfan
Posts: 194
Joined: Mon Oct 08, 2012 7:39 am
Location: France

Re: Decyphering iMiEV and iON CAR-CAN message data

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
Posts: 12
Joined: Tue Sep 19, 2017 10:59 pm

Re: Decyphering iMiEV and iON CAR-CAN message data

many thanks for the code!
i try it with the raspberry as soon as posible and tell the results.
Thanks again.
Serhge
Posts: 95
Joined: Mon Jul 16, 2018 7:35 pm

Re: Decyphering iMiEV and iON CAR-CAN message data

how to solve a problem ?

Image

https://ibb.co/N2Kr4R5
My theme : hobdrayv - and i-MIEV ion zero, electronic control units, resetting errors

http://myimiev.com/forum/viewtopic.php?f=9&t=4101
kiev
Posts: 1776
Joined: Sun May 03, 2015 7:15 am
Location: The Heart o' Dixie
Contact: Website

Re: Decyphering iMiEV and iON CAR-CAN message data

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).
kiev = kenny's innovative electric vehicle
Serhge
Posts: 95
Joined: Mon Jul 16, 2018 7:35 pm

Re: Decyphering iMiEV and iON CAR-CAN message data

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
My theme : hobdrayv - and i-MIEV ion zero, electronic control units, resetting errors

http://myimiev.com/forum/viewtopic.php?f=9&t=4101
CZeroOwner
Gold Member
Posts: 58
Joined: Mon Jan 15, 2018 1:47 am
Location: Denmark

Re: Decyphering iMiEV and iON CAR-CAN message data

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
Posts: 3
Joined: Thu Jun 11, 2015 6:19 pm

Re: Decyphering iMiEV and iON CAR-CAN message data

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
Posts: 66
Joined: Wed Jul 08, 2015 7:23 pm
Location: Gosford, Australia
Contact: Website

Re: Decyphering iMiEV and iON CAR-CAN message data

israndy wrote: 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.

EvBatMon App for iMiEV/C-Zéro/iOn
Android https://play.google.com/store/apps/details?id=com.EvPositive.EvBatMon_iMiEV
iOS (iPhone,iPad,iPod) https://itunes.apple.com/us/app/evbatmon-for-mitsubishi-imiev/id1143905475
www.EvPositive.com
franciscoshi
Posts: 1
Joined: Wed Jun 30, 2021 9:30 am

Re: Decyphering iMiEV and iON CAR-CAN message data

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
Gold Member
Posts: 58
Joined: Mon Jan 15, 2018 1:47 am
Location: Denmark

Re: Decyphering iMiEV and iON CAR-CAN message data

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.

Image

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:
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
viewtopic.php?f=25&t=763&p=4898&hilit=cells#p4898

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