OBD2 Explained: Your Comprehensive Guide to On-Board Diagnostics [2025 Updated]

Looking for a straightforward and practical explanation of OBD2?

This guide provides a comprehensive introduction to the On-Board Diagnostics 2 (OBD2) protocol. We’ll cover everything from the OBD2 connector and OBD2 parameter IDs (PIDs) to its link with the CAN bus system.

This is a hands-on introduction, designed to equip you with the knowledge to request and interpret OBD2 data. You’ll also discover key applications and practical tips for utilizing OBD2 in real-world scenarios.

Discover why this guide has become a leading resource for understanding OBD2.

You can also watch our OBD2 introductory video above – or download this guide as a PDF

Article Contents:

Author: Martin Falch (Updated January 2025)

Download as PDF

What Exactly is OBD2?

OBD2, or On-Board Diagnostics 2, is essentially your car’s internal health monitoring system. It’s a standardized protocol that enables access to diagnostic trouble codes (DTCs) and real-time vehicle data through the OBD2 port.

You’ve likely already encountered OBD2 in action:

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 utilize an OBD2 scanner to pinpoint the problem.

The mechanic connects the OBD2 reader to the 16-pin OBD2 connector, typically located near the steering wheel. This tool transmits ‘OBD2 requests’ to the vehicle, and the car responds with ‘OBD2 responses’. These responses can contain vital information such as speed, fuel level, and Diagnostic Trouble Codes (DTCs), which are crucial for efficient troubleshooting.

Understanding OBD2: On-Board Diagnostics and the Malfunction Indicator Light (MIL).

Is My Vehicle OBD2 Compliant?

Likely, yes!

The vast majority of modern non-electric vehicles are equipped with OBD2 and often operate on the CAN bus network. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t guarantee OBD2 support. This resource can help you determine compliance. A key indicator is the vehicle’s manufacturing origin and year:

OBD2 Compliance Guide: Check if your car is OBD2 compliant based on region and year.

A Look at OBD2 History

OBD2 has its roots in California, where the California Air Resources Board (CARB) mandated OBD for all new vehicles starting in 1991 for emissions monitoring.

The Society of Automotive Engineers (SAE) further developed the standard, leading to standardized DTCs and the OBD connector, detailed in SAE J1962.

The OBD2 standard was progressively implemented:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: Required in the EU for gasoline vehicles.
2003: Extended to diesel vehicles in the EU (EOBD).
2005: OBD2 mandated in the US for medium-duty vehicles.
2008: US vehicles required to use ISO 15765-4 (CAN) as the OBD2 foundation.
2010: OBD2 became mandatory for heavy-duty vehicles in the US.

OBD2 Timeline: From Emission Control to Modern Vehicle Diagnostics.

Visual Timeline of OBD2 History and Evolution.

The Future of OBD: OBD3, Remote Diagnostics, and IoT Integration.

The Future Trajectory of OBD2

OBD2 is firmly established, but its evolution continues. Let’s examine key trends shaping its future:

Originally designed for emissions control, regulatory OBD2 requirements don’t extend to electric vehicles. Consequently, most modern EVs do not support standard OBD2 requests. Instead, they often utilize OEM-specific UDS communication, making data retrieval challenging without reverse engineering. However, successful reverse engineering efforts have been documented in case studies for electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Acknowledging OBD2’s limitations in data richness and lower-layer protocols, modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These aim to optimize OBD communication by using the UDS protocol as a foundation. For a deeper understanding of these protocols, refer to our introduction to UDS.

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

The proposed solution is OBD3: integrating telematics into all vehicles.

OBD3 envisions adding a small radio transponder to every car, similar to those used for toll collection. This would allow the car’s vehicle identification number (VIN) and DTCs to be transmitted wirelessly to a central server for automated checks.

Many current devices, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger, already facilitate CAN or OBD2 data transfer via WiFi/cellular networks.

