OBD2 CAN Bus Scanner: Your Guide to On-Board Diagnostics [2025]

Looking for a straightforward and practical introduction to OBD2 and CAN bus scanners?

This guide provides a comprehensive overview of the On-Board Diagnostics (OBD2) protocol, focusing on Obd2 Can Bus Scanners. We’ll delve into the OBD2 connector, OBD2 Parameter IDs (PIDs), and their connection to the CAN bus system.

This is a practical introduction, designed to equip you with the knowledge to request and decode OBD2 data, understand key logging applications, and offer valuable practical tips for using an OBD2 CAN bus scanner.

Discover why this has become a leading resource for understanding OBD2 and CAN bus scanning technology.

You can also watch our introductory OBD2 video above – or download the PDF guide

Understanding OBD2: The Basics

OBD2 is essentially your car’s internal health monitoring system. It’s a standardized protocol that allows you to retrieve diagnostic trouble codes (DTCs) and access real-time vehicle data through the OBD2 connector. Think of it as a universal language for car diagnostics, and an OBD2 CAN bus scanner as your translator.

You’ve likely encountered OBD2 in action before:

Ever seen the check engine light illuminate on your dashboard?

That’s your vehicle signaling a potential issue. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the problem. Specifically, many modern scanners are OBD2 CAN bus scanners, leveraging the Controller Area Network (CAN) bus for communication.

To diagnose your car, a mechanic connects the OBD2 CAN bus scanner to the 16-pin OBD2 connector, typically located near the steering wheel. The scanner sends ‘OBD2 requests’ to the car’s computer system. The car then responds with ‘OBD2 responses’, which can include vital information like speed, fuel levels, and Diagnostic Trouble Codes (DTCs). This data is crucial for efficient troubleshooting and repair. Using an OBD2 CAN bus scanner makes identifying and resolving car problems faster and more accurate.

Image alt text: Illustration showing a car dashboard with the malfunction indicator light (MIL) illuminated, next to an OBD2 CAN bus scanner, highlighting the diagnostic process.

OBD2 Compatibility: Does Your Car Have It?

The short answer is: Almost certainly!

The vast majority of modern non-electric vehicles are equipped with OBD2, and most of these systems operate on the CAN bus protocol. For older vehicles, it’s important to note that even if a 16-pin OBD2 connector is present, it might not actually support the OBD2 standard. A reliable way to check for OBD2 compliance is to consider the vehicle’s purchase location and year:

Image alt text: Chart outlining OBD2 compliance by region (EU, US) and vehicle type (car, light truck) with timelines, emphasizing CAN bus adoption and relevance to OBD2 CAN bus scanners.

A Brief History of OBD2

OBD2’s origins trace back to California, where the California Air Resources Board (CARB) mandated OBD systems in all new vehicles from 1991 onwards for emission control. This marked the beginning of standardized vehicle diagnostics, paving the way for tools like the OBD2 CAN bus scanner.

The OBD2 standard itself was developed and recommended by the Society of Automotive Engineers (SAE). It standardized Diagnostic Trouble Codes (DTCs) and the physical OBD connector across different vehicle manufacturers (SAE J1962). This standardization is what allows a single OBD2 CAN bus scanner to work across various car brands.

The implementation of OBD2 was a gradual process:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: Required in the EU for gasoline cars.
2003: Required in the EU for diesel cars as well (EOBD).
2005: OBD2 became mandatory in the US for medium-duty vehicles.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication, making OBD2 CAN bus scanners essential.
2010: OBD2 requirement extended to heavy-duty vehicles in the US.

Image alt text: Graphic depicting the historical timeline of OBD2 adoption for emission control, highlighting key milestones and the increasing role of CAN bus in OBD2 systems and OBD2 CAN bus scanners.

Image alt text: Timeline visualization of OBD2 history, from its inception for emission control to its widespread adoption, emphasizing the evolution of on-board diagnostics and the development of OBD2 CAN bus scanners.

Image alt text: Conceptual image representing the future of OBD, including OBD3, remote diagnostics, cloud connectivity, and IoT integration, showcasing the evolution beyond basic OBD2 scanners to advanced OBD2 CAN bus scanner technologies.

