Why Some OBD II Trouble Codes Don’t Make Sense

The advent of affordable code readers and scanners has enabled many non-professional and DIY mechanics to diagnose and repair their own vehicles, but there are several downsides to investing in a cheap, generic code reader as well. In this article, we will discuss some of the most important shortcomings of generic code readers, as well as explain why most generic code readers don’t work on some vehicle makes and models, starting with-

“Nonsense” codes

Many DIY mechanics report that they routinely encounter OBD II trouble codes that don’t seem to make sense on the one hand, and that upon researching these codes, they don’t appear to be listed in any resource, on the other. Typically, these codes include the following, but note that the “nonsense” codes listed here represent neither an exhaustive, nor a complete list of codes that do not conform to the accepted format of OBD II codes-

• B2ERR

• B2TAE

• C07<D

• DAT

• ROR

Moreover, note that the above examples may or may not be followed by a series of numbers or other symbols. In almost all cases though, whether or not any of the examples above are followed by numbers of symbols depends on both the affected vehicle being scanned, and the code reader being used in question, with smart phone diagnostic apps often producing the most confusing examples.

In practice, most generic code readers, and particularly smart phone apps, are designed and intended by their creators to be used either on a specific make of vehicle, or sometimes, on a small range of makes and models. However, while it relatively easy to program a code reader, or construct a smart phone app that can access the most commonly occurring generic codes on a particular vehicle make or model range, this is far less easy to do that when vehicle or manufacturer specific codes are involved.

The SAE Standard J2012 describes a list of several thousand generic OBD II trouble codes and their definitions, and by an Act of Congress, all vehicles that are sold in the Unites States must be programmed so that any given generic trouble code means the same thing on any other vehicle.

For instance, all trouble codes, both generic and manufacturer specific, start with the letter B (body codes), or C (chassis codes), or P (powertrain codes), or U (communication codes), but if the first character (letter) is followed by a “0”, that code is a generic code that must have the same definition across all makes and models. One example will suffice; fault code P0300 – “Random/Multiple Misfire Detected”, must mean exactly the same thing on all vehicles that display the P0300 code.

As a practical matter, the PID’s (Fault Parameter Identifiers) of generic trouble codes are known and widely published, which makes it a fairly simple matter to construct a piece of software that can communicate with a particular serial bus communication system to extract any generic codes that may be stored by the OBD II system on any given vehicle.

However, things are vastly different when it comes to manufacturer specific codes, the definitions of which can be anything a particular manufacturer wants it to be. Again, one example will suffice to illustrate the problem- let us look at manufacturer specific code P1335 as a random example. In this example, various manufacturers define code P1335 in various ways to describe different issues, i.e.-

• Daewoo: Cylinder #5 Misfire – Circuit Open

• Nissan/ Infiniti: Crankshaft Position Sensor (CKPS) (Reference Voltage)

• Volkswagen/Audi/Volvo: Engine Torque Monitoring 2 Control Limit Exceeded

• Ford: EGR Position Sensor “A” Minimum / Maximum Stop Performance

There are thousands of other possible examples, but the point is that car manufacturers can, and do, assign any code that is not generic or SAE reserved, to any issue that is not covered by a generic code. Moreover, apart from the PID’s and diagnostic modes that apply to generic codes that must be made available to the car repair industry, manufacturers are free to develop their own proprietary PID’s for issues that are specific to their products.

More to the point though, car manufacturers are not obliged to share proprietary PID’s with anybody, including manufacturers of diagnostic equipment. In fact, in many cases, car manufacturers refuse to make proprietary PID’s and other diagnostic information available to the repair trade. This is known as captive technology/information, which means that even some high-end diagnostic equipment cannot always extract all stored fault codes/data, or access serial communication systems that are tied to captive information.

So where does this leave the average DIY mechanic? The short answer is that many DIY mechanics are often left up the proverbial creek without a paddle when they come across nonsensical fault codes such as the few listed in the beginning of this article. The simple truth is that nonsensical codes are caused by communication failures between PCM’s, CAN, or other serial communication bus systems, and code readers/scanners that are incompatible with any given serial communication protocol or standard .

Put in another way, miscommunications between cheap generic code readers and serial communication systems occur across all manufacturers, and involve conflicts between some (mostly cheap, generic) code readers and communication protocols and/or standards, which begs this question-

