Iso 9141-2 Code

[Dinah Lianes]

Thisis just another OBD2 solution for monitoring the sensors in a verhicle. It supports the K-line OBD2 serial communication between a verhicle and a microcontroller. This K-line communication is also known as ISO 9141-2 or ISO 14230-4 (also known as Keyword Protocol 2000 or KWP). Both ISO's are almost similar. This solution differs from the rest that is low cost (for less than 10 euro!!). It is low cost in the way that you don't need an arduino, raspberry pi or smart phone. Just a microcontroller and LCD display so you can use your smartphone for other purposes.

It is tested with a Citroen C1 gasoline (2013) and VW Touran gasoline (2003). Probably it will work for a Peugeot 107 and Toyota Aygo of 2013 as well since they are technically identical. From what I read on the internet there are many flavours on K-line around so there is a possibility it will not suit your car. Maybe some changes are needed to make it work. The source code is provided so you can investigate and change when needed. Maybe you can help extending this list of cars to help others!

Both ISO's 9141 and 14230 knows a 5 baud initialization sequence. The microcontroller must start this init by transmitting byte 0x33 to the verhicle at 5 bits per second. The total transmit time for transmitting byte 0x33 takes about 2 seconds. After this initialization it is expected to continue communicating at 10k4 baud.

For ISO 9141-2 the verhicle ECU will respond with synchronization byte 0x55. After this, the verhicle will respond with key bytes 0x08 and 0x08 or 0x96 and 0x96. The sync byte with key bytes of the verhicle must be acknowledged by the microcontroller by inverting the second key byte. This will end the initialization part of ISO 9141-2.

The response of ISO 14230 is slightly different. The verhicle ECU will also respond with synchronization byte 0x55. Only the key bytes are different. In case of a VW Touran of 2003 the key bytes are 0xef and 0x8f. Also here the second key byte must be acknowledged by the microcontroller by inverting it.

After the initialization process it is possible to submit a request to the verhicle ECU. A request is a sequence of bytes where adressing, a mode, a PID and a checksum is present. The following are example requests:

In this example mode 1 is used. This mode will show "current data" as how it is at this moment. This mode is perfect for displaying actual information. The data field contains the PID. In this case 0x0d which is the verhicle speed. The checksum is the sum of the bytes with mod 256. See this link for a list of PIDs:

A routine for displaying and clearing stored diagnostic trouble codes is included. This can be initiated by pressing the switch for 2 seconds. This routine is untested and will most probably not work. Feel free to try if you have a car with trouble codes.

The 5 baud init is also called "slow init". There is also a "fast init". The fast init does not use the 5 baud init as descibed above but starts directly at 10.4 kbps. A StartCommunication request 0xc1, 0x33, 0xf1, 0x81, 0x66 must be submitted prior submitting requests. I don't have a car which supports this fast init so maybe someone can help including it in this code to help others.

On-board diagnostics (OBD) is a term referring to a vehicle's self-diagnostic and reporting capability. In the United States, this capability is a requirement to comply with federal emissions standards to detect failures that may increase the vehicle tailpipe emissions to more than 150% of the standard to which it was originally certified.[1][2]

OBD systems give the vehicle owner or repair technician access to the status of the various vehicle sub-systems. The amount of diagnostic information available via OBD has varied widely since its introduction in the early 1980s versions of onboard vehicle computers. Early versions of OBD would simply illuminate a tell-tale light if a problem was detected, but would not provide any information as to the nature of the problem. Modern OBD implementations use a standardized digital communications port to provide real-time data and diagnostic trouble codes which allow malfunctions within the vehicle to be rapidly identified.

GM's ALDL (Assembly Line Diagnostic Link) is sometimes referred to as a predecessor to, or a manufacturer's proprietary version of, an OBD-I diagnostic starting in 1981. This interface was made in different varieties and changed with power train control modules (aka PCM, ECM, ECU). Different versions had slight differences in pin-outs and baud rates. Earlier versions used a 160 baud rate, while later versions went up to 8192 baud and used bi-directional communications to the PCM.[15][16]

The regulatory intent of OBD-I was to encourage auto manufacturers to design reliable emission control systems that remain effective for the vehicle's "useful life".[17] The hope was that by forcing annual emissions testing for California starting in 1988, [18] and denying registration to vehicles that did not pass, drivers would tend to purchase vehicles that would more reliably pass the test. OBD-I was largely unsuccessful, as the means of reporting emissions-specific diagnostic information was not standardized. Technical difficulties with obtaining standardized and reliable emissions information from all vehicles led to an inability to implement the annual testing program effectively.[19]

