Does anyone have the full details of the MUT protocol?
I am interested in open source scanning / data logging / flashing of Mitsubishi ECUs. However, I have only been able to find limited information online regarding the specifics of the MUT protocol. I was wondering whether someone has a link to a full specification? Alternatively if someone has access to evoscan / a dealer MUT tool they can sniff the K-line to reverse-engineer the protocol.
I will summarise what I know so far.
Command | Data | Formula
------------------------------------
0x06 | Timing | A - 20
0x14 | Battery | A * 0.0733
0x17 | TPS (?) | A * (100/255)
0x1A | MAF sensor | A * 6.29
0x1C | ECU load (?) | A * 0.625
0x26 | Knock count | A
0x27 | Octane number | A
0x21 | RPM | A * 31.25
0x29 | PW (?) | A * 0.256
0x2F | Vehicle speed | A*2
0x32 | AFR Map | A
References:
https://evoecu.logic.net/wiki/MUT_Protocol
https://github.com/harshadura/libmut
I will summarise what I know so far.
- Communication happens via ISO-9141-2 (similar to UART) on the K-line; pin 7 if the car uses a regular OBD2 connector. Data high => 12V, data low => 0V.
- Usually done by using a resistor to pull the line high and a transistor to stretch the line low; this seems to be how OpenPort does it.
- Usually done by using a resistor to pull the line high and a transistor to stretch the line low; this seems to be how OpenPort does it.
- Pin 1 should be connected to ground to enable communication (Note: may not be true on newer vehicles)
- Communication is initiated by sending the byte 0x1 at 5 baud (8N1; i.e. 1 start bit, 8 data bits, no parity bit, 1 stop bit, data sent LSB first)
- Note: standard (i.e. non-Mitsubishi) K-line init is similar, but sends 0x33 instead of 0x1
- Note: standard (i.e. non-Mitsubishi) K-line init is similar, but sends 0x33 instead of 0x1
- Communication then proceeds at 15625 baud (but still 8N1). The ECU will send the bytes C0 55 EF 85.
- From there the ECU will respond to MUT commands. The table below is a partial list of MUT commands.
Command | Data | Formula
------------------------------------
0x06 | Timing | A - 20
0x14 | Battery | A * 0.0733
0x17 | TPS (?) | A * (100/255)
0x1A | MAF sensor | A * 6.29
0x1C | ECU load (?) | A * 0.625
0x26 | Knock count | A
0x27 | Octane number | A
0x21 | RPM | A * 31.25
0x29 | PW (?) | A * 0.256
0x2F | Vehicle speed | A*2
0x32 | AFR Map | A
References:
https://evoecu.logic.net/wiki/MUT_Protocol
https://github.com/harshadura/libmut
The source code did help; I made table in the original post based on libmut. As you can see only a subset of the MUT commands are defined there, compared to the data available to something like evoscan.
Fuel trims, coolant temp, O2 sensor data, etc. are missing.
Also theoretically ECU flashing is done over MUT too? But reverse engineering that is a more ambitious task.
Fuel trims, coolant temp, O2 sensor data, etc. are missing.
Also theoretically ECU flashing is done over MUT too? But reverse engineering that is a more ambitious task.
A lot of data got scrubbed from evoecu.logic.net but you can use the way back machine to view it. 2016 seems to be a good year.
https://web.archive.org/web/20161029...CU_Development
https://web.archive.org/web/20161029...CU_Development
Hey there guys, I know this thread is dead since a few years but I still wanna ask: are you @P0301 or @Biggiesacks still involved in anything regarding the MUT protocol? I have an Colt V from 1996 which I think should speak MUT-II but got no luck in the past 2 months. I haven't even got the handshake to work... If you are still active, perhaps we can share some knowledge
I have verified and got live data readings using an tester from Autel from my local workshop, so I it works in theory...
I have verified and got live data readings using an tester from Autel from my local workshop, so I it works in theory...
Thread
Thread Starter
Forum
Replies
Last Post
evo4mad
ECU Flash
70
Oct 25, 2007 04:14 AM







