This is a collection of various pages and files that may help if you are writing programs to run on a PC and communicate with a vehicle using the interface circuitry.
No programming support is available.
MESSAGE FRAME structure This defines the general structure of message frames for the different protocols : Header bytes, Data bytes, Error check bytes.
MODE 1 and MODE 2 Definitions These are the Parameter Identification (PID) definitions for mode 1 and 2. Mode 1 and 2 are the most important modes, and may be all you ever need other than mode 3 and 4, which read and clear trouble codes. These functions return various vehicle information such as Speed, Temperature, etc. Mode 2 is basically the same as mode 1, except is was stored at a point in time when the vehicle set a trouble code, so it is referred to as "Freeze Frame" data. Most of the PIDs are defined exactly the same for these two modes.
This mode has the sole function of retrieving any trouble codes that the vehicle may have set and stored. Note that a vehicle may not respond at all to a mode 3 Request if it has not set any trouble codes.
This mode clears any trouble codes that the vehicle may have set and stored. Note that ALL diagnostic data is cleared, as well as the trouble codes, so be sure to retrieve any data that you may need before you run mode 4.
CRC and Checksum Definitions
Here is information on how to calculate the Cyclic redundancy (CRC) or Checksum data byte. The VPW and PWM protocols use the CRC byte for error detection, while ISO 9141 vehicles use a simple Checksum byte. The checksum is the last byte in the message frame, and it is calculated using all the other bytes. Note that the Control byte and the Frame number byte are specific to the Interface chip, and these bytes do not enter into the CRC or Checksum calculation.
The method of calculating the CRC or Checksum is defined by SAE and ISO, respectively. Rather than try to define it here, the below code is offered. .
These are logfiles that illustrate the exact data exchanged between a computer and a vehicle Via the interface circuitry. They were taken using an actual vehicle, with a modified version of DIAGNOSE.EXE which generated log files for each transaction. The logfiles were then edited to show what each piece of information is. To view these files, you need to use a fixed width font. If your browser can't show them properly, Just download the text files (Usually, you can do that by right clicking on the link above and selecting "save document as.." . Then you can use a text editor such as notepad or wordpad to see them or print them out.
The data will show you exactly what to use for header , mode and pid bytes, as well as what to expect from the vehicle for the PWM protocol. Note that other protocols use different header bytes, control bytes, and frame bytes.
PWM - Mode 1 - Mode 1 messages using PWM Protocol.
Serial Port communication
Communications to and from the device are by way of a standard serial port. (You may be able to use a USB/serial converter cable which is properly installed and functioning.)
If you are unsure if your port is functioning, there are some instructions linked in the FAQ which may help to test the port independently of external devices.
Parameters:
19200 Baud
1 Start bit
1 Stop bit
8 bit data byte
NO Parity
NO Handshaking
NOTE: ascii encoding is NOT used. Consequently, you cannot use a terminal program such as hyperterminal.
Terminal programs are only able to send the ascii character set, and they can only display the printable ascii characters.
LOG file structure
The general structure of log files are discussed in the following tutorial. You should use WordPad to view the document since it makes use of formatting and color for clarity.