The Diagnostic Trouble Codes (DTC's) of OBD-I vehicles can usually be found without an expensive scan tool. Each manufacturer used their own Diagnostic Link Connector (DLC), DLC location, DTC definitions, and procedure to read the DTC's from the vehicle. DTC's from OBD-I cars are often read through the blinking patterns of the 'Check Engine Light' (CEL) or 'Service Engine Soon' (SES) light. By connecting certain pins of the diagnostic connector, the 'Check Engine' light will blink out a two-digit number that corresponds to a specific error condition. The DTC's of some OBD-I cars are interpreted in different ways, however. Cadillac petrol fuel-injected vehicles are equipped with actual onboard diagnostics, providing trouble codes, actuator tests and sensor data through the new digital Electronic Climate Control display.

Additional vehicle-specific diagnostic and control circuits are also available on this connector. For instance, on the Corvette there are interfaces for the Class 2 serial data stream from the PCM, the CCM diagnostic terminal, the radio data stream, the airbag system, the selective ride control system, the low tire pressure warning system, and the passive keyless entry system.[21]

OBD-II is an improvement over OBD-I in both capability and standardization. The OBD-II standard specifies the type of diagnostic connector and its pinout, the electrical signalling protocols available, and the messaging format. It also provides a candidate list of vehicle parameters to monitor along with how to encode the data for each. There is a pin in the connector that provides power for the scan tool from the vehicle battery, which eliminates the need to connect a scan tool to a power source separately. However, some technicians might still connect the scan tool to an auxiliary power source to protect data in the unusual event that a vehicle experiences a loss of electrical power due to a malfunction. Finally, the OBD-II standard provides an extensible list of DTCs. As a result of this standardization, a single device can query the on-board computer(s) in any vehicle. This OBD-II came in two models OBD-IIA and OBD-IIB. OBD-II standardization was prompted by emissions requirements, and though only emission-related codes and data are required to be transmitted through it, most manufacturers have made the OBD-II Data Link Connector the only one in the vehicle through which all systems are diagnosed and programmed. OBD-II Diagnostic Trouble Codes are 4-digit, preceded by a letter: P for powertrain (engine and transmission), B for body, C for chassis, and U for network.

The European on-board diagnostics (EOBD) regulations are the European equivalent of OBD-II, and apply to all passenger cars of category M1 (with no more than 8 passenger seats and a Gross Vehicle Weight rating of 2,500 kg, 5,500 lb or less) first registered within EU member states since January 1, 2001 for petrol-engined cars and since January 1, 2004 for diesel engined cars.[25]

Each of the EOBD fault codes consists of five characters: a letter, followed by four numbers.[26] The letter refers to the system being interrogated e.g. Pxxxx would refer to the powertrain system. The next character would be a 0 if complies to the EOBD standard. So it should look like P0xxx.

The term "EOBD2" is marketing speak used by some vehicle manufacturers to refer to manufacturer-specific features that are not actually part of the OBD or EOBD standard. In this case "E" stands for Enhanced.

In North America, EMD and EMD+ are on-board diagnostic systems that were used on vehicles with a gross vehicle weight rating of 14,000 lb (6,400 kg) or more between the 2007 and 2012 model years if those vehicles did not already implement OBD-II. EMD was used on California emissions vehicles between model years 2007 and 2009 that did not already have OBD-II. EMD was required to monitor fuel delivery, exhaust gas recirculation, the diesel particulate filter (on diesel engines), and emissions-related powertrain control module inputs and outputs for circuit continuity, data rationality, and output functionality. EMD+ was used on model year 2010-2012 California and Federal petrol-engined vehicles with a gross vehicle weight rating of over 14,000 lb (6,400 kg), it added the ability to monitor nitrogen oxide catalyst performance. EMD and EMD+ are similar to OBD-I in logic but use the same SAE J1962 data connector and CAN bus as OBD-II systems.[8]

Five signaling protocols are permitted with the OBD-II interface. Most vehicles implement only one of the protocols. It is often possible to deduce the protocol used based on which pins are present on the J1962 connector:[30]

3a8082e126