KommyKT
Posts: 7
Joined: Tue Dec 25, 2018 1:50 am

Re: Decyphering iMiEV and iON CAR-CAN message data

CZeroOwner wrote: Mon May 16, 2022 10:44 pm 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?
This thread show how to get data: http://www.myoutlanderphev.com/forum/vi ... =10&t=1796
CZeroOwner
Gold Member
Posts: 58
Joined: Mon Jan 15, 2018 1:47 am
Location: Denmark

Re: Decyphering iMiEV and iON CAR-CAN message data

KommyKT wrote: Sun May 22, 2022 2:49 am This thread show how to get data: http://www.myoutlanderphev.com/forum/vi ... =10&t=1796
Hi KommyKT Thanks very much for this information. Cheers David
kiev
Posts: 1789
Joined: Sun May 03, 2015 7:15 am
Location: The Heart o' Dixie
Contact: Website

Re: Decyphering iMiEV and iON CAR-CAN message data

This is like peeling an onion. May be old news for some folks, but it's new to me.

It appears that "anko" from the mitsubishi Outlander PHEV forum has figured out a method to send a query request to the BMU to access the BMU Data Items List which is mentioned in the FSM when using the MUT tool.

This seems to be a different approach than that of Canion and other apps which read CAN PIDs over the OBDII port.

anko shared his findings with zzcoopej from Australia, who developed the EvBatMon app which is available for the phev and miev on his website at evpositive (.com).

i could see the value of being able to send a query request to some of the various ecus for troubleshooting, to read DTCs and stored values, etc.

more layers to peel...
kiev = kenny's innovative electric vehicle
dopey
Posts: 11
Joined: Mon Jul 11, 2022 3:23 am

Re: Decyphering iMiEV and iON CAR-CAN message data

A new i-miev owner, technically get the old car this Wednesday.

Been reading up on what I had assumed be a fairly straight forward project :) Some sort of remote heater activation via can bus. I have a volvo s60r and just assumed a similar level of hackery as been done on the s60 platform :)

If my reading thus far is correct..

No one has gotten this to work.

People have cracked the suspected PID and format for heat/cool controls.

It is not known how to write to the canbus, so it is simply untested to to send such PID+data combos onto the canbus.

Someone referenced a few times a 'risk of break assistance' being affected if you try to write to the canbus? Did they mean brake assist (ABS)? I couldn't find any thread where this fear was first explained.


I've ordered an OVMS that with any luck will arrive tomorrow. If nothing else having the remote visibility of charge state/location is quite nice.

Is it true no one has documented how to write to the canbus?
Can MUT III actuate the heater? It must be able to write to the canbus then? Any ability to decode that?
If I were to buy the remote-ecu + antenna + remote control, is it known if the 20111 model has the connections needed? Any one emulate the radio signal from within the car instead - letting you do it over internet instead of within range of the remote ?

Appreciate any tips, plan to start my own tinkering with the car.
muth
Posts: 4
Joined: Mon Sep 07, 2020 6:26 am

Re: Decyphering iMiEV and iON CAR-CAN message data

Hello,
I've made a small additional gauge for my c-zero. It connects to the OBDII plug, the CAN-bus is processed by a MCP2515 and an arduino.
It shows the cells voltage and the battery power in/out.

Image

Some details here (I should complete it soon):
https://pierremuth.wordpress.com/2022/0 ... ard-gauge/
dopey
Posts: 11
Joined: Mon Jul 11, 2022 3:23 am

Re: Decyphering iMiEV and iON CAR-CAN message data

very cool @muth . If you have any of your pids documented i'd love to see them; I believe the OVMS project uses it and this repo is the best 'single' source I've found.
https://github.com/KommyKT/i-miev-obd2

I am still trying to do lossless captures on my i-miev. When using the ovms, I get 50% discards capturing the entire canbus. I've ordered a CL2000 hoping this will give me the ability to do full captures lossless. While also trying to improve the ovms performance.

I am new to can and 'this level' of development, triage. If I am following though, we know the PID which the HVAC announces it's status (on/off, heat, location, etc). Sending 0x3A4 will not turn on the climate control, as it's the unit just announcing it status. Right?