How do serial communication protocols/standards differ from each other?

Automotive electronics have become increasingly complex over the past two decades: in fact, modern management and control systems even in midrange passenger vehicles now demand more processing power to function as designed, than was required to land roving vehicles on Mars.

We need not delve into those complexities here, but suffice to say that the systems required to interconnect several dozen microprocessors with dozens of sensors that monitor every aspect of a vehicle’s operation are exceeding complex. Moreover, serial communication systems are also required to operate in a stable manner in noisy electromagnetic environments, have a certain degree of fault tolerance, be capable of self-diagnosis, as well as be capable of prioritizing some data classes, while being capable of managing data on either a time or event based scheme, at the same time.

All of the above is a very tall order indeed, and while most modern serial communication bus systems manage some aspects better than some other aspects, the demands of modern automotive control systems are such that no serial communication system can cope with all aspects equally well. Therefore, the communication requirements of many, if not most vehicles are managed by a combination of two or more communication protocols or standards, or by a system in which dedicated control/management functions are performed by dedicated, but different, communication protocols/systems/standards.

An example of such an arrangement would be where one standard that supports a communication speed of say, 10.4 Kilo baud manages infotainment, and power window/seat adjustment systems. On the same vehicle, another standard that supports a communication rate of say, 41.6 Kilo baud might manage the ABS, fuel and ignition systems, as well as advanced driver assist systems such as Traction, Stability, and Cruise control systems. The interface between the two standards would be determined by the overall architecture of the serial communications system as a whole, which differs between manufacturers, and even between models in a model range.

Limited space precludes a full treatment of this aspect of serial communication systems, but for reference purposes, we have compiled a list of the most commonly used automotive serial communications systems in use today, as well as some of the salient features of each system, starting with-

CAN (Controller Area Network) systems

First introduced in the late 1980’s CAN bus systems employ pairs of wires that are twisted together to make the overall system more resistant against interference caused by electromagnetic fields. Most CAN bus systems typically have two circuits; a low speed circuit that typically controls/manages some body functions like window and seat adjustments and a high-speed circuit that typically controls the ABS and other systems- some of which include engine management functions on some applications.

Common features

• Maximum Data Transfer Rates: 1Mbps @ 40m, 125Kbps @ 500m, 50kbps @ 1000m

• Circuit Type: Differential – meaning the system consists of two discrete circuits

• Physical Layer: Twisted wire pair

• Transmission Format: Asynchronous- meaning the low and high speed circuits can function independently of each other

• Drive Voltage: High: 2.75v ~ 4.5v; Low: 0.5v ~ 2.25v; Differential: 1.5v ~ 3.0v

• Network Layout Point to Point – meaning microprocessors are directly linked by the system branches

• Supported Standards: ISO 11898/11519

NOTE: The term “bit rate” refers to the speed at which data can be transmitted per second, but note that the rate of data transfer is a function of the duration of each bit of data. This means that the more data is contained in a bit, the fewer the bits that can be transmitted per second.

LIN (Local Interconnect Network)

First introduced in 1999, LIN systems have the advantage that they can be implemented by a single wire, with the vehicle frame serving as a current return path, aka ground connection. While LIN systems are generally very slow and uncomplicated relative to more advanced systems, LIN systems are commonly used to interconnect “intelligent” actuators and sensors.

Common features

• Maximum Data Transfer Rates: 19.2 Kilo baud @ 40m

• Physical Layer: Single-wire

• Transmission Format: SCI (UART) Data Format

• Operating Voltage: 12 VDC using a single wire

• Network Layout: Single Master Control Unit and up to 16 sensors and/or actuators

• Supported Standards: Enhanced ISO 9141

NOTE: The term “baud rate” refers to the maximum number of bits of data that can be transmitted in a system. Thus, if the baud rate of a communication system is pegged at say, 9600 baud, that system can transmit a maximum of 9600 bits of data per second. Note though that at baud rates that are in excess of 76 800, the quality of the installation becomes a serious limiting factor concerning the distance that data can be transmitted.

FlexRay

Flex Ray systems are a relatively new development that is intended for use on high-speed systems such as wireless steering and braking systems. The principal advantage that a FlexRay system has over other systems is its modular nature, and the fact that it is highly fault tolerant, especially with regard to its synchronization mechanisms.

