Mitsubishi vehicles, particularly older models, utilize a diagnostic communication protocol known as MUT-II. For those familiar with modern car diagnostics, the term OBD2 (On-Board Diagnostics II) is commonplace. Understanding how MUT-II relates, or rather differs, from OBD2 is crucial when working on these vehicles. This article delves into the specifics of the MUT-II protocol, shedding light on its technical aspects and its connection to the broader world of automotive diagnostics, including OBD2.
MUT-II Protocol: The Basics
MUT-II, or Mitsubishi Unified Test-II, is based on the ISO9141-2 standard, a communication protocol prevalent in many early OBD systems. However, MUT-II implements a specific variation. Unlike the full ISO9141-2, MUT-II primarily uses only the K-line for communication, omitting the L-line. The data transmission speed, or baud rate, is set at 15625. For hardware interfacing, a driver capable of handling RS232 logic levels is necessary, with the MAX232 chip being a popular and effective choice.
A key characteristic of MUT-II communication is its half-duplex nature over a single wire. This means that data transmission and reception occur on the same line, but not simultaneously. In practical terms, any data transmitted will also be received back by the transmitting device. This aspect needs to be managed within the software interface designed to communicate with a MUT-II system.
Initialization and System Addressing
To initiate communication with a MUT-II equipped vehicle, a 5-baud initialization sequence is required. This initialization is not merely about establishing a communication channel; it also serves to specify which vehicle system you intend to communicate with. At any given time, communication is limited to a single system. For instance, to switch from communicating with the Transmission Control Unit (TCU) to the Airbag system (SRS), the current communication session must time out, and a new 5-baud initialization sequence must be initiated with the address of the desired system.
Each system within the vehicle, such as the Engine Control Unit (ECU), TCU, ABS, SRS, and others, is assigned a unique address. These addresses are crucial for directing diagnostic commands to the correct module. Below is a list of common ECU addresses, derived from analyzing MUT-III tools, which provides insight into the system addressing scheme:
public enum ECUAddress {
ECU = 0x0,
TCU = 0x1,
IMMOBILISER = 0x89,
SS4II = 0x92,
TCL = 0x85,
ECS = 0x2,
ABS = 0x4,
STEERING = 0x83,
HBB = 0x91,
AYC = 0xB,
SRS = 0x8,
SWS = 0x8A,
TPMS = 0x19,
CAMERA = 0x1A
}Note that some addresses listed might correspond to systems not present in all vehicle models.
Maintaining Communication
Implementing the 5-baud initialization using standard UART on microcontrollers like Arduino can be challenging due to the slow baud rate. Bit-banging is often employed to achieve this accurately. Fast initialization methods are not supported in MUT-II. To maintain an active communication link, it is necessary to periodically send requests to the system. A common practice is to send a random request and disregard the response, effectively keeping the communication channel open.
The 5-baud initialization sequence itself consists of: a start bit held for approximately 200 milliseconds, followed by 8 bits representing the system address, and finally a stop bit.
In standard MUT-II communication, grounding pin 1 of the OBD plug is required before sending the 5-bit baud initialization sequence. This action typically triggers error codes to be flashed by systems not being actively communicated with. However, some modifications to the ECU firmware can bypass this pin 1 grounding requirement, enabling out-of-band communication, although this method may have stability issues and requires further refinement.
Upon successful completion of the 5-bit baud initialization, the targeted control unit will respond with two bytes, signaling that the communication path is established. Following this, communication proceeds with a byte-for-byte exchange: sending a byte will result in receiving a byte in response.
MUT-II and the Transition to OBD2
While MUT-II is distinct from OBD2, it represents an earlier step in automotive diagnostic evolution. OBD2, standardized in the mid-1990s, aimed to create a universal diagnostic system across all manufacturers. Vehicles equipped with MUT-II predate this standardization. Understanding MUT-II is therefore essential for diagnosing and servicing older Mitsubishi vehicles. While direct “Mut 2 To Obd2” conversion isn’t technically accurate as they are different protocols, the knowledge of MUT-II provides a foundational understanding when working with pre-OBD2 Mitsubishi systems and when considering how diagnostic systems have evolved to the current OBD2 standards. For practical purposes, when working with these older systems, specialized MUT-II compatible tools or interfaces, sometimes alongside adapters to physically connect to OBD2 ports (even though the protocol is different), are necessary to effectively diagnose and communicate with the vehicle’s electronic control units.
