As I understand the Scangauge email, DC engineers violated the standards based protocol by which the onboard computers communicate. They then deliberately introduced a software kludge to cause one of the computers on the bus to go to sleep so as not to cause other problems on the bus. If the software kludge is the only way to keep the computers communicating without problems, how are they going to remove it and not introduce the original problems they feared by violating the protocol? Note that I am not asking how they can remove the older flash updates for TCM, but how can they fix the problem with 2 masters or controllers on a bus that only permits one? It appears that this bug has to stay as it appears to disable one of the controllers so that the protocol is not violated. I have noticed that my obdii software will report losing communication with the CRD OBDII port nearly every time I use it more than a few minutes at a time. This does not happen on my V6 Liberty with the same software.
I won't even go into asking why these engineering clowns didn't know what they were working with in terms of protocol in time to avoid the violation and who approved a software kludge instead of using a compliant hardware solution.
EDIT: Found some info on the ISO 9141-2 bus. It is a standard derived orignally from CARB work. But the OBDII connector has access to the SCI and PCI bus on the Liberty and I assume, 91941-2 as well, since it was designed for diagnostics.
Here is a partial description of the bus from another site (
http://www.evaluationengineering.com/ar ... 98auto.htm )
Every vehicle coming off the assembly line today is stuffed with microcontrollers and microprocessors. To coordinate all the processing power distributed throughout the vehicle, each car or truck must have its own computer network—without which the engine could not run, the brakes would not work, and...you get the idea.
When computer control was introduced to the automotive industry, each manufacturer developed proprietary architectures and protocols. This strategy proved inefficient and costly. The next step was collaboration on a set of standards to implement and use vehicle-based computer networks.
In Part 1 of this article in the January issue of EE, we introduced the On-Board Diagnostics (OBD) law and its impact on the adoption of a standard diagnostic connector for cars and light trucks sold in this country.1 The law requires that the vehicle manufacturer equip the vehicle with the connector and that it support at least one of three network standards. Two of these standards, J1850 VPW and J1850 PWM, were examined in Part 1.
Now we will look at the International Standards Organization (ISO) 9141-2, the third of the OBD network interface standards. It is used in cars and light trucks as the diagnostic connection between on-vehicle computers and off-vehicle test equipment. For practical purposes, the 9141-2 standard is a subset of the 9141 network standard for the interconnection of computers within the vehicle.
The ISO 9141-2 standard sometimes is known as the 9141 California Air Resources Board (CARB) standard. The precursor to the OBD-II law was a California regulation that originally referred to the ISO 9141 standard. Later, the CARB regulation adopted a revised standard, ISO 9141-2, subtitled CARB Requirements for Interchange of Digital Information.
The ISO 9141 is the parent of the ISO 9141-2 standard. With respect to the OSI network model, these standards refer primarily to the bottom two layers: the physical and data link.
An ISO 9141 Network
The principal characteristics of the ISO 9141-2 network are:
Physical layer: two wires (not a balanced signal).
Data rate: 10.4 kb/s.
Bit time: 96.15 µs.
The architecture of ISO 9141 departs considerably from the two J1850 networks and, in general, from most network structures. A J1850 network does not have a central or primary node, and there is no real concept of signal direction or flow.
In a J1850 network, all nodes are equal because any node may transmit a message and all nodes receive all messages. Likewise, symbol and message timing are irrespective of who is transmitting and who is receiving.
In a network compliant with ISO 9141-2, message-flow direction is important. The specification was written with respect to the connection of off-board test equipment to an ISO 9141 network-equipped vehicle. Message direction and timing issues are based on who is talking and who is listening.
The interface of interest is the vehicle diagnostic connector, also known as the J1962 connector which is the Society of Automotive Engineers specification for the connector. Figure 1 is a network block diagram.
Definitions
The symbols used in ISO 9141 are shown in Table 1. Only two symbols are really defined: logic 0 and logic 1. The significance of the Start and Stop bits is determined by where they show up.
Physical Layer
An ISO 9141 bus consists of two wires designated the K-line and L-line. Each line may exist in the high (logic 1) or low (logic 0) state. The voltage level on the wire determines the state.
Unlike J1850, the K- and L-lines do not exist in a passive or active state. When a node is powered, both lines are pulled up to the battery voltage (Vbatt) via a set of pull-up resistors. Both lines idle in the 1 state. For a node to transmit a 0, it pulls the desired line to ground and holds it there for 1-bit time.
Bus
The K-line is bidirectional and shared by all nodes in the vehicle as well as the off-board test equipment. All nodes listen to this line and transmit on it. The K-line architecture looks like the familiar wired OR circuit. This results in a logic 0 being the dominant bit on the network, the same as J1850.
The L-line is unidirectional, and only the off-board test equipment may transmit on it. Modules that support off-board diagnostics may have the requirement to listen to this line.
ISO 9141-2 Communications
The ISO 9141 network is based on the Universal Asynchronous Receiver Transmitter. This device is found in RS-232, -422, and -485 communications links.
Both Start and Stop bits are used. The signaling is non-return-to-zero. All symbols are 1 bit time in duration, and the bit time is fixed. A Start bit is a logic 0 for 1-bit time. Similarly, a Stop bit is a logic 1 for 1-bit time.
All messages are transmitted as one or more bytes. Each byte is sent as a packet of bits. A Start bit precedes a byte. Eight data bits are used. The data bits are sent as the least significant bit first to the most significant bit last. A Stop bit is appended to the end. Figure 2 is a diagram of a byte as it would appear on the K- or L-line.
Time’s Up
Unlike J1850, there are no special symbols like start-of-frame or end-of-data. The significance of 1 byte in a message as compared to another or where one message ends and another begins is strictly a function of time.
The specification defines windows for all time parameters, one for every situation. Some examples of these windows are the time between bytes from the tester or the time from the end of a vehicle message until the next tester message starts.
The various times are noted as W times and P times. At least one of the times is dynamic and dependent on where the tester is sending a message. The W times apply during the initialization phase, and the P times apply during other communications.
Anyone Home?
If you grab a J1850 interface and laptop, connect it to a vehicle, and send it an OBD-II query message such as report oil pressure (assuming everything is operational), the vehicle engine controller will respond with an oil-pressure report message. Do this with an ISO 9141-2 interface and a similarly equipped vehicle and you will not get any response.
Before an off-board tester can communicate with an on-board computer, according to ISO 9141-2, the communications link must be initialized. The initialization sequence permits the two parties, the off-board tester and the on-board computer, to recognize one another and ensure each knows who the other is as well as the means by which they will communicate.
The standard should be referenced but, in essence, here is the initialization sequence:
The tester sends 51 at 5 baud on both the K- and L-lines. Once completed, the L-line is disabled and idles in the high state.
The vehicle computer(s) wake up, but only the computer responsible for diagnostics answers with 85 at 10.4 kb/s. This is the synchronization byte.
All subsequent communications occur at 10.4 kb/s.
The vehicle computer sends Keyword #1, a 1-byte value.
The vehicle computer sends Keyword #2, a 1-byte value.
Keywords are sent seven data bits with one odd parity bit.
The tester acknowledges by sending the logic bit-wise inversion of Keyword #2.
The vehicle computer acknowledges by sending the logic bit-wise inversion of the wake-up address (that the tester sent in step 1).
At this point, the communications link is initialized and operational.
Once the link is initialized, it must be maintained. If there is no message traffic on the link for 5 s, each computer assumes communications are over. The initialization sequence must be repeated to re-establish the link. The tester may periodically transmit a keep-alive message to maintain the link.
Quick Comparison
The differences between ISO 9141-2 and J1850 extend beyond voltage levels, bit timing, and physical characteristics. Essentially, J1850 is a message-oriented protocol (a whole message is sent) while ISO 9141 is a byte-oriented protocol (one byte at a time is sent).
On a more subtle note, a J1850 network is used for both down-the-road and diagnostic messages. An ISO 9141-2 interface into an ISO 9141 network was designed to support off-board diagnostic equipment. The same interface may not be compatible when network computers are communicating while moving down the road. On an ISO 9141 network, when a tester is not present, the bus may be used by on-board computers to communicate at other baud rates and timing requirements.
Login
Register
FAQ
Search