While offering convenience and cost savings, OBD3 raises privacy concerns and presents political challenges related to surveillance.

While OBD2 was initially intended for stationary emission testing, it’s now widely used by third parties to access real-time vehicle data via OBD2 dongles, CAN loggers, and similar devices. However, the German automotive industry is considering limiting this access:

“OBD has been designed to service cars in repair shops. In no way has it been intended to allow third parties to build a form of data-driven economy on the access through this interface“

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal suggests disabling OBD2 functionality during driving, centralizing data collection within manufacturer servers. This would give manufacturers control over the burgeoning field of ‘automotive big data’.

Security concerns, such as mitigating car hacking risks, are cited as justification. However, many perceive this as a commercially motivated move. The long-term impact on the market for third-party OBD2 services remains uncertain.

Future of OBD2 Data Access: Potential Restrictions and Electric Vehicle Trends.

Enhance Your CAN Bus Expertise

Want to become a CAN bus expert?

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

Download Now

Decoding OBD2 Standards

On-board diagnostics, OBD2, operates as a higher-layer protocol, acting as a language. CAN, in contrast, is the communication method, akin to a telephone line. This places OBD2 in a similar category to other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

Specifically, OBD2 standards define the OBD2 connector, lower-layer protocols, OBD2 parameter IDs (PIDs), and more.

These standards can be visualized within a 7-layer OSI model. The following sections will delve into the most critical aspects.

In the OSI model, you’ll notice that both SAE and ISO standards cover several layers. This reflects the standardization efforts for OBD in the US (SAE) and EU (ISO). Many standards are technically very similar, for instance, SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3.

OBD2 and CAN Bus in the OSI Model: Understanding the 7-Layer Structure.

OBD2 Connector Pinout: Type A Socket (Female) Data Link Connector (DLC).

The OBD2 Connector [SAE J1962 Standard]

The 16-pin OBD2 connector, standardized under SAE J1962 / ISO 15031-3, provides easy access to your vehicle’s data. It’s also known as the Data Link Connector (DLC).

The illustration shows a typical Type A OBD2 pin connector.

Key points about the OBD2 connector:

It’s usually located near the steering wheel, but can sometimes be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout varies depending on the communication protocol.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are commonly used.

OBD2 Connector Types: A vs. B

In practice, you might encounter both Type A and Type B OBD2 connectors. Type A is typically found in cars, while Type B is more common in medium and heavy-duty vehicles.

While both types share similar OBD2 pinouts, they differ in power supply: 12V for Type A and 24V for Type B. Baud rates can also vary, with cars often using 500K and heavy-duty vehicles typically using 250K (though 500K support is increasing).

Visually distinguishing them, the Type B OBD2 connector has a split groove in the center. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and B sockets, whereas a Type A adapter will not fit into a Type B socket.

OBD2 Connector Types: Type A vs. Type B – Differences and Applications.

OBD2 and CAN Bus: Interrelation based on ISO 15765 Standard.

OBD2 and CAN Bus Integration [ISO 15765-4]

Since 2008, CAN bus has been the mandated lower-layer protocol for OBD2 in all US-sold vehicles, as per ISO 15765.

ISO 15765-4 (Diagnostics over CAN or DoCAN) specifies constraints applied to the CAN standard (ISO 11898).

It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:

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/responses.
Diagnostic CAN frame data length is fixed at 8 bytes.
OBD2 adapter cable length is limited to 5 meters maximum.

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

All OBD2 communication is based on request/response message exchanges.

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 for data related to the requested parameter (ISO 15765-4). ‘Physical Addressing’ requests to specific ECUs can be made using CAN IDs 0x7E0-0x7E7, though this is less common.

ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most frequent response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module).

Some vehicles, particularly vans and light/medium/heavy-duty vehicles, may utilize extended 29-bit CAN identifiers for OBD2 communication instead of 11-bit.

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