Common features

• Maximum Data Transfer Rates: 500 kbps to about 10 Mbps

• Communication Modes: Either time-triggered, or event-triggered depending on the implementation

• Network Layout: Either single-channel or, or dual-channel layout depending on the implementation

MOST (Media Oriented Systems Transport)

Designed in cooperation with carmaker BMW, Becker Radio, and DaimlerChrysler, MOST systems are commonly used to manage and/or control multimedia applications, such as car audio systems, CD /DVD players, and GPS navigation systems in modern vehicles. Since MOST systems transfer data though fibre optic conduits, these systems typically have date transfer rates that far exceed those of other types of serial communications systems.

Common features

• Maximum Data Transfer Rate: 150 Mbps

• Layers: All seven layers of the ISO/OSI Reference Model for Data Communication

• Network Layout: Point to point via a ring layout, but Star configurations are also in common use

• Other Features: Supports Plug and Play functionality with up to 60 channels, and up to 15 MPEG1 channels that are user-configurable

• Standards: ISO 7498-1 (OSI Model)

Ethernet

Although Ethernet-based serial communication systems are not currently used in mainstream vehicles, these systems have the types of advantages over other systems that should make it more popular in next-generation vehicles.

Common features

• Maximum Data Transfer Rate: Current iterations are limited to about 100 Mbps for automotive applications, although data transfer rates of about 100 GB/per second are possible

• Network Layout: Star, line, and clustered layouts have proven to be successful in concept vehicles

One more thing…

The above are simple descriptions of very complex systems. In terms of diagnostics however, the complexity of serial bus communication systems is compounded by the fact that there are several protocols that determine the actual signaling that occurs within a system. Moreover, since some signaling protocols are controlled by specifications drawn up by the SAE (Society of Automotive Engineers), and others are controlled by standards drawn up by the ISO (International Organization for Standardization), two competing protocols are generally not compatible. This is true concerning each other, and especially so with generic code readers that are more often than not, programmed to function with only one signaling protocol.

In practice, there are currently 5 signaling protocols that are all compatible with OBD II systems that use the 16-pin J1962 DLC (Data Link Connector) but note that that is where the similarity ends. In practice, different manufacturers use different signalling protocols, details of which are listed below

• SAE J1850 PWM (Pulse Width Modulation) standard operates at 41.6 Kilo baud per second, and is used by Ford

• SAE J1850 VPW (Variable Pulse Width) operates at 10.4 to 41.6 Kilo baud, and is used by General Motors

• ISO 9141-2 standard operates at 10.4 Kilo baud, and is used mainly by Chrysler, and most European and Asian vehicles

• ISO 14230 KWP2000 (Keyword Protocol 2000) operates at 10.4 kbps, and may be used on some Chrysler, European, and Asian vehicles

• ISO 15765 CAN typically operates at speeds of either 250 kbps or 500 kbps, but speeds of up to 1Mbps are in use on some high-end applications. Note that most vehicles made and sold in the North American marker are fitted with CAN-based serial communication systems

As if the above is not complicated enough, it should be noted that any given communication protocol can be defined by any one of several technical standards, the most common of these being, ISO 11898, SAE J1962, J1850, J1939, J1978, J1979, J2012, J2178-1, J2178-2, J2178-3, and/or J2178-4.

In addition, it should be noted that apart from the above, some vehicle manufacturers sometimes develop their own proprietary serial communication standards, or impose proprietary message structures and/or content upon “open-source” protocols, including most CAN iterations and some FlexRay configurations.

In these cases, vehicle manufacturers are not obliged to share their (patented) communications technologies with anybody, but should they elect to share with manufacturers of diagnostic equipment, the licensing costs are often prohibitively expensive, which means that in many cases, some diagnostic and fault data can be retrieved with software that only dealerships have access to.

Conclusion

It is our hope that you have found the information in this article helpful, and that it explains why many generic code readers and smart phone apps produce “trouble codes” that don’t make sense. It is simply a matter of computers failing to recognize each other, but once you understand why miscommunications occur, you may want to invest in a code reader that is programmed with the specific protocol and standards that define the serial bus communication in your particular vehicle.