The Future of OBD2 and OBD2 CAN Bus Scanners

OBD2 is firmly established, but its future is evolving. Understanding these trends is crucial for anyone involved in vehicle diagnostics or using OBD2 CAN bus scanners.

Originally designed for emissions testing, legislated OBD2 has an interesting position with electric vehicles (EVs). Notably, EVs are not obligated to support OBD2 in its traditional form. In fact, most modern EVs largely bypass standard OBD2 requests, opting instead for OEM-specific UDS communication protocols. This shift can make accessing data from EVs challenging unless decoding methods are reverse-engineered. However, progress is being made, as seen in case studies for electric vehicles like Tesla, Hyundai/Kia, Nissan and VW/Skoda EVs, where solutions for data access, potentially using advanced OBD2 CAN bus scanners, are emerging.

Current OBD2 implementations have limitations, particularly in data richness and lower-layer protocols. In response, newer standards like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are being developed. These aim to improve OBD communication by using the UDS protocol as a foundation. For a deeper dive into these protocols, refer to our introduction to UDS. Future OBD2 CAN bus scanners may need to support these evolving standards.

In our increasingly connected world, traditional OBD2 testing methods can seem outdated. Manual emission checks are time-consuming and costly.

The proposed solution? OBD3: Integrating telematics into all vehicles.

OBD3 envisions adding a small radio transponder to every car, similar to those used for bridge tolls. This would allow vehicles to transmit their vehicle identification number (VIN) and DTCs wirelessly via WiFi to a central server for automated checks. This opens up possibilities for remote diagnostics and advanced OBD2 CAN bus scanner applications.

Many devices today already facilitate CAN or OBD2 data transfer over WiFi/cellular networks. Examples include the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger. These technologies could be seen as precursors to OBD3, enhancing the capabilities of OBD2 CAN bus scanners in a connected ecosystem.

While convenient and cost-saving, OBD3 raises political and privacy concerns related to surveillance. The balance between efficiency and data privacy will be a key factor in the future of OBD and OBD2 CAN bus scanner technology.

The original OBD2 protocol was designed for stationary emission control testing.

However, today, OBD2 is widely used by third parties to generate real-time vehicle data through OBD2 dongles, CAN loggers and advanced OBD2 CAN bus scanners. Interestingly, the German automotive industry is considering changes that could impact this third-party access (link to news article):

OBD was intended for car servicing in repair shops, not for creating a data-driven economy based on third-party access.

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal involves potentially disabling OBD2 functionality during driving and centralizing data collection with manufacturers. This would give manufacturers control over ‘automotive big data’. While security concerns, such as reducing the risk of car hacking, are cited, many view this as a commercially motivated move (link to blog post). Whether this trend gains traction remains to be seen, but it could significantly disrupt the market for third-party OBD2 services and the future applications of OBD2 CAN bus scanners.

Image alt text: Graphic depicting the potential future trend of electric vehicles limiting OBD2 data access, contrasting with the traditional accessibility of OBD2 CAN bus scanners in combustion engine vehicles.

Enhance Your CAN Bus Knowledge

Want to become a CAN bus expert and better understand your OBD2 CAN bus scanner?

Access our 12 ‘simple introductions’ in one comprehensive 160+ page PDF:

Download now

OBD2 Standards: A Deeper Dive

On-board diagnostics, or OBD2, is a higher-layer protocol (like a language). CAN bus acts as the communication method (like a telephone line). This makes OBD2 similar to other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000. Understanding these protocols helps in fully utilizing an OBD2 CAN bus scanner.

Specifically, OBD2 standards define the OBD2 connector, lower-layer protocols, OBD2 Parameter IDs (PIDs), and more. These standards ensure interoperability between vehicles and diagnostic tools, including OBD2 CAN bus scanners.

We can visualize these standards using a 7-layer OSI model. In the following sections, we will focus on the most critical aspects relevant to using an OBD2 CAN bus scanner.

Looking at the OSI model overview, you’ll notice that both SAE and ISO standards cover multiple layers. This reflects the development of OBD standards in both the USA (SAE) and Europe (ISO). Many of these standards are technically very similar, for example, SAE J1979 versus ISO 15031-5, and SAE J1962 versus ISO 15031-3. This international collaboration ensures that OBD2 CAN bus scanners are effective globally.

