Need a straightforward and expert introduction to the Iso Obd2 Protocol?
This guide provides an in-depth look at the ISO On-Board Diagnostics 2 (OBD2) protocol, including the OBD2 connector, OBD2 Parameter IDs (PIDs), and its connection to the CAN bus system.
Note: This is designed as an expert-level guide offering practical insights. You’ll learn how to effectively request and interpret OBD2 data, explore crucial logging applications, and gain valuable practical tips for implementation and troubleshooting.
Discover why this is rapidly becoming the go-to resource for mastering the ISO OBD2 protocol.
You can also watch our OBD2 intro video above – or download the PDF guide
Article Contents
Author: Martin Falch (Updated January 2025)
Download as PDF
Understanding the Basics of OBD2 and the ISO OBD2 Protocol
OBD2, or On-Board Diagnostics 2, is essentially your vehicle’s integrated self-diagnostic system. It’s based on a standardized protocol—the ISO OBD2 protocol—that enables the extraction of Diagnostic Trouble Codes (DTCs) and real-time operational data through the OBD2 connector.
You’ve likely already encountered OBD2 in action:
Have you ever seen the malfunction indicator light, commonly known as the check engine light, illuminate on your dashboard?
That light is your vehicle signaling a problem. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the issue.
To do this, the mechanic connects an OBD2 reader to the OBD2 16-pin connector, typically located near the steering wheel. This tool sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses.’ These responses can contain critical information like speed, fuel level, and Diagnostic Trouble Codes (DTCs), significantly speeding up the diagnostic and repair process.
OBD2 Compatibility: Is Your Car Equipped with the ISO OBD2 Protocol?
In most cases: Yes, probably!
The vast majority of modern, non-electric vehicles are equipped with OBD2 systems, and many operate on the CAN bus network. For older vehicles, it’s important to note that the presence of a 16-pin OBD2 connector doesn’t guarantee OBD2 support. In fact, it might not support OBD2 at all. A reliable way to check for compliance is to consider the vehicle’s purchase location and date:
A Brief History of the ISO OBD2 Protocol
The ISO OBD2 protocol has its roots in California. The California Air Resources Board (CARB) mandated OBD in all new vehicles starting from 1991 for emissions monitoring.
The Society of Automotive Engineers (SAE) further developed the OBD2 standard, leading to standardized DTCs and the universal OBD connector (SAE J1962). This standardization was crucial for interoperability across different vehicle manufacturers.
The implementation of the ISO OBD2 protocol was phased in globally:
- 1996: OBD2 became mandatory in the USA for all cars and light trucks.
- 2001: The EU required OBD2 for gasoline cars.
- 2003: The EU extended the requirement to diesel cars (EOBD – European On-Board Diagnostics).
- 2005: OBD2 was mandated in the US for medium-duty vehicles.
- 2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
- 2010: OBD2 became mandatory for heavy-duty vehicles in the US.
The Future Landscape of the ISO OBD2 Protocol
While the ISO OBD2 protocol remains relevant, its future is evolving.
Here are key trends to consider:
Initially, legislated OBD2 was primarily for emissions control and testing. Consequently, electric vehicles (EVs) aren’t obligated to support OBD2 in any form. This is evident as most modern EVs largely bypass standard OBD2 requests, opting instead for OEM-specific UDS (Unified Diagnostic Services) communication. This often makes data retrieval from EVs challenging, except when decoding methods are reverse-engineered. Examples include our case studies on electric vehicles such as Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.
Today, the ISO OBD2 protocol is implemented in diverse ways but faces limitations in data richness and lower-layer protocol options. To address these, advanced alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These aim to enhance OBD communication by using the UDS protocol as a base. For a deeper understanding, refer to our introduction to UDS.
In our increasingly connected world, traditional OBD2 testing methods can seem inefficient. Manual emission checks are time-consuming and costly.
The solution being explored is OBD3: integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder to all cars, 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.
Many current devices already facilitate CAN or OBD2 data transfer via WiFi/cellular networks, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.
While this offers cost savings and convenience, it also raises political and privacy concerns related to surveillance.
The ISO OBD2 protocol was originally intended for stationary emissions testing.
However, today, third parties widely use OBD2 to generate real-time vehicle data through OBD2 dongles, CAN loggers, and more. Interestingly, the German car industry is pushing for changes that could restrict this access:
OBD was designed for car servicing in repair shops. “It was never intended to allow third parties to build a data-driven economy based on access through this interface.“
– Christoph Grote, SVP Electronics, BMW (2017)
The proposal is to disable OBD2 functionality during driving and instead centralize data collection with manufacturers. This would essentially put car manufacturers in control of the burgeoning ‘automotive big data’.
The rationale often cited is security, aiming to reduce the risk of car hacking. However, many perceive this as a commercially motivated move (https://www.navixy.com/blog/obd-trackers-what-future-awaits/). Whether this trend will solidify remains to be seen, but it could significantly disrupt the market for third-party OBD2 services.
Enhance Your Expertise with our ‘Ultimate CAN Guide’
Ready to become a CAN bus expert?
Access our 12 ‘simple introductions’ in one comprehensive 160+ page PDF:
Download now
Delving into ISO OBD2 Protocol Standards
On-board diagnostics, OBD2, functions as a higher-layer protocol, much like a language. In contrast, CAN bus is the communication method, similar to a phone line. This positions OBD2 alongside other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.
Specifically, the ISO OBD2 protocol standards define the OBD2 connector, lower-layer protocols, OBD2 Parameter IDs (PIDs), and more.
These standards can be mapped to the 7-layer OSI model. In the following sections, we will focus on the most critical aspects.
In the OSI model overview, you’ll notice that both SAE and ISO standards cover multiple layers. This reflects the standardization efforts for OBD in the USA (SAE) and the EU (ISO). Many standards are technically very similar, for example, SAE J1979 compared to ISO 15031-5, and SAE J1962 versus ISO 15031-3.
The OBD2 Connector: SAE J1962 and ISO 15031-3 Standards
The 16-pin OBD2 connector is your gateway to accessing vehicle data. It is meticulously defined in the SAE J1962 / ISO 15031-3 standards.
The illustration above shows a Type A OBD2 pin connector, also known as a Data Link Connector (DLC).
Key features of the OBD2 connector include:
- Location: Typically found near the steering wheel, although it might be concealed.
- Pin 16: Supplies battery power, often even when the ignition is off.
- Pinout Variability: The OBD2 pinout configuration depends on the communication protocol used.
- Common Protocol: CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are commonly active.
OBD2 Connector Types: A vs. B – SAE J1962 Differences
In practical applications, you may encounter both Type A and Type B OBD2 connectors. Type A is generally used in cars, while Type B is more common in medium and heavy-duty vehicles.
As depicted 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, while heavy-duty vehicles often use 250K (with increasing support for 500K more recently).
Visually distinguishing them is straightforward: the Type B OBD2 connector has a central interrupted groove. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, while a Type A adapter will not fit into a Type B socket.
OBD2 and CAN Bus: ISO 15765-4 Protocol Deep Dive
Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, as mandated by ISO 15765. This standard, ISO 15765-4, is a cornerstone of the ISO OBD2 protocol.
ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies a set of constraints and guidelines for using the CAN standard (ISO 11898) in diagnostic applications.
It standardizes the CAN interface for diagnostic test equipment, focusing on the physical, data link, and network layers:
- CAN Bit-rate: Must be either 250K or 500K.
- CAN IDs: Can be 11-bit or 29-bit.
- Specific CAN IDs: Reserved for OBD request/response messaging.
- Data Frame Length: Diagnostic CAN frames must be 8 bytes in length.
- Adapter Cable Length: OBD2 adapter cables are limited to a maximum of 5 meters.
OBD2 CAN Identifiers: 11-bit and 29-bit Formats
All OBD2 communication operates on a request/response model.
In most passenger vehicles, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, used to query all OBD2-compatible ECUs (Electronic Control Units) for data related to the requested parameter, as per ISO 15765-4. ‘Physical Addressing’ requests, using CAN IDs from 0x7E0 to 0x7E7, can target specific ECUs but are less frequently used.
ECUs respond using 11-bit IDs ranging from 0x7E8 to 0x7EF. The most common response ID is 0x7E8 (ECM – Engine Control Module), followed by 0x7E9 (TCM – Transmission Control Module).
In some vehicle types, particularly vans and medium to heavy-duty vehicles, you may find that OBD2 communication uses extended 29-bit CAN identifiers instead of the standard 11-bit IDs.
For 29-bit identifiers, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
Responses in 29-bit format are typically seen with CAN IDs from 0x18DAF100 to 0x18DAF1FF (commonly 18DAF110 and 18DAF11E). The response ID is also sometimes represented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is designated as ‘Reserved for ISO 15765-2’ in the J1939-71 standard.
OBD2 vs. Proprietary CAN Protocols: Understanding the Difference
It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) operate using OEM (Original Equipment Manufacturer)-specific proprietary CAN protocols, independent of OBD2. These proprietary CAN protocols are unique to each vehicle brand, model, and year. Without OEM documentation or reverse engineering, interpreting this data is generally not possible (reverse engineering techniques).
When 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 raw CAN data, allowing only standardized ISO OBD2 protocol communication through the OBD2 port.
In essence, think of OBD2 as an additional, standardized higher-layer protocol operating in parallel with the OEM-specific protocol.
Bit-rate and ID Validation for ISO OBD2 Protocol
As previously mentioned, the ISO OBD2 protocol can utilize two bit rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in 4 potential protocol combinations. Modern vehicles most commonly use 500K with 11-bit IDs. Diagnostic tools should systematically verify these parameters.
ISO 15765-4 provides a recommended initialization sequence to determine the correct protocol combination. This process leverages the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (refer to the OBD2 PID section for details). Incorrect bit-rate transmission will result in CAN error frames, aiding in bit-rate identification.
Newer versions of ISO 15765-4 account for vehicles supporting OBD communication via OBDonUDS (OBD on Unified Diagnostic Services) rather than OBDonEDS (OBD on Emission Diagnostic Service). This article primarily focuses on OBD2/OBDonEDS (as per ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (as per ISO 14229, ISO 27145-3/SAE J1979-2).
To differentiate between OBDonEDS and OBDonUDS, diagnostic tools can 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 should 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.
Five Lower-Layer Protocols of the ISO OBD2 Protocol
While CAN bus (ISO 15765) is now the dominant lower-layer protocol for OBD2, particularly in vehicles manufactured post-2008, it’s beneficial to know the four other protocols used in older vehicles. The pinouts can help identify which protocol your vehicle might be using.
- ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and widely used today.
- ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, especially in Asia.
- ISO 9141-2: Used in EU, Chrysler, and Asian vehicles from 2000-2004.
- SAE J1850 (VPW): Predominantly used in older GM vehicles.
- SAE J1850 (PWM): Mainly found in older Ford vehicles.
ISO-TP: Transporting OBD2 Messages via ISO 15765-2
All OBD2 data communication over CAN bus relies on ISO-TP (ISO 15765-2), a transport protocol. This protocol is essential for transmitting 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. More details are available in our introduction to UDS.
However, much of the OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of ‘Single Frame’ (SF) format. Here, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-specific communication.
Dissecting the OBD2 Diagnostic Message: SAE J1979, ISO 15031-5 Standards
To fully understand OBD2 communication over CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. In simple terms, an OBD2 message includes an identifier, a data length indicator (PCI field), and the data itself. The data is further broken down into Mode, Parameter ID (PID), and data bytes.
Example: OBD2 Request and Response in Action
Before we detail each component of the OBD2 message, let’s consider an example of requesting and receiving ‘Vehicle Speed’.
In this scenario, an external diagnostic tool sends a request message to the vehicle with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds with a message via CAN ID 0x7E8 and 3 payload bytes. The 4th byte of this response, 0x32 (decimal 50), contains the Vehicle Speed value.
Using the decoding rules for OBD2 PID 0x0D, we can determine that the physical value is 50 km/h.
Next, we’ll focus on the OBD2 modes and PIDs in more detail.
The 10 OBD2 Services (Modes) Defined by the ISO OBD2 Protocol
The ISO OBD2 protocol defines 10 diagnostic services, or modes. Mode 0x01 is used for real-time data retrieval, while others are designed for accessing and clearing Diagnostic Trouble Codes (DTCs) or viewing freeze frame data.
Vehicles are not required to support all 10 OBD2 modes, and manufacturers may implement additional OEM-specific modes outside of these standardized ones.
In OBD2 messages, the mode is located in the second byte. In a request message, the mode is included directly (e.g., 0x01). In a response message, 0x40 is added to the requested mode (e.g., resulting in 0x41 for a response to mode 0x01).
OBD2 Parameter IDs (PIDs) and the ISO OBD2 Protocol
Within each OBD2 mode, there are Parameter IDs (PIDs).
For instance, mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on parameters like speed, RPM, and fuel level. However, vehicles are not obligated to support all PIDs within a given mode. In practice, most vehicles support only a subset of the available PIDs.
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 vehicle’s ECU indicates its support for PIDs 0x01-0x20. This makes PID 0x00 a crucial test for basic ‘OBD2 compatibility’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for subsequent ranges of mode 0x01 PIDs.
Practical Tip: OBD2 PID Overview Tool
The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBD2 PIDs, allowing you to convert raw data into physical values, as explained in our CAN bus introduction.
For quick lookup of mode 0x01 PIDs, utilize our OBD2 PID overview tool. This tool aids in constructing OBD2 request frames and dynamically decoding OBD2 responses.
OBD2 PID overview tool
Practical Guide: Logging and Decoding ISO OBD2 Protocol Data
This section provides a practical example of how to log OBD2 data using the CANedge CAN bus data logger.
The CANedge allows configuration of custom CAN frame transmissions, making it ideal for OBD2 logging.
Once configured, the CANedge can be easily connected to your vehicle using our OBD2-DB9 adapter cable.
Example of sending a CAN frame at 500K to validate bit-rate success.
Review of ‘Supported PIDs’ responses in asammdf.
Step #1: Bit-rate, ID, and Supported PID Validation
As discussed, ISO 15765-4 outlines the process to determine the bit-rate and IDs used by a specific vehicle. You can use the CANedge to perform these tests as follows (refer to the CANedge Intro for detailed instructions):
- Bit-rate Test: Send a CAN frame at 500K and verify successful transmission. If unsuccessful, try 250K.
- Bit-rate Configuration: Use the identified bit-rate for all subsequent communication.
- Supported PIDs Query: Send multiple ‘Supported PIDs’ requests (PID 0x00) and analyze the responses.
- ID Format Determination: Response IDs will indicate 11-bit vs. 29-bit CAN ID usage.
- PID Support Confirmation: Response data reveals which PIDs are supported by the vehicle.
We provide pre-configured setups to simplify these tests.
Most non-EV vehicles manufactured in 2008 or later support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.
As seen in the asammdf GUI screenshot, multiple responses to a single OBD request are common due to the use of the 0x7DF request ID, which broadcasts the request to all ECUs. 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. Note that the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs in the system. To reduce bus load, you can target requests specifically to the ECM by using the ‘Physical Addressing’ CAN ID 0x7E0 for subsequent communication.
Step #2: Configuring OBD2 PID Requests for Data Logging
After identifying the supported OBD2 PIDs, bit-rate, and CAN IDs for your vehicle, you can configure your data logger to request specific PIDs of interest.
Consider these factors when setting up your OBD2 PID requests:
- CAN ID Addressing: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize redundant responses and bus load.
- Request Spacing: Implement a delay of 300-500 ms between each OBD2 request to prevent overwhelming ECUs and ensure reliable responses.
- Battery Management: Use trigger conditions to halt transmissions when the vehicle is inactive, preventing battery drain by ‘waking up’ ECUs unnecessarily.
- Data Filtering: Apply filters to record only OBD2 responses if your vehicle also broadcasts OEM-specific CAN data, streamlining data capture and analysis.
With these configurations in place, your data logger is ready to record raw OBD2 data efficiently.
Example CANedge configuration for OBD2 PID requests.
Visualization of DBC decoded OBD2 data in asammdf.
Step #3: DBC Decoding of Raw OBD2 Data
To effectively analyze and visualize your logged OBD2 data, you need to decode the raw data into physical values (e.g., km/h, °C).
Decoding information is specified in ISO 15031-5/SAE J1979 and is also available on resources like Wikipedia. For convenience, we offer a free OBD2 DBC file that simplifies DBC decoding of raw OBD2 data in most CAN bus software tools.
Decoding OBD2 data is more complex than standard CAN signal decoding because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is insufficient to identify the signals within the payload.
To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID together to correctly identify each signal. This is a form of multiplexing known as ‘extended multiplexing‘, which can be effectively implemented in DBC files.
CANedge: Your Dedicated ISO OBD2 Protocol Data Logger
The CANedge provides an easy-to-use solution for recording ISO OBD2 protocol data directly to an 8-32 GB SD card. Simply connect it to your car or truck to start logging. Decode your data using free software and APIs and our OBD2 DBC file.
OBD2 logger introduction
Explore CANedge
ISO-TP Multi-Frame Examples in ISO OBD2 Protocol
While many examples discussed so far involve single-frame communication, the ISO OBD2 protocol, via ISO-TP (ISO 15765-2), also supports multi-frame communication for larger data packets. This section provides examples of multi-frame OBD2 interactions.
Multi-frame OBD2 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 demonstrated in the CANedge configuration example.
Analyzing multi-frame OBD2 responses requires CAN software or API tools that support ISO-TP, such as the CANedge MF4 decoders.
Example 1: Retrieving Vehicle Identification Number (VIN) via ISO OBD2 Protocol
The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more (see our UDS introduction). To retrieve the VIN using OBD2 requests, utilize mode 0x09 and PID 0x02:
The diagnostic 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, indicating the Number Of Data Items (NODI), which is 1 in this case (see ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes represent the VIN, convertible from HEX to ASCII as discussed in our UDS introduction.
Example 2: Multi-PID Request (6x) in ISO OBD2 Protocol
External tools can 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 multi-frame responses as per ISO-TP.
This method increases data collection efficiency and frequency but complicates signal encoding. Generic OBD2 DBC files may not be suitable for such use cases. We generally advise against this method in practice. Below is an example trace:
The multi-frame response structure is similar to the VIN example, but the payload includes both the requested PIDs and their corresponding data. PIDs are often ordered as requested, which is common but not strictly mandated by ISO 15031-5.
Decoding these responses using DBC files is challenging. Therefore, we don’t recommend this approach for practical data logging unless you are using tools with specific built-in support for multi-PID requests. This approach introduces extended multiplexing complexities, requiring your DBC file to account for the specific payload position of each PID, making it difficult to generalize across vehicles with varying PID support. Managing multiple such multi-PID requests via DBC manipulations becomes nearly impossible.
Workarounds could involve custom scripts that interpret response messages in conjunction with request messages, but these are hard to scale.
Example 3: Diagnostic Trouble Codes (DTCs) via ISO OBD2 Protocol
You can request emissions-related Diagnostic Trouble Codes (DTCs) using OBD2 mode 0x03 (‘Show stored Diagnostic Trouble Codes’). No PID is included in the request. The targeted ECU(s) will respond with the number of stored DTCs (including 0 if none are present), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than 2 DTCs are stored.
The 2-byte DTC value is structured as per 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 shown in the visual. 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.
Use Cases for ISO OBD2 Protocol Data Logging
Data from the ISO OBD2 protocol, gathered from cars and light trucks, has numerous applications:
Logging Data from Cars
OBD2 data logging in cars can help reduce fuel costs, improve driving habits, test prototype components, and optimize insurance models.
Explore OBD2 loggers
Real-Time Car Diagnostics
OBD2 interfaces enable real-time streaming of human-readable OBD2 data, facilitating vehicle diagnostics and issue troubleshooting.
Learn about OBD2 streaming
Predictive Maintenance
Cars and light trucks can be monitored via IoT OBD2 loggers in the cloud to predict and prevent breakdowns through predictive maintenance strategies.
Discover predictive maintenance solutions
Vehicle Black Box Logger
An OBD2 logger can function as a ‘black box’ for vehicles or equipment, providing critical data for dispute resolution or in-depth diagnostics.
Explore CAN bus black box applications
Do you have a specific use case for ISO OBD2 protocol data logging? Contact us for a free consultation!
Contact us
For more introductory guides, see our tutorials section – or download the ‘Ultimate Guide’ PDF.
Need to log or stream ISO OBD2 protocol data?
Get your OBD2 data logger 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
