Decoding the OBD Connector: Your Gateway to Vehicle Diagnostics [2025 Guide]

Looking for a straightforward guide to understanding the Obd Connector?

This article provides a practical introduction to the On-Board Diagnostics II (OBD2) system, with a specific focus on the OBD connector. We’ll cover everything from the basics of the OBD2 protocol and connector to OBD2 parameter IDs (PIDs) and its connection to the CAN bus.

This is designed as a hands-on introduction, so you’ll also learn how to request and interpret OBD2 data, explore key applications, and get practical tips.

Discover why this is becoming a leading resource for learning about OBD2 and, specifically, the crucial OBD connector.

You can also watch our OBD2 intro video above – or get the PDF

Understanding OBD2 and the OBD Connector

OBD2 is essentially your car’s internal health monitoring system. It’s a standardized protocol that allows access to diagnostic trouble codes (DTCs) and real-time vehicle data through the OBD connector.

You’ve likely already encountered OBD2 in some form.

Ever seen the check engine light illuminate on your dashboard?

That’s your vehicle signaling a problem. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the issue.

This process involves connecting an OBD2 reader to the 16-pin OBD2 connector, typically located near the steering wheel. This tool sends ‘OBD2 requests’ to the vehicle, and the car responds with ‘OBD2 responses’, which can include data like speed, fuel level, or Diagnostic Trouble Codes (DTCs). This communication via the OBD connector makes troubleshooting much faster and more efficient.

Is Your Car Equipped with an OBD Connector?

In short: Most likely, yes!

Nearly all modern non-electric vehicles are equipped with OBD2 and predominantly utilize the CAN bus system. For older vehicles, even if a 16-pin OBD connector is present, it might not actually support OBD2. A key indicator of OBD2 compliance is the vehicle’s purchase location and year:

A Brief History of the OBD Connector and OBD2

The origins of OBD2 trace back to California, where the California Air Resources Board (CARB) mandated OBD in all new vehicles starting from 1991 to monitor and control emissions.

The OBD2 standard was further developed and recommended by the Society of Automotive Engineers (SAE), which standardized DTCs and, importantly, the OBD connector across different manufacturers (SAE J1962).

The implementation of the OBD2 standard was a phased process:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: Required in the EU for gasoline cars.
2003: Extended to diesel cars in the EU (EOBD).
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 via the OBD connector.
2010: OBD2 mandate extended to heavy-duty vehicles in the US.

The Future of OBD2 and the OBD Connector

OBD2 is expected to remain relevant, but its form and function are evolving.

Here are some key trends to consider:

Originally, OBD2 was legislated for emissions control and testing. Consequently, electric vehicles (EVs) are generally not required to support OBD2 in its standard form. In fact, most modern EVs do not support standard OBD2 requests. Instead, they often use OEM-specific UDS communication protocols. This makes accessing data from EVs challenging, except in cases where decoding methods have been reverse-engineered. Examples include case studies for electric cars like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

OBD2 implementations today vary and have limitations in data richness and lower-layer protocols. Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged to address these issues. These aim to improve OBD communication by using the UDS protocol as a base. For more on these protocols, refer to our introduction to UDS.

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

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

OBD3 envisions adding a small radio transponder (similar to those used for bridge tolls) to all cars. This would allow the car’s vehicle identification number (VIN) and DTCs to be transmitted wirelessly via WiFi to a central server for automated checks.

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

While this offers cost savings and convenience, it also raises political and privacy concerns related to surveillance.

The OBD2 protocol was initially designed for stationary emissions testing.

However, third parties now widely use OBD2 to generate real-time data via OBD2 dongles, CAN loggers and other devices. The German car industry is considering limiting this access:

OBD was intended for car servicing 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,” as stated by Christoph Grote, SVP Electronics, BMW (2017).

The proposal is to deactivate OBD2 functionality during driving and instead collect data on a central server. This would give manufacturers control over the ‘automotive big data’.

Security concerns, such as mitigating the risk of car hacking, are cited as reasons, although many view it as a commercially motivated move. Whether this trend gains traction remains to be seen, but it could significantly disrupt the market for third-party OBD2 services.

Enhance Your CAN Bus Expertise

Want to become a CAN bus expert?

Access our 12 ‘simple intros’ in a comprehensive 160+ page PDF:

Download now

OBD2 Standards and the OBD Connector