Image alt text: OSI 7-layer model diagram comparing OBD2 and CAN bus standards (ISO 15765, ISO 11898), illustrating the protocol layers relevant to OBD2 CAN bus scanners.

Image alt text: Diagram of an OBD2 connector pinout (female, type A, DLC), detailing pin assignments relevant to communication protocols used by OBD2 CAN bus scanners.

The OBD2 Connector [SAE J1962 / ISO 15031-3]

The 16-pin OBD2 connector is your gateway to accessing vehicle data. It’s standardized under SAE J1962 / ISO 15031-3, ensuring compatibility with OBD2 CAN bus scanners and other diagnostic tools.

The illustration shows a typical Type A OBD2 pin connector (sometimes called the Data Link Connector, or DLC).

Key points to remember about the OBD2 connector:

It’s usually located near the steering wheel, but it might be hidden behind a panel.
Pin 16 provides battery power, often even when the ignition is off, allowing OBD2 CAN bus scanners to operate.
The OBD2 pinout configuration depends on the communication protocol used by the vehicle.
CAN bus is the most common lower-layer protocol. This means pins 6 (CAN-High) and 14 (CAN-Low) are typically used for communication with OBD2 CAN bus scanners.

OBD2 Connector Types: A vs. B

You might encounter both Type A and Type B OBD2 connectors in practice. Type A is generally found in cars, while Type B is more common in medium and heavy-duty vehicles. Understanding the connector type is important for selecting the correct OBD2 CAN bus scanner adapter.

As shown in the illustration, both types have similar OBD2 pinouts but differ in power supply outputs (12V for Type A and 24V for Type B). Baud rates can also vary, with cars typically using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing). An OBD2 CAN bus scanner needs to be compatible with these different baud rates.

To distinguish between the connector types, Type B OBD2 connectors have an interrupted groove in the middle. A Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, while a Type A adapter will only fit Type A sockets. This is a crucial detail when choosing accessories for your OBD2 CAN bus scanner.

Image alt text: Diagram comparing OBD2 Connector Type A and Type B (SAE J1962), highlighting differences in voltage (12V vs 24V) and physical characteristics relevant to OBD2 CAN bus scanner compatibility in cars, vans, and trucks.

Image alt text: Graphic illustrating the relationship between OBD2 and CAN bus according to ISO 15765, emphasizing CAN bus as the communication layer for OBD2 and the role of OBD2 CAN bus scanners.

OBD2 and CAN Bus [ISO 15765-4]: The Communication Backbone

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, as per ISO 15765. This means that most OBD2 CAN bus scanners rely on this standard for communication.

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies a set of rules for using CAN for diagnostics (ISO 11898). It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers. Understanding these specifications is key to effectively using an OBD2 CAN bus scanner.

Key aspects of ISO 15765-4 for OBD2 CAN bus scanners:

CAN bus bit-rate must be either 250K or 500K.
CAN IDs can be 11-bit or 29-bit.
Specific CAN IDs are designated for OBD requests and responses.
Diagnostic CAN frame data length is fixed at 8 bytes.
The OBD2 adapter cable should not exceed 5 meters in length.

OBD2 CAN Identifiers (11-bit, 29-bit)

All OBD2 communication involves request/response message exchanges. OBD2 CAN bus scanners initiate requests and interpret responses.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, which is used to query all OBD2-compatible ECUs to see if they have data for the requested parameter (as defined in ISO 15765-4). ‘Physical Addressing’ requests, using CAN IDs 0x7E0-0x7E7, target specific ECUs, but are less commonly used with standard OBD2 CAN bus scanners.

ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most common response ID is 0x7E8 (Engine Control Module – ECM), followed by 0x7E9 (Transmission Control Module – TCM). An OBD2 CAN bus scanner typically listens for these response IDs.

