How does OBD-II data logging work?
In practical terms, OBD-II works as follows:
- You connect a OBD2 scanner or OBD2 data logger to the OBD-II 16 pin connector
- Via the tool, you enter “request messages” (queries) transmitted via the CAN-bus
- The relevant ECUs react and send “response messages” via the CAN-bus
Why is this important to understand?
It means that you will not see OBD-II data if you plug in a passive/silent CAN logger or interface to your car (though you'd see plenty of raw CAN frames).
To log OBD-II response messages, your OBD2 data logger needs to be able to send the request messages.
This feature was recently added to the CANLoggerX000 and you can check out our practical application (in an Astra) of it here.
Note: If you wish to log OBD2 data, it is helpful to set up the logger filters to only accept the valid OBD2 message range. Otherwise you will also get all the proprietary messages, making it harder to analyse the output.
Can you please explain OBD-II PIDs for dummies?
If you want to get started with recording data from your car’s OBD-II system, it’s helpful to understand the basics of the message structure. Don’t worry, this will be kept high level!
In simplified terms, an OBD-II message is comprised of an identifier and data. Further, the data is split in Mode, PID and data bytes Ah, Bh, Ch, Dh - cf. the figure below.
An example of a request/response CAN message for the PID ‘Vehicle Speed’ with a value of 50 km/h can look like this:
Request: 7DF 02 01 0D 55 55 55 55 55
Response: 7E8 03 41 0D 32 aa aa aa aa
You can try to enter the response message in our OBD-II message converter to confirm the result.
Note that when using the calculator you need to exclude the ID (7E8) and data length (03).
Below, the various parts of the OBD-II message are explained:
Identifier: For OBD-II messages, the identifier is standard 11-bit and used to distinguish between “request messages” (ID 7DF) and “response messages” (ID 7E8 to 7EF). Note that 7E8 will typically be where the main engine or ECU responds at.
Length: This simply reflects the length in number of bytes of the remaining data (03 to 06). For the Vehicle Speed example, it is 02 for the request (since only 01 and 0D follow), while for the response it is 03 as both 41, 0D and 32 follow.
Mode: For requests, this will be between 01-0A. For responses the 0 is replaced by 4 (i.e. 41, 42, … , 4A). There are 10 modes as described in the SAE J1979 OBD-II standard. Mode 1 shows Current Data and is e.g. used for looking at real-time vehicle speed, RPM etc. Other modes are used to e.g. show or clear stored diagnostic trouble codes and show freeze frame data.
PID: For each mode, a list of standard PIDs exist - e.g. in Mode 01 PID 0D is Vehicle Speed. For the full list, check out the aforementioned Wikipedia OBD-II PID overview. Each PID has a description and some have a specified minimum/maximum and conversion formula. The formula for speed is e.g. simply A, meaning that the Ah data byte (which is in HEX) is converted to decimal to get the km/h converted value. For RPM (PID 0C), the formula is (256*A + B) / 4.
Ah, Bh, Ch, Dh: These are the data bytes in HEX, which need to be converted to decimal form before they are used in the PID formula calculations. Note that the last data byte (after Dh) is not used.
Importantly, not all cars support all PIDs (in particular older cars). As such, you may find it far easier to get valid OBD-II data returned in a car from 2015 vs a car from 2007 (yes, we tried).