Responses are typically seen with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (often 18DAF110 and 18DAF11E). The response ID is sometimes presented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is marked as ‘Reserved for ISO 15765-2’ in the J1939-71 standard.

OBD2 Request and Response Frames: Illustrating PID Data Parameters.

OBD2 vs. Proprietary CAN Bus Protocols: Data Access and Differences.

OBD2 vs. OEM Proprietary CAN Protocols

It’s important to understand that your vehicle’s electronic control units (ECUs) do not depend on OBD2 for their core functionality. Each original equipment manufacturer (OEM) implements its own proprietary CAN protocols for vehicle operations. These protocols are often unique to the vehicle brand, model, and year. Accessing and interpreting this OEM-specific data usually requires reverse engineering unless you are the OEM.

If you connect a CAN bus data logger to your vehicle’s OBD2 connector, you might observe OEM-specific CAN data, typically broadcast at high rates (1000-2000 frames/second). However, in many newer vehicles, a ‘gateway’ module restricts access to this CAN data through the OBD2 port, allowing only OBD2 communication.

In essence, think of OBD2 as a supplementary higher-layer protocol operating alongside the OEM-specific protocol.

Bit-rate and ID Validation Process

As mentioned, OBD2 can utilize two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern vehicles commonly use 500K with 11-bit IDs. External tools should systematically verify the correct combination.

ISO 15765-4 provides guidelines for an initialization sequence to determine the appropriate combination, illustrated in the flowchart. This method relies on the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see OBD2 PID section) and the fact that incorrect bit-rate transmissions will cause CAN error frames.

Newer ISO 15765-4 versions acknowledge that vehicles might 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).

To differentiate between OBDonEDS and OBDonUDS, diagnostic tools may send additional UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS must have ECUs that respond to this DID.

In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars today, while WWH-OBD is mainly used in EU trucks and buses.

OBD2 Bit-rate and CAN ID Validation Flowchart based on ISO 15765-4.

OBD2 Lower-Layer Protocols: CAN (ISO 15765), KWP2000, SAE J1850, ISO 9141.

Five Lower-Layer OBD2 Protocols

CAN is currently the dominant lower-layer protocol for OBD2 as per ISO 15765.

However, when working with older vehicles (pre-2008), knowing the other four lower-layer protocols used for OBD2 can be helpful. The pinouts can also help identify the protocol used in your vehicle.

ISO 15765 (CAN bus): Mandatory in US cars from 2008 onwards and widely used today.
ISO14230-4 (KWP2000): Keyword Protocol 2000, commonly used in 2003+ vehicles, particularly in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian vehicles in the 2000-2004 period.
SAE J1850 (VPW): Predominantly used in older GM vehicles.
SAE J1850 (PWM): Mostly used in older Ford vehicles.

ISO-TP for OBD2 Message Transport [ISO 15765-2]

All OBD2 data communication over CAN bus relies on the ISO-TP transport protocol (ISO 15765-2). This protocol enables the transmission of data payloads exceeding 8 bytes, which is essential for OBD2 operations 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. More details can be found in our UDS introduction.

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

ISO-TP Frame Types for OBD2 Communication: Single Frame, First Frame, Consecutive Frame, Flow Control Frame.

The OBD2 Diagnostic Message Structure [SAE J1979, ISO 15031-5]

To better understand OBD2 communication over CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message consists of an identifier, a data length indicator (PCI field), and the data itself. The data is further structured into Mode, parameter ID (PID), and data bytes.

OBD2 Message Structure: Breakdown of Mode, PID, and Data Bytes.

Example: OBD2 Request/Response Cycle

Consider this request/response example for the ‘Vehicle Speed’ parameter.

An external tool sends a request message to the vehicle with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds using CAN ID 0x7E8 with 3 payload bytes, including the Vehicle Speed value in the 4th byte, 0x32 (decimal 50).

Referring to the OBD2 PID 0x0D decoding rules, we determine that the physical value is 50 km/h.

Next, we’ll explore OBD2 modes and PIDs in more detail.

OBD2 Request and Response Example: CAN IDs 7DF and 7E8 for Vehicle Speed.

OBD2 PID Example: Vehicle Speed Parameter ID 0D.

OBD2 Services (Modes): Current Data, Freeze Frame, Clear DTCs, and more.

The 10 OBD2 Services (Modes)

OBD2 defines 10 diagnostic services, also known as modes. Mode 0x01 provides real-time data, while others are used for viewing and clearing diagnostic trouble codes (DTCs) or accessing freeze frame data.

Vehicles are not required to support all OBD2 modes and may implement additional OEM-specific modes beyond the 10 standard modes.

In OBD2 messages, the mode is located in the second byte. In a request, the mode is included directly (e.g., 0x01). In a response, 0x40 is added to the mode value (e.g., resulting in 0x41).

OBD2 Parameter IDs (PIDs)

Each OBD2 mode contains parameter IDs (PIDs).

For instance, mode 0x01 includes approximately 200 standardized PIDs providing real-time data such as speed, RPM, and fuel level. However, vehicles typically support only a subset of the available PIDs within a mode.

One PID is particularly significant:

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

OBD2 Request and Response Frames: Detailing PID Data Parameters.

OBD2 PID Overview Tool: Service 01 PID Lookup and Decoding.

Practical Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBD2 PIDs, enabling you to convert raw data into physical values (as explained in our CAN bus introduction).

For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool is a valuable resource. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

Logging and Decoding OBD2 Data: A Practical Guide

This section provides a practical example of logging OBD2 data using the CANedge CAN bus data logger.

The CANedge allows custom CAN frame transmission, making it suitable for OBD2 logging.

Once configured, the CANedge can be easily connected to your vehicle using our OBD2-DB9 adapter cable.

OBD2 Data Logger Setup: Requesting PIDs 7df and 7e8.

Testing OBD2 Bit Rate: Verify successful CAN frame transmission.
Analyzing Supported PIDs: Review responses in asammdf.

Step #1: Validate Bit-rate, IDs & Supported PIDs

As discussed, ISO 15765-4 outlines how to determine the correct bit-rate and IDs for a specific vehicle. You can use the CANedge to test this, as described below (refer to the CANedge Introduction for detailed instructions):

Transmit a CAN frame at 500K and confirm successful transmission (if unsuccessful, try 250K).
Use the identified bit-rate for subsequent communication.
Send multiple ‘Supported PIDs’ requests and examine the responses.
Determine 11-bit or 29-bit IDs based on response IDs.
Identify supported PIDs from the response data.

We offer plug-and-play configurations to facilitate these tests.

Most post-2008 non-EV vehicles 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. This is because the 0x7DF request ID polls all ECUs for responses. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are typical. For subsequent ‘Supported PIDs’ requests, fewer ECUs tend to respond. Notably, the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs in this example. Bus load can be reduced by directing subsequent communication specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configure OBD2 PID Requests

Once you know your vehicle’s supported OBD2 PIDs, bit-rate, and CAN IDs, you can configure your transmit list with relevant PIDs.

Consider these factors:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses per request.
Spacing: Introduce 300-500 ms intervals between OBD2 requests to avoid overwhelming ECUs.
Battery Drain: Implement triggers to halt transmission when the vehicle is inactive to prevent ECU ‘wake-up’ and battery drain.
Filters: Apply filters to record only OBD2 responses if OEM-specific CAN data is also present.

With configuration complete, your device is ready to log raw OBD2 data!

Example CANedge OBD2 PID Request List Configuration.

Visualizing Decoded OBD2 Data: Plotting in asammdf using a CAN bus DBC file.

Step #3: DBC Decode Raw OBD2 Data

To analyze and visualize your logged data, you need to decode the raw OBD2 data into ‘physical values’ (e.g., km/h or °C).

Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. For convenience, we provide a free OBD2 DBC file to facilitate DBC decoding of raw OBD2 data in most CAN bus software tools.

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

To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID together to uniquely identify the signal. This multiplexing technique, known as ‘extended multiplexing‘, can be implemented in formats like DBC files.

CANedge: Your OBD2 Data Logging Solution

The CANedge simplifies OBD2 data recording to an 8-32 GB SD card. Connect it to your vehicle to start logging and decode the data using free software/APIs and our OBD2 DBC.

OBD2 logger intro
CANedge Product Details

OBD2 Multi-Frame Examples [ISO-TP]

While most examples have focused on single-frame communication, OBD2 also utilizes multi-frame communication via the ISO-TP transport protocol (ISO 15765-2). Multi-frame communication requires flow control frames (see our UDS introduction). In practice, a static flow control frame can be transmitted approximately 50 ms after the initial request frame, as shown in the CANedge configuration example.

Analyzing multi-frame OBD2 responses requires CAN software/API tools that support ISO-TP, such as the CANedge MF4 decoders.

OBD2 Multi-Frame Request Example: Vehicle Identification Number (VIN) Retrieval.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more (see our UDS introduction). To retrieve the VIN using OBD2, use mode 0x09 and PID 0x02:

The testing tool 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, representing the Number Of Data Items (NODI), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes constitute the VIN, convertible from HEX to ASCII as described in our UDS introduction.

Example 2: OBD2 Multi-PID Request (6x)

External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU responds with data for supported PIDs (omitting unsupported ones), potentially across multiple frames via ISO-TP.

This efficient method allows higher-frequency data collection. However, the signal encoding becomes specific to your request method, complicating the use of generic OBD2 DBC files. This approach is generally not recommended for practical use. Here’s an example trace:

The multi-frame response resembles 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 mandated by ISO 15031-5.

Decoding this response using generic DBC files is challenging. It’s generally not recommended for practical data logging unless you’re using a tool specifically designed for this. This scenario represents extended multiplexing, but with multiple instances within the payload. Your DBC file would need to account for each PID’s specific payload position, making it difficult to generalize across vehicles with varying supported PIDs. Furthermore, managing this via DBC manipulations becomes very complex if you send multiple multi-PID requests, as uniquely identifying messages from each other becomes problematic.

Workarounds could involve custom scripts and recording transmit messages from your testing tool. The script could then interpret response messages in conjunction with request messages. However, such approaches are generally difficult to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

OBD2 can retrieve emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03 (‘Show stored Diagnostic Trouble Codes’). No PID is included in the request. Responding ECUs will indicate the number of stored DTCs (possibly zero), with each DTC occupying 2 data bytes. Multi-frame responses are necessary if more than 2 DTCs are stored.

The 2-byte DTC value is typically 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, as visualized. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.

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

OBD2 DTC Decoding: Interpreting Diagnostic Trouble Codes.

OBD2 Data Logging: Use Case Applications

OBD2 data from cars and light trucks has diverse applications:

Car Data Logging

OBD2 data logging in cars can be utilized for fuel efficiency improvement, driving behavior analysis, prototype testing, and insurance applications.

OBD2 Logger Solutions

Real-Time Vehicle Diagnostics

OBD2 interfaces facilitate real-time streaming of human-readable vehicle data, aiding in diagnosing vehicle issues.

OBD2 Streaming Interfaces

Predictive Maintenance

IoT-enabled OBD2 loggers enable remote vehicle monitoring in the cloud for predictive maintenance, helping prevent breakdowns.

Predictive Maintenance Solutions

Vehicle Black Box Logging

An OBD2 logger can function as a vehicle ‘black box’ for incident data recording, useful for disputes or detailed diagnostics.

CAN Bus Black Box Loggers

Do you have an OBD2 data logging application? Contact us for a free consultation!

Explore our guides section for more introductory resources or download the ‘Ultimate Guide’ PDF.

Need to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy Now
Contact Us