In some vehicles, particularly vans and medium/heavy-duty vehicles, OBD2 communication might use extended 29-bit CAN identifiers instead of 11-bit IDs. Advanced OBD2 CAN bus scanners should be able to handle both.

Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Responses in 29-bit format use CAN IDs from 0x18DAF100 to 0x18DAF1FF (commonly 18DAF110 and 18DAF11E). The response ID is sometimes represented in ‘J1939 PGN’ form, specifically PGN 0xDA00 (55808), which is reserved for ISO 15765-2 in the J1939-71 standard. This is relevant for more specialized OBD2 CAN bus scanners used in commercial vehicles.

Image alt text: Diagram illustrating OBD2 protocol request and response frames, showing the flow of data between an OBD2 CAN bus scanner and a vehicle’s ECU, including PID data and parameters.

Image alt text: Graphic differentiating OBD2 CAN bus protocol from proprietary OEM-specific CAN bus protocols, highlighting that OBD2 CAN bus scanners primarily access standardized diagnostic data, not all vehicle CAN data.

OBD2 vs. Proprietary CAN Protocols: What an OBD2 CAN Bus Scanner Accesses

It’s important to understand that your vehicle’s Electronic Control Units (ECUs) function using proprietary CAN protocols developed by the Original Equipment Manufacturer (OEM), independent of OBD2. These OEM protocols are often vehicle brand, model, and year-specific. Without OEM documentation, this data is generally inaccessible (unless you undertake reverse engineering). Standard OBD2 CAN bus scanners are not designed to interpret this proprietary data.

If you connect a CAN bus data logger to your car’s OBD2 connector, you might observe OEM-specific CAN data, often broadcast at high rates (1000-2000 frames/second). However, many newer vehicles employ a ‘gateway’ that restricts access to this raw CAN data through the OBD2 port, allowing only OBD2 communication. Advanced OBD2 CAN bus scanners might offer features to bypass or analyze gateway restrictions, but this is not standard functionality.

In essence, think of OBD2 as a separate, standardized diagnostic protocol existing alongside the OEM’s proprietary communication network. An OBD2 CAN bus scanner specifically targets this standardized diagnostic layer.

Bit-Rate and ID Validation for OBD2 CAN Bus Scanners

As mentioned, OBD2 over CAN can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern cars commonly use 500K and 11-bit IDs, but robust OBD2 CAN bus scanners should automatically detect and adapt to these variations.

ISO 15765-4 provides a recommended initialization sequence to determine the correct combination. This process leverages the fact that OBD2-compliant vehicles must respond to a mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit-rates will cause CAN error frames. Advanced OBD2 CAN bus scanners often perform this validation automatically.

Newer versions of ISO 15765-4 consider that vehicles may support OBD communication via OBDonUDS instead of OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2). Future OBD2 CAN bus scanners might need to support both protocols.

To test for OBDonEDS vs. OBDonUDS, a sophisticated diagnostic tool might send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should have ECUs that respond to this DID.

Currently, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars, while WWH-OBD is mainly used in EU trucks/buses. Most standard OBD2 CAN bus scanners are designed for OBDonEDS.

Image alt text: Flowchart illustrating the OBD2 bit-rate and CAN ID validation process according to ISO 15765-4, showing how an OBD2 CAN bus scanner can determine the correct communication parameters.

Image alt text: Graphic showing the five lower-layer OBD2 protocols: CAN (ISO 15765), KWP2000, SAE J1850 (VPW & PWM), and ISO 9141, indicating the evolution of OBD2 communication and the dominance of CAN bus for modern OBD2 CAN bus scanners.

Five Lower-Layer OBD2 Protocols: Beyond CAN

While CAN is now dominant (ISO 15765), older vehicles might use other lower-layer protocols for OBD2. If you’re working with pre-2008 cars, understanding these alternatives is helpful. Pinouts on the OBD2 connector can sometimes indicate the protocol in use. While modern OBD2 CAN bus scanners primarily focus on CAN, some advanced tools might support these legacy protocols.

The five lower-layer OBD2 protocols include:

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and now the most common globally, making CAN-compatible OBD2 CAN bus scanners essential.
ISO 14230-4 (KWP2000): Keyword Protocol 2000, used in 2003+ cars, particularly in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian cars in the 2000-2004 period.
SAE J1850 (VPW): Primarily used in older GM vehicles.
SAE J1850 (PWM): Primarily used in older Ford vehicles.

