Table of contents: General information ↓ Main purpose ↓ Scheme of controller for interfacing… ↓ Recommendations for use ↓ General principles of data exchange ↓ Initialization of the controller and… ↓ Establishing a connection ↓ Initialization ↓ Data exchange procedure ↓ Modifications made to the latest… ↓ Establishing a connection ↓ Selecting a protocol ↓ Note and comments ↓
Warning: VPW standard applies to GM models, PWM standard applies to Ford models, ISO 9141-2 standard applies to Asian and European models.
General information
The device in question is a microcontroller made using CMOS technology.
Warning: The controller is not intended for connection to first generation on-board self-diagnostic systems (OBD I)!
The device acts as a simple scanner and is designed to read diagnostic codes and OBD II system data (engine speed, coolant and intake air temperature, load characteristics, engine air flow rate, etc.) within the framework of the SAE J1979 standard via any type of bus (PWM, VPW and ISO 9141-2).
Main purpose
A 3-wire cable is sufficient for connection to the computer, and a 6-wire cable is used to connect to the diagnostic connector. The supply voltage is supplied to the controller via the 16-pin OBD diagnostic connector. The schematic diagram of the controller is shown below.
Scheme of controller for interfacing personal computer with on-board self-diagnostic system OBD II
Recommendations for use
To connect the device to the car, an unshielded cable of no more than 1.2 m in length can be used, which is especially important when using the PWM protocol. When using a longer cable, the resistance of the resistors at the input of the device should be reduced (R8 and R9 or R15). When using a shielded cable, the shield should be disconnected to reduce capacitance.
The cable for connecting to the computer's serial port can also be unshielded. The device works stably with a cable up to 9 m long. With a significantly longer cable, a more powerful RS 232 communicator should be used.
The topology of electrical connections is arbitrary. In case of high humidity, use additional shunt capacitors.
Free software (browser) for reading codes and data can be downloaded from manufacturers' websites and is intended for use under DOS. The small size of the software application in the "under DOS" version allows it to be placed on a DOS boot diskette and used even on computers equipped with DOS-incompatible software. Even the presence of a hard disk in the computer is not a mandatory requirement.
General principles of data exchange
Warning: Unless otherwise stated, all numbers are given in hexadecimal format (hex).
The decimal format is indicated by the label dec.
Data exchange occurs via a three-wire serial connection, without the use of initialization exchange of service messages (handshaking). The device listens to the channel for messages, executes the received commands and transmits the results to the personal computer (PC), after which it immediately returns to the listening mode. The data entering and leaving the controller is organized as a chain of consecutive bytes, the first of which is the control byte. Usually the control byte is a number from 0 to 15 dec (or 0-F hex), describing the number of information bytes that follow. For example, a 3-byte command would look like this: 03 (control byte), 1st byte, 2nd byte, 3rd byte. This format is used both for incoming commands to poll the on-board self-diagnostics system and for outgoing messages containing the requested information. It should be noted that only four low-order bits are used in the control byte - the high-order bits are reserved for some special commands and can be used by the PC when initializing the connection with the controller and agreeing on the data transfer protocol, as well as by the controller to control transmission errors. In particular, in the event of a transmission error, the controller sets the most significant bit (MSB) of the control byte to one. In case of successful transmission, all four high-order bits are set to zero.
Warning: There are some exceptions to the rules for using the control byte.
Initialization of the controller and on-board self-diagnostic system
To start data exchange, the PC must establish a connection with the controller, then initialize the controller and the OBD II data channel.
Establishing a connection
After connecting the controller to the PC and the OBD diagnostic connector, it must be initialized to prevent "hangs" associated with noise in the serial lines if they were connected before the controller was powered on. At the same time, a simple check of the interface activity is performed. First, a single-byte signal 20 (hex) is sent, which the controller perceives as a command to establish a connection. In response, the controller sends a single byte FF hex (255 dec) instead of the control byte and goes into data reception standby mode. Now the PC can proceed to initializing the data channel.
Warning: This is one of the few cases where the controller does not use a control byte.
Initialization
At this stage, the protocol by which data will be exchanged is initialized, and in the case of the ISO protocol, the on-board system is initialized. Data is exchanged using one of three protocols: VPW (General Motors), PWM (Ford) and ISO 9141-02 (asian/European manufacturers).
Warning: There are many exceptions, such as when surveying certain car models Mazda ford's PWM protocol may be used. Therefore, if transmission problems occur, the first step should be to try using some other protocol.
The protocol selection is made by transmitting a combination consisting of the control byte 41 (hexadecimal) and the byte immediately following it, which determines the protocol type: 0 = VPW, 1 = PWM, 2 = ISO 9141. For example, the command 41(hex) 02(hex) initializes the ISO 9141 protocol.
In response, the controller sends a control byte and a status byte. Setting the MSB of the control byte indicates that there are problems, and the following status byte will contain the corresponding information. If initialization is successful, a control byte of 01 (hex) is sent, indicating that a verification status byte follows. In the case of VPW and PWM protocols, the verification byte is a simple echo of the protocol selection byte (0 or 1, respectively), when initializing the ISO 9141 protocol, this will be a digital key returned by the on-board OBD processor that determines which of the two slightly different protocol versions will be used.
Warning: The digital key is for informational purposes only.
It should be noted that the initialization of the VPW and PWM protocols is much faster, since it only requires the transfer of the relevant information to the controller. On models that comply with the ISO standard, initialization takes about 5 seconds, spent on the exchange of information between the controller and the on-board processor, performed at a speed of 5 baud. The reader should note that on some models of cars of the ISO 9141 family, protocol initialization is suspended if a request for data output is not transmitted within a 5-second interval - this means that the PC must automatically issue requests every few seconds, even in idle mode.
After the connection is established and the protocol is initialized, the regular data exchange begins, consisting of requests received from the PC and responses issued by the controller.
Data exchange procedure
The controller operates in several different scenarios when using the ISO 9141-2 and SAE (VPW and PWM) protocols.
Exchange via SAE protocols (VPW and PWM)
When exchanging data using these protocols, only one data frame is buffered, which means that the frame to be captured or returned must be specified. In some (rare) cases, the onboard processor may transmit packets consisting of more than one frame. In such a situation, the request must be repeated until all frames in the packet have been received.
Request is always formed as follows: [Control Byte], [SAE Standard Request], [Frame Number]. As mentioned above, the control byte is usually a number equal to the total number of bytes that follow it. The request is formed in accordance with SAE Specifications J1950 and J1979 and consists of a header (3 bytes), a sequence of data bytes, and an error check byte (CRC). Note that while the request information is formed in strict accordance with SAE Specifications, the consumer of the control byte and frame number is the interface chip.
If the procedure is completed successfully, the response message always has the following format: [Control Byte], [SAE Standard Response]. The control byte, as before, determines the number of information bytes that follow it. The response, in accordance with the SAE standard, consists of a header (3 bytes), a chain of information bytes, and a CRC byte.
In case of failure 2-byte is sent reply message: [Control byte], [Status byte]. In this case, the MSB is set in the control byte. The four least significant bits form the number 001, indicating that the control byte is followed by a single byte, the status byte. This situation can occur quite often, since the Specifications allow for the possibility of the on-board processor not issuing data, as well as the transmission of incorrect data in the event that the request does not correspond to the standard supported by the vehicle manufacturers. A situation is also possible when the requested data is not present in the processor's RAM at the current time. When the chip does not receive the expected response, or receives corrupted data, the MSB of the control byte is set, and the status byte is issued after the control byte.
In case of collisions in the bus, the interface generates a single byte 40 (hex), which is a control byte with the least significant bit set to zero. Such a situation can occur quite often when loading the car bus with messages of higher priority than diagnostic data - the computing device must repeat the original request.
Exchange according to ISO 9141-2 protocols
The ISO 9141-2 standard is used by most Asian and European automotive manufacturers. The structure of the generated PC request is not much different from that used in SAE standards, with the only difference being that the chip does not need information about the frame number and the corresponding information should not be present in the packet. Thus, request always consists of a control byte and a following chain of information bytes, including a checksum. As reply message the chip simply retransmits the signals generated by the on-board processor. There is no control byte in the response message, so the PC receives incoming information continuously until the chain is interrupted by a 55-millisecond pause, indicating the end of the information packet. Thus, the response message may consist of one or more frames in accordance with the requirements of the SAE J1979 Specifications. The chip does not analyze frames, does not discard non-diagnostic frames, etc. The PC must independently process the incoming data in order to isolate individual frames by analyzing the header bytes.
Warning: Responses to most queries consist of a single frame.
Modifications made to the latest versions of interface controllers
Below are the main differences in the data transfer process using the SAE and ISO 9141 protocols, typical for the latest versions of interface controllers, as well as the procedure for transferring data using the ISO 14230 protocol: 1. ISO 9141 standard: Added address byte;
2. ISO 9141: Returns not just one but both key bytes; (the extra byte is also returned in SAE modes, but is not used here).
3. Added support for ISO 14230 protocol.
Warning: All data bytes are transmitted in hexadecimal format.
Warning: The XX character represents an undefined, reserved, or unrecognized byte.
Establishing a connection
The connection setup procedure has not changed:
| Dispatch: | 20 |
| Reception: | FF |
Selecting a protocol
|
VPW:
|
|
|
Dispatch: |
41, 00 |
|
Reception: |
02, 01, XX |
|
PWM: |
|
|
Dispatch: |
41, 01 |
|
Reception: |
02, 01, XX |
|
ISO 9141: |
|
|
Dispatch: |
42, 02, adr, where: adr is the address byte (usually 33 hex) |
|
Reception: |
02, K1, K2, where K1, K2 are ISO key bytes |
|
Or: |
82, XX, XX (iSO 9141 initialization error) |
|
ISO 14230 (fast initialization): |
|
|
Dispatch: |
46, 03, R1, R2, R3, R4, R5, where: R1÷R5 - message about the beginning of the ISO 14230 request to establish a connection, usually R1÷R5 = C1, 33, F1, 81, 66 |
|
Reception: |
S1, S2, ……… - ISO 14230 connection setup response start messages |
Warning: More than one ECU may be transmitted in succession. A negative response code may be used as a response.
A typical positive answer looks like this: S1, S2, ……. = 83, F1, 10, C1, E9, 8F, BD
ISO 14230 (slow initialization): Similar to ISO 9141
Note and comments
If the controller is planned to be used for data transmission only via one or two of the protocols, unnecessary components can be excluded (see diagram above). For example, when organizing a circuit for the VPW (GM) protocol, only three wires of electrical wiring will be required in the wire connecting the controller to the car (terminals 16, 5 and 2).
If the PWM protocol is not used, elements R4, R6, R7, R8, R9, R10, T1, T2 and D1 can be excluded.
When refusing to exchange via the ISO protocol, the following elements are subject to exclusion: R15, R16, R17, R18, R19, R21, T4 and T5.
By not using the VPW protocol, the following elements can be eliminated: R13, R14, R23, R24, D2, D3 and T3.
Carbon film resistors with 5% resistance tolerance are used.
Please note that there is no emergency reset button (RESET), if necessary, such a reset can be done by disconnecting the controller from the car connector (the interface processor will reboot automatically). Restarting the software on the PC results in a new initialization of the interface.