Constructing an OBDII Message
In addition to reprogramming, J2534 supports diagnostics and calibration. The API provides protocol-independent functions to: read and write messages, establish periodic messages, perform filtering, and assert ECU reprogramming voltages.
The OBDII J1979 specifications defines:
Received messages may contain additional information beyond the extra data index including: a checksum, CRC, or in-frame response.
Protocol | Min Size | Max Size | Extra Data |
ISO15765 (Standard) | 4 | 4100 | never |
ISO15765 (Extended) | 4 | 4100 | never |
J1850PWM | 3 | 12 | IFR, CRC |
J1850VPW | 1 | 4128 | IFR, CRC |
ISO9141 | 1 | 4128 | Checksum |
ISO14230 | 4 | 260 | Checksum |
Received messages may contain additional information beyond the extra data index including: a checksum, CRC, or in‑frame response.
ISO15765 (Standard)
This protocol is a multi-frame version of CAN used on all recent (2004+) vehicles. It extends the CAN protocol in two main ways. First, it can transmit large logical messages (up to 4095 bytes) using a series of individual CAN frames. Second, it provides control over the rate at which individual message frames are transmitted.
There are two addressing modes: Standard (11‑bit) and Extended (29‑bit) and both are used on OBD‑II vehicles.
Type | Header (4) | Data (4095 max) | ||||||
D0 | D1 | D2 | D3 | D4 | … | DN | EDI | |
Functional Request | 00 | 00 | 07 | DF | X | Y | Z | CRC |
Physical | 00 | 00 | 0A | BC | X | Y | Z | CRC |
Flow control filters are used to establish an ISO 15765 conversation. These filters automatically transform the large logical messages (up to 4095 bytes) into a series of individual CAN frames (up to 7 bytes each). By default, the CarDAQ requests that multi-frame message be sent as quickly as possible, in a single burst, with no interruption. Be aware, many engine controllers are sensitive to the format of the flow control message. Some controllers expect the messages to be zero-padded to a full 8 bytes, while others expect only the necessary data. Adjust the ISO15765_FRAME_PAD flag to match the expected behavior.
Functional Addressing
The tester can broadcast an OBD‑II request using identifier 00 00 07 DF. In this mode, expect several modules to respond to each request. There are no other interesting, standard functional addresses available on this protocol.
Physical Addressing
For this protocol, each automaker assigns addresses differently.
OBD‑II Tester Code
// Establish a logical communication channel using ISO15765
PASSTHRU_MSG Mask, Pattern, FlowControl;
U32 ChannelID, MsgID, i;
PassThruConnect(ISO15765, 0, &ChannelID);
for (i=0; i < 7; i++)
{
Mask.ChannelID = ISO15765;
Mask.DataSize = 4;
Mask.Data[0] = 0x00;
Mask.Data[1] = 0x00;
Mask.Data[2] = 0x07;
Mask.Data[3] = 0xFF;
Pattern.ChannelID = ISO15765;
Pattern.DataSize = 4;
Pattern.Data[0] = 0x00;
Pattern.Data[1] = 0x00;
Pattern.Data[2] = 0x07;
Pattern.Data[3] = (0xE8 + i);
FlowControl.ChannelID = ISO15765;
FlowControl.DataSize = 4;
FlowControl.Data[0] = 0x00;
FlowControl.Data[1] = 0x00;
FlowCotrol.Data[2] = 0x07;
FlowControl.Data[3] = (0xE0 + i);
PassThruStartMsgFilter(ChannelID, FLOW_CONTROL_FILTER, Mask, Pattern, FlowControl, MsgID);
}
Mask.ChannelID = ISO15765;
Mask.DataSize = 4;
Mask.Data[0] = 0x00;
Mask.Data[1] = 0x00;
Mask.Data[2] = 0x07;
Mask.Data[3] = 0xF8;
Pattern.ChannelID = ISO15765;
Pattern.DataSize = 4;
Pattern.Data[0] = 0x00;
Pattern.Data[1] = 0x00;
Pattern.Data[2] = 0x07;
Pattern.Data[3] = 0xE8;
PassThruStartMsgFilter(ChannelID, PASS_FILTER, Mask, Pattern, NULL, MsgID);
ISO15765 (Extended)
This protocol was developed for OBD‑II diagnostics, and has been adopted for most vehicle manufacturer enhanced diagnostics. It is commonly used on all recent (2004+) vehicles.
It extends the CAN protocol in two main ways. First, it can transmit large logical messages (up to 4095 bytes) using a series of individual CAN frames. Second, it provides control over the rate at which individual message frames are transmitted.
Type | Header (4) | Data (4095 max) | ||||||
D0 | D1 | D2 | D3 | D4 | … | DN | EDI | |
Functional Request | 00 | 00 | 07 | DF | X | Y | Z | CRC |
Physical | 00 | 00 | 0A | BC | X | Y | Z | CRC |
Flow control filters are used to establish an ISO 15765 conversation. These filters automatically transform the large logical messages (up to 4095 bytes) into a series of individual CAN frames (up to 7 bytes each). By default, the CarDAQ requests that multi‑frame message be sent as quickly as possible, in a single burst, with no interruption.
Be aware, many engine controllers are sensitive to the format of the flow control message. Some controllers expect the messages to be zero‑padded to a full 8 bytes, while others expect only the necessary data. Adjust the ISO15765_FRAME_PAD flag to match the expected behavior.
Functional Addressing
The tester can broadcast an OBD‑II request using identifier 00 00 07 DF. In this mode, expect several modules to respond to each request. There are no other interesting, standard functional addresses available on this protocol.
Physical Addressing
For this protocol, each automaker assigns addresses differently.
OBD‑II Tester Code
// Make sure you’re already connected to 11‑Bit ISO15765 // especially
including the flow control filters
// Request RPM: Header 00,00,07,DF Mode 01 PID 0C
Msg[0].ProtocolID = ulProtocolID;
Msg[0].TxFlags = TxFlags; // Remember 29‑Bit!!!
Msg[0].DataSize = 4 + NumDataBytes; // 6
Msg[0].Data[0] = 0x18;
Msg[0].Data[1] = 0xDB;
Msg[0].Data[2] = 0x33;
Msg[0].Data[3] = 0xF1;
Msg[0].Data[4] = 0x01;
Msg[0].Data[5] = 0x0C;
PassThruWriteMsgs(ChannelID, &Msg[0], &NumMsgs, WRITE_DELAY_TIME);
J1850PWM
This protocol is most commonly used with Ford SCP. It supports both physical and functional addressing with a three byte header.
Type | Header (3) | Data (5 max) | Extra (2 max) | |||||
Flags0 | Dest1 | Source2 | D4 | … | DN | IFR | EDI | |
Functional | 61 | 6A | F0 | X | Y | Z | byte | byte |
Physical | 64 | 10 | F0 | X | Y | Z | byte | byte |
Functional Addressing
The tester can broadcast a request to all modules that perform a specific function. For example, several nodes listen for OBD‑II requests on functional address 6A, and send their responses to address 6B. In this mode, several modules can respond to a single request. Although OBD‑II is the most common use of functional addressing, but other systems support functional addresses as described below:
Module | Request | Response |
OBD-II | 6A | |
CarDAQ only regards a message if its destination address appears in the functional message lookup table. To perform OBD‑II testing, make sure to add 6B to the functional message lookup table.
Physical Addressing
The tester can send a request to a specific module, using its node address. The OBD‑II ECU is almost always physical address 10 on Ford vehicles. Other common node assignments are listed in the table below:
Module | Request |
Engine | 10 |
OBD‑II Tester Code
// Establish a logical communication channel using J1850PWM
PASSTHRU_MSG Msg;
SBYTE_ARRAY FuncAddrList;
U8 FuncAddr
PassThruConnect(J1850PWM, 0, &ChannelID);
FuncAddr = 0x6B;
InputMsg.NumOfBytes = 1;
InputMsg.BytePtr = &FuncAddr;
PassThruIoctl(ChannelID, ADD_TO_FUNCT_MSG_LOOKUP_TABLE, &InputMsg, NULL);
J1850VPW
Type | Header (3) | Data (4127 max) | Extra | |||||
Status0 | Source1 | Dest2 | D4 | … | DN | IFR | EDI | |
Functional | 61 | 6A | F0 | X | Y | Z | byte | byte |
Physical | 64 | 10 | F0 | X | Y | Z | byte | byte |
ISO9141
Type | Header (3) | Data (4127 max) | Extra | |||||
Status0 | Source1 | Dest2 | D4 | … | DN | IFR | EDI | |
Functional | 68 | 6A | F0 | X | Y | Z | byte | byte |
Physical | 10 | F0 | X | Y | Z | byte | byte |
Type | Header (3) | Data (254 max) | Extra | |||||
H0 | H1 | H2 | H3 | D4 | … | DN | Checksum | |
Functional | X | Y | Z | byte | ||||
Physical | X | Y | Z | byte |