Transporting OBD2 Messages via ISO-TP [ISO 15765-2]

All OBD2 data communication over CAN bus uses the ISO-TP (ISO 15765-2) transport protocol. This protocol enables the transmission of data payloads larger than 8 bytes, which is necessary for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. Advanced OBD2 CAN bus scanners and diagnostic software need to support ISO-TP to handle these multi-frame messages. For detailed information, refer to our introduction to UDS.

However, much OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF). The first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-related communication. Basic OBD2 CAN bus scanners often primarily deal with single-frame messages.

Image alt text: Diagram illustrating ISO-TP (ISO 15765-2) frame types for OBD2 communication, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame, essential for understanding multi-frame communication with OBD2 CAN bus scanners.

Decoding the OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]

To understand OBD2 communication on CAN bus, let’s examine a simplified ‘Single Frame’ OBD2 CAN message. An OBD2 message consists of a CAN identifier, a data length indicator (PCI field), and the data payload. The payload is further structured into Mode, Parameter ID (PID), and data bytes. OBD2 CAN bus scanners are designed to interpret this structure.

Image alt text: Breakdown of an OBD2 message structure, showing the CAN ID, PCI field (data length), Mode, PID, and data bytes, explaining how OBD2 CAN bus scanners interpret diagnostic data.

Example: OBD2 Request/Response with an OBD2 CAN Bus Scanner

Let’s consider a practical example: requesting ‘Vehicle Speed’. This demonstrates how an OBD2 CAN bus scanner interacts with a vehicle.

An external tool, like an OBD2 CAN bus scanner, sends a request message to the car with CAN ID 0x7DF and a 2-byte payload: Mode 0x01 and PID 0x0D. The car responds with CAN ID 0x7E8 and a 3-byte payload. The vehicle speed value is contained in the 4th byte, 0x32 (which is 50 in decimal).

By consulting the OBD2 PID specifications for PID 0x0D, we find that the physical value is 50 km/h. An OBD2 CAN bus scanner automates this lookup and decoding process.

Image alt text: Example of an OBD2 CAN bus communication trace showing a request (CAN ID 7DF) for Vehicle Speed (PID 0D) and the corresponding response (CAN ID 7E8) with the speed data.

Image alt text: Detailed example of OBD2 PID 0D (Vehicle Speed), illustrating the data bytes and how they are interpreted by an OBD2 CAN bus scanner to display vehicle speed in km/h.

Image alt text: Overview of the 10 OBD2 service modes (diagnostic services), including modes for current data, freeze frame data, and clearing DTCs, illustrating the range of diagnostic functions supported by OBD2 CAN bus scanners.

The 10 OBD2 Services (Modes) and Your OBD2 CAN Bus Scanner

There are 10 standardized OBD2 diagnostic services, also known as modes. Mode 0x01 is used to access current real-time data, while other modes are used to retrieve and clear Diagnostic Trouble Codes (DTCs) or access freeze-frame data. An OBD2 CAN bus scanner utilizes these modes to perform various diagnostic tasks.

Vehicles are not required to support all 10 OBD2 modes, and they may also support additional OEM-specific modes beyond the standard 10. Advanced OBD2 CAN bus scanners might offer access to these OEM-specific modes, but standard scanners typically focus on the standardized modes.

In OBD2 messages, the mode is located in the second byte of the data payload. In a request message, the mode is included directly (e.g., 0x01). In a response message, 0x40 is added to the mode value (e.g., resulting in 0x41 for a response to mode 0x01). OBD2 CAN bus scanners handle this mode encoding and decoding automatically.

OBD2 Parameter IDs (PIDs): Accessing Specific Data with Your OBD2 CAN Bus Scanner

Within each OBD2 mode, there are Parameter IDs (PIDs). PIDs are codes used to request specific pieces of information. An OBD2 CAN bus scanner uses PIDs to request data and then interprets the responses.

For instance, mode 0x01 contains approximately 200 standardized PIDs that provide real-time data on parameters like speed, RPM, and fuel level. However, a vehicle doesn’t have to support all PIDs within mode 0x01. In practice, most vehicles only support a subset of these PIDs. A good OBD2 CAN bus scanner will help you identify which PIDs are supported by your vehicle.

One PID stands out as particularly important:

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to PID 0x00, the ECU indicates its support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’ for OBD2 CAN bus scanners. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs.

Image alt text: Diagram illustrating OBD2 protocol request and response frames again, emphasizing the role of PIDs in requesting specific parameters and how OBD2 CAN bus scanners use PIDs to retrieve vehicle data.

Image alt text: Screenshot of an OBD2 PID overview tool, showing service 01 PIDs, useful for users of OBD2 CAN bus scanners to understand available parameters and construct requests.

Tip: Using an OBD2 PID Overview Tool with Your OBD2 CAN Bus Scanner

The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBD2 PIDs. This information is essential for converting raw data into meaningful physical values (as explained in our CAN bus introduction). Many OBD2 CAN bus scanners incorporate this decoding logic.

If you need to look up mode 0x01 PIDs, our OBD2 PID overview tool can be invaluable. It helps you construct OBD2 request frames and dynamically decode OBD2 responses, simplifying the use of your OBD2 CAN bus scanner.

OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD2 Data with an OBD2 CAN Bus Scanner

This section provides a practical example of how to log OBD2 data, which is a common application for OBD2 CAN bus scanners and loggers. While we use the CANedge data logger as an example, the principles apply to many OBD2 CAN bus scanners with logging capabilities.

The CANedge allows you to configure custom CAN frames for transmission, making it suitable for OBD2 logging and request/response interactions, similar to a more specialized OBD2 CAN bus scanner.

Once configured, the CANedge (or your OBD2 CAN bus scanner) can be easily connected to your vehicle using an OBD2-DB9 adapter cable.

Image alt text: Diagram illustrating an OBD2 PID data logger setup, showing the flow of request (7DF) and response (7E8) messages during data logging with an OBD2 CAN bus scanner or logger.

You can send a CAN frame at e.g. 500K, then check if it is successfully sent

The responses to ‘Supported PIDs’ can be reviewed in asammdf

Image alt text: Screenshot of an OBD2 PID lookup tool displaying decoded ‘Supported PIDs’ results, illustrating how to use such tools to interpret responses from an OBD2 CAN bus scanner and identify supported parameters.

Step #1: Testing Bit-rate, IDs, and Supported PIDs with Your OBD2 CAN Bus Scanner

As discussed, ISO 15765-4 outlines how to determine the correct bit-rate and CAN IDs for a specific vehicle. You can perform these tests using the CANedge or a similar OBD2 CAN bus scanner with configuration options:

Bit-rate Test: Attempt to send a CAN frame at 500K. Check for successful transmission (if unsuccessful, try 250K). Most OBD2 CAN bus scanners handle bit-rate auto-detection.
Bit-rate Confirmation: Use the identified bit-rate for all subsequent communication.
Supported PIDs Request: Send multiple ‘Supported PIDs’ requests (using PID 0x00 and related PIDs) and analyze the responses.
CAN ID Type Determination: Based on the response IDs (0x7E8 range for 11-bit, 0x18DAF1xx range for 29-bit), determine whether the vehicle uses 11-bit or 29-bit CAN IDs for OBD2. Again, many OBD2 CAN bus scanners automate this.
Supported PID Identification: Analyze the response data to identify the specific PIDs supported by the vehicle.

We provide plug-and-play configurations for CANedge to simplify these tests. Similar configurations may be available for other advanced OBD2 CAN bus scanners.

Most 2008+ non-EV cars support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

As shown in the asammdf GUI screenshot, multiple responses to a single OBD request are common when using the functional addressing ID (0x7DF). This is because the request polls all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, you’ll often see multiple responses to this PID. For subsequent ‘Supported PIDs’ requests, fewer ECUs typically respond. Notice that the ECM ECU (0x7E8) supports all PIDs supported by other ECUs in this example. This means you could reduce bus load by directing requests specifically to the ECM using ‘Physical Addressing’ CAN ID 0x7E0 for subsequent communication. Advanced OBD2 CAN bus scanners may offer options for both functional and physical addressing.

Step #2: Configuring OBD2 PID Requests in Your OBD2 CAN Bus Scanner

Once you know which OBD2 PIDs your vehicle supports and the correct communication parameters, you can configure your OBD2 CAN bus scanner or logger to request specific PIDs of interest.

Consider these points when configuring PID requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses to each request and reduce bus load, especially if you are primarily interested in data from the ECM. This is a feature offered by some advanced OBD2 CAN bus scanners.
Request Spacing: Introduce a delay of 300-500 ms between each OBD2 request. Overly rapid requests can overwhelm ECUs, causing them to stop responding. Many OBD2 CAN bus scanners have built-in pacing mechanisms.
Battery Drain Management: Use triggers or power-saving modes to stop transmitting requests when the vehicle is inactive to prevent battery drain. Some OBD2 CAN bus scanners offer ignition-based triggering.
Data Filtering: Implement filters to record only OBD2 responses, especially if your vehicle also outputs OEM-specific CAN data. This keeps your logs focused and manageable. Advanced OBD2 CAN bus scanners often have filtering capabilities.

After configuring these settings in your OBD2 CAN bus scanner, you are ready to log raw OBD2 data!

Image alt text: Example transmit list for an OBD2 CAN bus scanner or logger, showing configured OBD2 PID requests for various parameters, illustrating how to set up data logging.

Image alt text: Screenshot from asammdf software showing DBC decoded and visualized OBD2 data, demonstrating how raw OBD2 data logged by an OBD2 CAN bus scanner can be converted into meaningful plots and graphs.

Step #3: DBC Decoding of Raw OBD2 Data from Your OBD2 CAN Bus Scanner

To analyze and visualize your logged OBD2 data, you need to decode the raw data into ‘physical values’ (like km/h or °C). This decoding process is essential after logging data with an OBD2 CAN bus scanner.

The necessary decoding information is found in ISO 15031-5/SAE J1979 and online resources like Wikipedia. For convenience, we provide a free OBD2 DBC file. This DBC file simplifies DBC decoding of raw OBD2 data in most CAN bus software tools, making your OBD2 CAN bus scanner data easily understandable.

Decoding OBD2 data is slightly more complex than decoding regular CAN signals. This is because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is not sufficient to identify the signals within the payload.

To address this, you need to use the CAN ID, OBD2 mode, and OBD2 PID to uniquely identify each signal. This is a form of multiplexing called ‘extended multiplexing‘, which can be implemented in DBC files. Using a proper DBC file is crucial for accurately interpreting data from your OBD2 CAN bus scanner.

CANedge: An Example OBD2 Data Logger

The CANedge is a powerful example of a tool that lets you easily record OBD2 data to an SD card (8-32 GB). Simply connect it to your vehicle to start logging. You can then decode the data using free software/APIs and our OBD2 DBC file. While CANedge is a logger, many advanced OBD2 CAN bus scanners offer similar logging and data export features.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples [ISO-TP]: Handling Larger Data with Your OBD2 CAN Bus Scanner

All OBD2 data communication relies on the ISO-TP transport protocol (ISO 15765-2). Most examples so far have focused on single-frame communication. This section provides examples of multi-frame communication, which are handled by more advanced OBD2 CAN bus scanners and diagnostic tools.

Multi-frame OBD2 communication requires flow control frames (see our UDS introduction). In practice, you can often achieve this by transmitting a static flow control frame approximately 50 ms after the initial request frame, as illustrated in the CANedge configuration example. Sophisticated OBD2 CAN bus scanners often manage flow control automatically.

Furthermore, processing multi-frame OBD2 responses requires CAN software and API tools that support ISO-TP, such as the CANedge MF4 decoders. When choosing an OBD2 CAN bus scanner, ensure it and its accompanying software can handle multi-frame messages.

Image alt text: Example of an OBD2 multi-frame request message for Vehicle Identification Number (VIN), demonstrating the structure of requests handled by advanced OBD2 CAN bus scanners for larger data retrievals.

Example 1: Retrieving the Vehicle Identification Number (VIN) via OBD2 CAN Bus Scanner

The Vehicle Identification Number (VIN) is important for telematics, diagnostics, and more (see our UDS introduction for details). To retrieve the VIN using OBD2 requests with an OBD2 CAN bus scanner, you use mode 0x09 and PID 0x02:

The OBD2 CAN bus scanner sends a Single Frame request with the PCI field (0x02), request service identifier (0x09), and PID (0x02).

The vehicle responds with a First Frame containing the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is byte 0x01, the Number Of Data Items (NODI), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for details). The remaining 17 bytes represent the VIN and can be converted from HEX to ASCII, as discussed in our UDS introduction. An OBD2 CAN bus scanner typically automates this entire VIN retrieval and decoding process.

Example 2: OBD2 Multi-PID Request (6x) and Advanced OBD2 CAN Bus Scanners

External tools, including advanced OBD2 CAN bus scanners, are permitted to request up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU will respond with data for the supported PIDs (omitting unsupported ones), potentially using multiple frames as per ISO-TP.

This feature allows for more efficient data collection at higher frequencies. However, the signal encoding becomes specific to the request method, making generic OBD2 DBC files less useful. While technically possible, this multi-PID request method is not generally recommended for practical data logging, especially with basic OBD2 CAN bus scanners.

Below is an example trace of a multi-PID request and response:

The multi-frame response is similar to the VIN example, but the payload includes both the requested PIDs and their corresponding data. The PIDs in the example are ordered similarly to the request order, which is common but not strictly required by ISO 15031-5.

Decoding these multi-PID responses using generic DBC files is very challenging. Therefore, we don’t recommend this approach for general data logging unless you’re using tools specifically designed for it. You would be dealing with extended multiplexing, but with multiple instances throughout the payload. Creating a DBC file to handle this across various vehicles with different supported PIDs is extremely difficult to generalize.

While custom scripts and recording transmit messages could provide a workaround, these methods are complex to scale. Generally, for most OBD2 CAN bus scanner users, sticking to single-PID requests is more practical.

Example 3: Retrieving OBD2 Diagnostic Trouble Codes (DTCs) with an OBD2 CAN Bus Scanner

You can use OBD2 mode 0x03 (‘Show stored Diagnostic Trouble Codes’) to request emissions-related DTCs. No PID is included in the request. The targeted ECU(s) will respond with the number of stored DTCs (which could be zero) and the DTCs themselves, each DTC being 2 bytes. Multi-frame responses are necessary when more than two DTCs are stored. OBD2 CAN bus scanners are specifically designed to retrieve and interpret DTCs.

The 2-byte DTC value is structured according to ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’, and the remaining 14 bits form a 4-digit hexadecimal code. You can look up decoded DTC values using OBD2 DTC lookup tools like repairpal.com, or directly within many OBD2 CAN bus scanners.

The example below shows a request to an ECU with 6 stored DTCs.

Image alt text: Example of OBD2 DTC (Diagnostic Trouble Code) decoding and DBC interpretation, explaining how an OBD2 CAN bus scanner translates raw DTC data into human-readable fault codes.

Real-World Applications: OBD2 Data Logging Use Cases with OBD2 CAN Bus Scanners

OBD2 data from cars and light trucks has a wide range of applications. OBD2 CAN bus scanners and loggers are essential tools for these use cases.

Vehicle Data Logging for Cars

OBD2 data logging in cars can be used for fuel efficiency optimization, driving behavior improvement, prototype part testing, and insurance telematics. OBD2 CAN bus scanners with logging capabilities are ideal for these applications.

OBD2 logger

Real-time Car Diagnostics

OBD2 interfaces and OBD2 CAN bus scanners can stream human-readable OBD2 data in real-time for diagnosing vehicle issues.

OBD2 streaming

Predictive Maintenance

Cars and light trucks can be monitored via IoT-connected OBD2 CAN bus loggers in the cloud to predict and prevent breakdowns.

predictive maintenance

Vehicle ‘Black Box’ Logging

An OBD2 CAN bus logger can act as a ‘black box’ for vehicles or equipment, providing valuable data for incident analysis, warranty claims, and diagnostics.

can bus blackbox

Do you have an OBD2 data logging application in mind? Contact us for free expert advice!

For more introductory guides, visit our guides section or download the ‘Ultimate Guide’ PDF.

Need to log or stream OBD2 data?

Get your OBD2 data logger or CAN bus scanner today!

Buy now
Contact us

Recommended Resources

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN