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.

OBDII J1979 Specification Definitions
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.

Table 3: ISO15765 Message Structure
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.

Table 3: ISO15765 Message Structure
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.

Table 4: J1850PWM Message Structure
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:

J1850PWM Functional Addressing
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:

J1850PWM Physical Addressing
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

Table 5: J1850VPW Message Structure
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

Table 6: ISO9141 Message Structure
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
ISO14230
Table 7: ISO14230 Message Structure
Type Header (3) Data (254 max) Extra
H0 H1 H2 H3 D4 DN Checksum
Functional         X Y Z byte
Physical         X Y Z byte