But the PID which turns on the HVAC is unknown, and unfortunately no one with a factory remote has ever done a capture :( -- If anyone has the remote control and can do a capture, i'd even be happy to pay for a device to do the capture.

An Idea I've had - Has anyone captured during a chademo session? When doing chademo the car turns on the A/C and controls the vents. Is there any chance that PID is possible to be 'the one' that we'd want to spoof -- albeit different bits to control the vents towards the cabin? Perhaps it is the right pid, but different data bits? -- Chademo turns on A/C temp, but remote sets heat? Would this be logical? Has anyone already explored this theory?
muth
Posts: 4
Joined: Mon Sep 07, 2020 6:26 am

Re: Decyphering iMiEV and iON CAR-CAN message data

Thanks a lot Dopey, KommyKT repo is really great !
I used only known PID. The four battery cell voltage: 6E1 6E2 6E3 6E4. And the 373 for the total voltage and amp. Plus the min and max of the cells voltages, also in 373, I think it is not mentioned on KommyKT repo but I've found it in the OBDZero source code, D0 and D1 :

Code: Select all

case "373":
    b_BatVmax.dbl = (aPID.intPID[0] + 210) / 100.0;
    b_BatVmin.dbl = (aPID.intPID[1] + 210) / 100.0;
    b_Amps.dbl = (aPID.intPID[2] * 256 + aPID.intPID[3] - 32768) / 100.0;
    c_Amps.dbl = -b_Amps.dbl;
    c_AmpsCal.dbl = -(b_Amps.dbl + 0.66);
    if (aPID.intPID[4] > 9)
        b_Volts.dbl = (aPID.intPID[4] * 256 + aPID.intPID[5]) / 10.0;
    b_Watts.dbl = c_AmpsCal.dbl * b_Volts.dbl;
    break;
KommyKT
Posts: 7
Joined: Tue Dec 25, 2018 1:50 am

Re: Decyphering iMiEV and iON CAR-CAN message data

muth wrote: Fri Jul 29, 2022 8:24 am Thanks a lot Dopey, KommyKT repo is really great !
I used only known PID. The four battery cell voltage: 6E1 6E2 6E3 6E4. And the 373 for the total voltage and amp. Plus the min and max of the cells voltages, also in 373, I think it is not mentioned on KommyKT repo but I've found it in the OBDZero source code, D0 and D1 :
Nice work, I can not use min and max voltage in ovms code because ovms calculate this from cell data automatically.
dopey
Posts: 11
Joined: Mon Jul 11, 2022 3:23 am

Re: Decyphering iMiEV and iON CAR-CAN message data

I've yet to find anything useful, but sharing some collection i've done thus far. My goal is to turn the heater on remotely in winter -- but at this point i'd be happy to trigger any sort of command on the car :(

I've been recording from the OBD using usbcan, and yesterday tapped into the AC ECU under the back seat -- pins 3 +4 using canusb. Looking at the docs it appears we have a CAN1, CAN2 with the ETACS ecu acting as gateway towards the diagnostic port. I had hoped by listening on the canH/L on the A/C ECU that i'd find commands to control the A/C unit.

Additionally had the idea to sniff both OBD2 and the ac-ecu when starting chademo since it triggers the A/C + vents during those sessions. Even if that is the 'wrong' command, being able to control the A/C at all be a huge win.

Sadly, I believe i'm seeing less PIDs sniff the AC ECU than from OBD2. I was expecting the opposite.

Here is a high level summary from the following. This is a very simple script that counts the pids in the candump file.

  • percentage of known vs unknown
  • 'Known Pids(count) - I consider a pid 'known' from the README.md having a description/formula for the pid. I started to incorporate the formula in my python script so they are listed as 'known'.
  • 'Uknown' Pids(count) are one that I have not seen defined what they do/for/mean or a formula.
  • 'Known but not configured(count):' Are in the readme but I havent' implemented the formula.
[*] 'Failed Pids(count):' This is just incase any try/except code explodes to not 'miss' a PID in the file.
[*] The pid then the # of occurence in the file

[/list]

This is my first time digging into canbus, my thinking was to try and divide and find uncommon/unique pids either from actions (clicking on/off A/C), or from location i'm sniffing. So take away the known 'noise', and try to find new things.


From OBD2 port - Driving from home *to* chademo station. Starting with key out of ignition.

Code: Select all

[dopey@dopey-desktop triage-imiev]$ python dopeyParse.py rawLogs/obd2/310722-home-mcdonalds-d-b-d-38.log 
Known 43.01104006596152, Unknown 56.98895993403848, Failed 0.0
Total Pids(55):
Known Pids(15):
101 12204
149 60609
200 60608
208 60608
210 60999
215 60608
231 60607
236 121210
285 121998
298 12200
346 60998
373 122097
374 12210
384 12113
412 12264
Unknown Pids(40):
100 1
110 1
111 1
119 60607
156 60609
212 60999
288 121991
2F2 12120
300 60607
308 60998
325 61506
375 12210
385 12113
408 12264
564 24399
565 24399
5A1 24420
695 12200
6D0 24400
6D1 24400
6D2 24400
6D3 24399
6D4 24400
6D5 24400
6D6 24400
6DA 24399
6FA 12200
75A 12199
75B 12199
Known but not configured(11):
286 12200
696 12200
6E3 30524
697 12199
6E4 30524
29A 12200
6E2 30524
6E1 30524
424 30754
418 61000
3A4 12113
Failed Pids(0):
[dopey@dopey-desktop triage-imiev]$ 
*note* I accidentally took a wrong turn so the length of this capture was a good deal longer, but the car was never stopped, put in reverse, etc just driven forward longer.

From ACECU terminal 3+4: Driving from Chademo station back home.

Code: Select all

[dopey@dopey-desktop triage-imiev]$ python dopeyParse.py rawLogs/acecu/3102722-ac-ecu-kungmcd-home-d-b-keyoff-removed.log 
Known 35.89669122775868, Unknown 64.10330877224132, Failed 0.0
Total Pids(47):
Known Pids(12):
101 7453
200 3309
208 1542
210 36962
215 583
231 28318
285 72043
298 5994
346 40032
373 73628
374 5986
412 7199
Unknown Pids(35):
100 1
119 169
212 34647
288 65481
2F2 7301
300 1047
308 36370
325 714
375 7442
408 7650
564 12057
565 13064
5A1 14646
695 8035
6D0 17067
6D1 17012
6D2 16603
6D3 16922
6D4 15784
6D5 15146
6D6 15542
6DA 15694
6FA 7893
75A 6279
75B 7275
Known but not configured(10):
418 34023
424 266
697 7996
6E1 19877
29A 6075
286 8532
6E3 20724
6E4 20230
6E2 19493
696 8404
Failed Pids(0):
[dopey@dopey-desktop triage-imiev]$ 

When I first arrived I started a new candump log, started chademo, waiting a bit, then cancelled the session. This from OBD2 connector:

Code: Select all

[dopey@dopey-desktop triage-imiev]$ python dopeyParse.py rawLogs/obd2/310722-chademo-start-end-obd2.log 
Known 29.951199674664498, Unknown 70.0488003253355, Failed 0.0
Total Pids(42):
Known Pids(9):
101 451
210 2251
285 4505
298 451
346 2251
373 4562
374 457
384 424
412 851
Unknown Pids(33):
212 2251
288 4503
308 2251
325 4260
375 457
385 425
408 851
564 901
565 901
5A1 912
695 451
6D0 901
6D1 901
6D2 901
6D3 900
6D4 901
6D5 901
6D6 901
6DA 900
6FA 451
75A 451
75B 451
Known but not configured(11):
696 451
418 2251
6E4 1141
6E1 1141
29A 451
6E2 1141
3A4 425
286 451
424 2130
697 450
6E3 1141
Failed Pids(0):
[dopey@dopey-desktop triage-imiev]$ 
I then connected to the A/C ECU terminal 3+4, started a chademo, waiting, then cancelled. I was better to not leave a door 'open' during this, hence less noise on the 424/other pids I think.

Code: Select all

[dopey@dopey-desktop triage-imiev]$ python dopeyParse.py rawLogs/acecu/310722-ac-ecu-chademo-start-end-door-open-close.log 
Known 31.327193932827736, Unknown 68.67280606717226, Failed 0.0
Total Pids(42):
Known Pids(9):
101 1522
210 7564
285 15222
298 1510
346 7583
373 15209
374 1527
384 328
412 1582
Unknown Pids(33):
212 7567
288 15132
308 7556
325 8227
375 1528
385 108
408 1575
564 3031
565 2969
5A1 2903
695 1522
6D0 2935
6D1 3042
6D2 3042
6D3 3039
6D4 3041
6D5 3042
6D6 3042
6DA 3036
6FA 1522
75A 1515
75B 1502
Known but not configured(11):
6E1 3820
697 1522
286 1458
3A4 482
29A 1495
6E2 3819
418 7566
424 4018
6E3 3751
696 1522
6E4 3764
Failed Pids(0):
[dopey@dopey-desktop triage-imiev]$ 

I'm just starting to go through this(Just got home with the logs). I was expecting to find new interesting PIDs from sniffing the A/C ECU as I *thought* I was on CAN2 and seeing traffic obscured from the OBD2 connector. At a glance, that does not seem to be the case.



A really really dumb question -- Any theories why we seemingly cannot issue a canbus command/reply anything we see on the bus? When locking doors I see 424, 412, and 408. Replaying these never cause the locks to change. Even tho seemingly D3 changing from 00 to 40 is the switch, with the other bits seeming to change over time. I'm new to this, but thought the general approach for canbus was finding the 'right' pid and replaying it. Whether Windows, locks, etc. Is there some sort of calculation happening/expected on the other Bytes? Is it a timing/order of multiple pids to trigger an event? Is it 424 may be the 'status' of the lock but another unknown PID is the 'command' to unlock the door?

The most i've been able to do is make the dashboard look like a christmas tree playing with the 424 pid -- by sending the same data on 424 twice in quick succession i can get both turn signals to 'blink' like they do when unlocking the car, but never anything actually meaningful :(

By sending I mean doing something like:

Code: Select all

cansend slcan0 424#C0004000A70501FF
Or using replay in savvycan.

Is it true no one has managed to 'send' a command via canbus? The only way has been a canbus bridge -- which feels dangerous as if the bridge dies the traffic dies and the car will go out of Ready? Any theories why this car is so resistant?
kiev
Posts: 1789
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 about the checksum/CRC? How is that created and sent along with your packet?

It seems like most of the PID lists and tables leave out the CRC, but they are necessary for every message.

Image
kiev = kenny's innovative electric vehicle

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