On-board diagnostics, or OBD2, is a higher-layer protocol – essentially a language. CAN bus is the communication method, like a phone line. This makes OBD2 comparable to other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

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

These standards can be categorized within a 7-layer OSI model. The following sections will focus on the most critical aspects, particularly those related to the OBD connector.

In the OSI model, you’ll notice that SAE and ISO standards cover multiple layers. This reflects the standards for OBD defined in the USA (SAE) and EU (ISO). Many standards are technically very similar, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3 – the latter being crucial for the OBD connector specification.

The OBD2 Connector [SAE J1962]

The 16-pin OBD2 connector is your primary interface for accessing vehicle data, as specified by the SAE J1962 / ISO 15031-3 standard.

The illustration above shows a typical Type A OBD2 pin connector, also known as a Data Link Connector (DLC).

Key points about the OBD connector:

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

OBD2 Connector Types: A vs. B

You may encounter both Type A and Type B OBD2 connectors. Type A is standard in cars, while Type B is more common in medium and heavy-duty vehicles.

Both types share similar OBD2 pinouts but differ in power supply outputs: Type A typically provides 12V, and Type B provides 24V. Baud rates can also differ, with cars often using 500K, and heavy-duty vehicles often using 250K (though 500K is becoming more common).

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

OBD2 and CAN Bus [ISO 15765-4]

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all US-sold vehicles, according to ISO 15765. This standardization significantly impacts the OBD connector‘s communication method.

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies a set of rules for using CAN (ISO 11898) for diagnostics.

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 and responses via the OBD connector.
Diagnostic CAN frame data length is fixed at 8 bytes.
The OBD2 adapter cable connected to the OBD connector must not exceed 5 meters in length.

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

All OBD2 communication involves request/response message pairs transmitted through the OBD connector.

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 per ISO 15765-4). CAN IDs ranging from 0x7E0 to 0x7E7 can be used for ‘Physical Addressing’ requests to specific ECUs, though this is less common.

ECUs respond with 11-bit IDs in the range 0x7E8-0x7EF. The most common response ID is 0x7E8 (from the Engine Control Module, ECM), and to a lesser extent 0x7E9 (from the Transmission Control Module, TCM).

In some vehicles, especially vans and medium to heavy-duty vehicles, OBD2 communication may use extended 29-bit CAN identifiers instead of 11-bit IDs via the OBD connector.

For 29-bit identifiers, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Responses are typically seen with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (commonly 0x18DAF110 and 0x18DAF11E). The response ID is also sometimes represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which the J1939-71 standard marks as ‘Reserved for ISO 15765-2’.

OBD2 vs. Proprietary CAN Protocols

It’s crucial to understand that your vehicle’s electronic control units (ECUs) do not depend on OBD2 for their primary functions. Instead, each Original Equipment Manufacturer (OEM) implements its own proprietary CAN protocols for internal communication. These protocols are often unique to the vehicle brand, model, and year. Unless you are the OEM, interpreting this proprietary data is typically not possible without reverse engineering it.

When you connect a CAN bus data logger to your car’s OBD connector, you might observe OEM-specific CAN data, usually broadcast at a high rate of 1000-2000 frames per second. However, many newer vehicles use a ‘gateway’ that restricts access to this raw CAN data through the OBD connector, only allowing OBD2 communication.

In essence, think of OBD2 as an ‘additional’ higher-layer protocol that operates alongside the OEM-specific protocol, both accessible via the OBD connector.

Bit-rate and ID Validation for OBD Connector Communication

As mentioned, OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in 4 potential combinations for communication through the OBD connector. Modern cars commonly use 500K and 11-bit IDs, but diagnostic tools should systematically verify this.

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

Newer versions of ISO 15765-4 account for vehicles that might support OBD communication via OBDonUDS rather than 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 protocols when using the OBD connector, a diagnostic tool 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 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 OBD2 Protocols

CAN bus is now the dominant lower-layer protocol for OBD2, as defined by ISO 15765.

However, when working with older vehicles (pre-2008), it’s useful to know the other four lower-layer protocols that were previously used for OBD2. The OBD connector pinouts can sometimes indicate which protocol a vehicle might be using.

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and now the most common protocol.
ISO14230-4 (KWP2000): Keyword Protocol 2000, frequently used in 2003+ vehicles, especially in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian cars from 2000-2004.
SAE J1850 (VPW): Mostly found 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 exchanged through the OBD connector is communicated on the CAN bus using 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. For more details, see 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). Here, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-related communication within the CAN frame transmitted via the OBD connector.

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

To better understand OBD2 communication over CAN via the OBD connector, 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 actual data. The data is further structured into Mode, parameter ID (PID), and data bytes.

Example: OBD2 Request/Response via the OBD Connector

Before detailing each part of the OBD2 message, consider this example of a request/response for ‘Vehicle Speed’ sent and received through the OBD connector.

An external tool sends a request message to the vehicle via the OBD connector with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds back through the OBD connector via CAN ID 0x7E8 with 3 payload bytes, including the vehicle speed value in the 4th byte, 0x32 (which is 50 in decimal form).

By consulting the decoding rules for OBD2 PID 0x0D, we can determine that the physical value is 50 km/h.

Next, we will delve into OBD2 modes and PIDs, which are essential for understanding data exchanged through the OBD connector.

The 10 OBD2 Services (aka Modes)

There are 10 standardized OBD2 diagnostic services, often referred to as modes, accessible via the OBD connector. Mode 0x01 is used to access current real-time data, while other modes are used to display or clear diagnostic trouble codes (DTCs) or to access freeze frame data.

Vehicles are not required to support all 10 OBD2 modes and may also support non-standard, OEM-specific OBD2 modes accessed through the OBD connector.

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

OBD2 Parameter IDs (PIDs)

Within each OBD2 mode, there are Parameter IDs (PIDs). These PIDs are crucial for specifying what data is being requested or provided through the OBD connector.

For example, mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on parameters such as speed, RPM, and fuel level. However, vehicles do not have to support all OBD2 PIDs within a mode. In practice, most vehicles only support a subset of these standardized PIDs accessible via the OBD connector.

One PID is particularly important:

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’ when using the OBD connector. Further, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs.

Tip: OBD2 PID Overview Tool

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

For quick lookup of mode 0x01 PIDs, use our OBD2 PID overview tool. This tool helps you construct OBD2 request frames and dynamically decode OBD2 responses, streamlining the process of interacting with your vehicle’s OBD connector.

OBD2 PID overview tool

How to Log and Decode OBD2 Data from the OBD Connector

This section provides a practical guide on logging OBD2 data using the CANedge CAN bus data logger, connected via the OBD connector.

The CANedge allows you to configure custom CAN frames for transmission, making it suitable for OBD2 logging.

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

Verifying successful CAN frame transmission at 500K bit-rate.

Reviewing responses to ‘Supported PIDs’ in asammdf.

#1: Test Bit-rate, IDs & Supported PIDs via the OBD Connector

As discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a vehicle’s OBD connector. You can test this with CANedge as follows (see the CANedge Intro for details):

Send a CAN frame at 500K and check for successful transmission (if not, try 250K).
Use the identified bit-rate for all subsequent communication via the OBD connector.
Send multiple ‘Supported PIDs’ requests and analyze the responses.
Determine 11-bit vs. 29-bit IDs based on response IDs.
Identify supported PIDs based on response data.

We offer plug-and-play configurations to simplify these tests for your OBD connector interface.

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

As shown in the asammdf GUI screenshot, multiple responses to a single OBD request are common when using the 0x7DF request ID, which queries all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, many responses to this PID are typical. For subsequent ‘Supported PIDs’ requests, fewer ECUs usually respond. Note that the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs in this example. Therefore, reducing bus load can be achieved by specifically querying only this ECU using ‘Physical Addressing’ CAN ID 0x7E0 for future communication via the OBD connector.

#2: Configure OBD2 PID Requests for OBD Connector Logging

Once you know the supported OBD2 PIDs, bit-rate, and CAN IDs for your vehicle’s OBD connector, you can configure your transmit list with the PIDs you want to log.

Consider these points when setting up your logging configuration:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses per request from the OBD connector.
Spacing: Add 300-500 ms intervals between OBD2 requests to avoid overwhelming ECUs and ensure reliable responses via the OBD connector.
Battery Drain: Use triggers to stop transmissions when the vehicle is inactive to prevent battery drain by ‘waking up’ ECUs through the OBD connector.
Filters: Implement filters to record only OBD2 responses if your vehicle also broadcasts OEM-specific CAN data through the OBD connector.

With these configurations, your device is ready to log raw OBD2 data from the OBD connector!

Example list of CANedge OBD2 PID requests for logging via the OBD connector.

asammdf allows DBC decoding and visualization of OBD2 data logged from the OBD connector.

#3: DBC Decode Raw OBD2 Data from your OBD Connector Logs

Finally, to analyze and visualize your logged data from the OBD connector, you need to decode the raw OBD2 data into ‘physical values’ (like km/h or °C).

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

Decoding OBD2 data is more complex than standard CAN signals because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8) through the OBD connector. The CAN ID alone isn’t enough to identify the signals in the payload.

To solve this, you must use the CAN ID, OBD2 mode, and OBD2 PID to identify each signal. This is a form of multiplexing known as ‘extended multiplexing‘, which can be implemented using DBC files.

CANedge: Your OBD2 Data Logger via the OBD Connector

The CANedge simplifies recording OBD2 data to an 8-32 GB SD card directly from your vehicle’s OBD connector. Simply connect it to your car or truck to start logging and decode the data using free software/APIs and our OBD2 DBC.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples [ISO-TP] via the OBD Connector

All OBD2 data communication through the OBD connector uses the ISO-TP (transport protocol) as per ISO 15765-2. Most examples so far have been single-frame communication. This section provides examples of multi-frame communication scenarios via the OBD connector.

Multi-frame OBD2 communication requires flow control frames (see our UDS intro). A practical approach is to transmit a static flow control frame about 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.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval via the OBD Connector

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more. (Refer to our UDS intro for details). To retrieve the VIN from a vehicle using OBD2 requests via the OBD connector, use 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) through the OBD connector.

The vehicle responds with a First Frame containing the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02) via the OBD connector. Following the PID is byte 0x01, representing the Number Of Data Items (NODI), in this case 1 (see ISO 15031-5 / SAE J1979 for details). The remaining 17 bytes constitute the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction.

Example 2: OBD2 Multi-PID Request (6x) via the OBD Connector

External diagnostic tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame transmitted via the OBD connector. The ECU should respond with data for all supported PIDs (omitting unsupported ones in the response), possibly using multiple frames as per ISO-TP.

This method allows for more efficient data collection at higher frequencies. However, the signal encoding becomes specific to the request method, complicating the use of generic OBD2 DBC files. We generally do not recommend this method for practical use. Below is an example trace:

The multi-frame response, received through the OBD connector, 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 this response using standard DBC files is challenging. Therefore, we advise against this approach for practical data logging unless you use a tool specifically designed for this purpose. This scenario represents extended multiplexing, where the DBC file must account for each PID’s specific payload position, making it difficult to generalize across different vehicles. Managing this complexity purely through DBC manipulations becomes nearly impossible if you send multiple multi-PID requests, as uniquely identifying messages becomes problematic.

Workarounds could include custom scripts that interpret responses based on corresponding requests. However, such methods are hard to scale and manage effectively.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) via the OBD Connector

OBD2 can be used to request emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, ‘Show stored Diagnostic Trouble Codes,’ via the OBD connector. No PID is included in the request. The target ECU(s) will respond with the number of stored DTCs (possibly zero), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than two DTCs are stored.

The 2-byte DTC value is typically divided into two parts, 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 in OBD2 DTC lookup tools like repairpal.com.

The example below shows a request to an ECU with 6 stored DTCs, communicated via the OBD connector.

OBD2 Data Logging – Use Case Examples Utilizing the OBD Connector

OBD2 data, accessed through the OBD connector, from cars and light trucks has numerous applications:

Logging Data from Cars via the OBD Connector

OBD2 data from cars, obtained via the OBD connector, can be used to reduce fuel costs, improve driving habits, test prototype parts, and for insurance purposes.

obd2 logger

Real-Time Car Diagnostics via the OBD Connector

OBD2 interfaces, connected through the OBD connector, can stream human-readable OBD2 data in real-time, enabling live vehicle diagnostics and issue detection.

obd2 streaming

Predictive Maintenance Using OBD Connector Data

Cars and light trucks can be monitored via IoT OBD2 loggers connected to the OBD connector, transmitting data to the cloud to predict and prevent breakdowns through proactive maintenance.

predictive maintenance

Vehicle Black Box Logger via the OBD Connector

An OBD2 logger, connected via the OBD connector, can serve as a ‘black box’ for vehicles or equipment, providing critical data for dispute resolution or in-depth diagnostics.

can bus blackbox

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

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

Need to log or stream OBD2 data from your OBD Connector?

Get your OBD2 data logger today!

Buy now
Contact us

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN