Understanding the Female OBD2 Connector: Your Gateway to Vehicle Diagnostics

Need a straightforward and practical guide to the Female Obd2 Connector?

This article provides a comprehensive introduction to the female On-Board Diagnostic (OBD2) connector, a critical component in modern vehicle diagnostics. We will explore its function, types, pinout, and its role in accessing your vehicle’s data.

Note: This is designed as a practical guide, so you’ll also learn about the female OBD2 connector’s relevance in requesting and decoding OBD2 data, its key applications, and helpful tips for using it effectively.

Discover why this is becoming a go-to resource for understanding the female OBD2 connector.

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

What is the Female OBD2 Connector?

The female OBD2 connector is essentially the socket in your vehicle that provides access to its built-in self-diagnostic system, known as OBD2. It’s a standardized 16-pin interface that allows mechanics and vehicle owners to retrieve diagnostic trouble codes (DTCs) and real-time data. Think of it as a universal port that service tools use to communicate with your car’s computer.

You’re likely already familiar with the concept of OBD2, perhaps through the malfunction indicator light on your dashboard. This light signals that your car has detected an issue. When you take your vehicle to a mechanic, they use an OBD2 scanner. This scanner connects to the female OBD2 16 pin connector, typically located near the steering wheel.

The tool sends ‘OBD2 requests’ through this female connector to the car’s computer. The car then responds with ‘OBD2 responses’, which can include data like speed, fuel level, or Diagnostic Trouble Codes (DTCs). This communication via the female OBD2 connector is crucial for quickly and accurately troubleshooting vehicle problems.

Understanding the OBD2 System: The malfunction indicator light (MIL) is often the first sign of a potential issue that can be diagnosed using a scan tool connected to the female OBD2 connector.

Is My Car Equipped with a Female OBD2 Connector?

In most cases: Yes!

Almost all modern non-electric vehicles are equipped with a female OBD2 connector and operate on the CAN bus system. However, for older vehicles, the presence of a 16-pin female OBD2 connector doesn’t automatically guarantee OBD2 compliance. Some older cars might have the connector but not fully support the OBD2 protocol. To determine compliance, consider where and when your car was originally purchased:

OBD2 Compliance Guide: This chart helps determine if your vehicle is OBD2 compliant based on the region and year of purchase, despite having a female OBD2 connector.

History of the OBD2 and the Standardized Connector

The origin of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated OBD in all new vehicles from 1991 onwards for emission control.

The Society of Automotive Engineers (SAE) recommended the OBD2 standard, which standardized DTCs and, importantly, the OBD connector itself across different vehicle manufacturers (SAE J1962). This standardization of the female OBD2 connector ensured that any compliant scan tool could interface with any OBD2 compliant vehicle.

The OBD2 standard was implemented gradually across different regions and vehicle types:

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 requirement in the US for medium duty vehicles.
2008: US vehicles mandated to use ISO 15765-4 (CAN) as the OBD2 communication basis.
2010: OBD2 became mandatory in US heavy-duty vehicles.

Evolution of OBD2: From emission control origins to widespread adoption, showing the historical progression of the OBD2 system and the female connector’s role.

OBD2 Timeline: A visual representation of the key milestones in OBD2 history, emphasizing the increasing standardization and adoption of the female OBD2 connector.

Future of OBD: Looking ahead to OBD3 and the potential for remote diagnostics, highlighting the continued relevance of the OBD connector.

The Future of OBD2 and the Female Connector

While OBD2 remains crucial, its future is evolving.

Originally designed for emissions control, legislated OBD2 isn’t strictly required for electric vehicles. Consequently, most modern EVs don’t support standard OBD2 requests, opting for OEM-specific UDS communication instead. This shift can complicate data retrieval from EVs, although reverse engineering efforts are making progress, as seen in case studies for EVs like Tesla, Hyundai/Kia, Nissan, and VW/Skoda.

To address OBD2’s limitations in data richness and lower-layer protocols, alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging. These aim to improve OBD communication using the UDS protocol. For more on these protocols, refer to our intro to UDS.

In the era of connected vehicles, manual OBD2 emission tests seem outdated. The proposed solution is OBD3 – integrating telematics into all vehicles. OBD3 envisions adding a small radio transponder to vehicles, allowing for wireless transmission of the vehicle identification number (VIN) and DTCs to a central server for automated checks.

Devices like the CANedge2 WiFi CAN logger and CANedge3 3G/4G CAN logger already facilitate CAN/OBD2 data transfer via WiFi/cellular. While convenient and cost-saving, this raises privacy concerns.

Originally intended for stationary emission controls, OBD2 is now widely used by third parties for real-time data via OBD2 dongles, CAN loggers, etc. However, the German car industry aims to restrict this, proposing to disable OBD2 functionality during driving and centralize data collection with manufacturers, citing security concerns and aiming to control ‘automotive big data’ (see CAN bus telematics). While presented as a security measure against car hacking, many view it as a commercial strategy that could disrupt the third-party OBD2 service market (see OBD trackers future).

EV and OBD2 Access: Illustrating the trend of electric vehicles potentially limiting access to OBD2 data, impacting the traditional role of the female OBD2 connector.

Get our ‘Ultimate CAN Guide’

Want to become a CAN bus expert?

Get our 12 ‘simple intros’ in one 160+ page PDF:

Download now

OBD2 Standards and the Female Connector

On-board diagnostics, OBD2, is a higher layer protocol, similar to a language, while CAN is the communication method. OBD2 is comparable to other CAN-based protocols like J1939, CANopen, and NMEA 2000.

OBD2 standards define the female OBD2 connector, lower-layer protocols, OBD2 parameter IDs (PIDs), and more. These standards are structured in a 7-layer OSI model. Key standards are defined by both SAE (US standards) and ISO (EU standards). For instance, SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3, are technically very similar.

OBD2 and CAN Bus in OSI Model: Visualizing how OBD2 and CAN bus protocols fit into the 7-layer OSI model, highlighting the standardization framework for vehicle diagnostics.

Female OBD2 Connector Pinout: Detailed diagram of a Type A female OBD2 connector, showing the pin assignments and their functions within the diagnostic system.

The OBD2 Connector [SAE J1962] – Focus on the Female Interface

The 16-pin female OBD2 connector, standardized under SAE J1962 / ISO 15031-3, provides straightforward access to your vehicle’s data. It’s designed as a durable and reliable interface point for diagnostics and data retrieval.

The illustration shows a Type A female OBD2 pin connector, also known as the Data Link Connector (DLC). Key features of the female OBD2 connector include:

Location: Typically found near the steering wheel, though its exact location may be hidden depending on the vehicle model.
Pin 16: Supplies battery power (even when the ignition is off), essential for powering diagnostic tools.
Pinout Variability: The specific OBD2 pinout depends on the communication protocol used by the vehicle.
CAN Bus Connection: In most modern vehicles, CAN bus is the primary protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) of the female OBD2 connector will be active.

Types of Female OBD2 Connectors: Type A vs. Type B

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

Both types share similar pinouts but differ in power supply output: Type A typically provides 12V, and Type B provides 24V. Baud rates can also vary, with cars generally using 500K and heavy-duty vehicles often using 250K (with newer support for 500K).

Visually, Type B female OBD2 connectors have an interrupted groove in the middle, distinguishing them from Type A. A Type B OBD2 adapter cable is versatile and compatible with both Type A and B female sockets, whereas a Type A adapter will only fit into a Type A socket.

OBD2 Connector Types: Comparing Type A and Type B female OBD2 connectors, highlighting differences in power supply and physical characteristics for different vehicle types.

OBD2 and CAN Bus Relationship: Illustrating the integration of OBD2 protocol over CAN bus, the dominant communication standard accessed through the female OBD2 connector.

OBD2 and CAN Bus [ISO 15765-4] Communication via the Female Connector

Since 2008, ISO 15765 mandates CAN bus as the lower-layer protocol for OBD2 in all US vehicles.

ISO 15765-4 (Diagnostics over CAN or DoCAN) specifies how the CAN standard (ISO 11898) is used for OBD2 communication. It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:

CAN Bus Bit-rate: Must be 250K or 500K.
CAN IDs: Can be 11-bit or 29-bit.
Specific CAN IDs: Designated for OBD requests and responses.
Diagnostic CAN Frame Data Length: Fixed at 8 bytes.
OBD2 Adapter Cable Length: Maximum 5 meters.

OBD2 CAN Identifiers (11-bit, 29-bit) and the Female Connector

OBD2 communication involves request/response messages transmitted through the female connector.

Most cars use 11-bit CAN IDs for OBD2. The ‘Functional Addressing’ ID is 0x7DF, used to query all OBD2-compatible ECUs for data on a requested parameter (ISO 15765-4). ‘Physical Addressing’ requests to specific ECUs use CAN IDs 0x7E0-0x7E7 (less common).

ECUs respond with 11-bit IDs 0x7E8-0x7EF. The most common response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module).

Some vehicles, especially vans and medium/heavy-duty vehicles, use extended 29-bit CAN identifiers for OBD2 communication. The ‘Functional Addressing’ CAN ID here is 0x18DB33F1. Responses use CAN IDs 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is also represented in ‘J1939 PGN’ form, PGN 0xDA00 (55808), which is ‘Reserved for ISO 15765-2’ in the J1939-71 standard.

OBD2 Communication Framework: Illustrating the request and response message exchange in OBD2 protocol, essential for diagnostic tools interfacing via the female connector.

OBD2 vs. Proprietary CAN: Contrasting OBD2 standard communication with OEM-specific CAN protocols, highlighting the female OBD2 connector as the access point for both.

OBD2 vs. Proprietary CAN Protocols and the Female Connector

Vehicle ECUs primarily function using OEM-specific proprietary CAN protocols, not OBD2. These protocols are unique to vehicle brands, models, and years. Reverse engineering is typically needed to interpret this data (see CAN bus sniffer reverse engineering).

Connecting a CAN bus data logger to the female OBD2 connector might capture OEM-specific CAN data, often broadcast at 1000-2000 frames/second. However, newer vehicles often use a ‘gateway’ to block access to this CAN data via the female OBD2 connector, allowing only OBD2 communication.

Think of OBD2 as an ‘additional’ higher-layer protocol running alongside the OEM-specific protocol, both accessible through the same female OBD2 connector.

Bit-rate and ID Validation via the Female Connector

OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in 4 combinations. Modern cars commonly use 500K and 11-bit IDs. Tools should systematically verify these settings when connecting to the female OBD2 connector.

ISO 15765-4 provides a sequence to determine the correct combination. OBD2 compliant vehicles must respond to a mandatory OBD2 request, and incorrect bit-rates will cause CAN error frames.

Newer ISO 15765-4 versions account for OBDonUDS alongside OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (ISO 15031-5/SAE J1979) versus WWH-OBD/OBDonUDS (ISO 14229, ISO 27145-3/SAE J1979-2).

Protocol testing (OBDonEDS vs. OBDonUDS) involves sending UDS requests via the female connector with 11-bit/29-bit functional address IDs for service 0x22 and DID 0xF810 (protocol identification). OBDonUDS-supporting vehicles must have ECUs that respond to this DID.

OBDonEDS (OBD2, SAE OBD, EOBD, ISO OBD) is prevalent in non-EVs, while WWH-OBD is mainly in EU trucks/buses.

Bit-rate Validation Flowchart: A flowchart illustrating the process of validating bit-rate and CAN ID settings when establishing OBD2 communication through the female connector.

Five OBD2 Protocols: Overview of the five lower-layer protocols used in OBD2, showing the evolution from older standards to the dominant CAN bus protocol.

Five Lower-Layer OBD2 Protocols and Connector Pinouts

While CAN (ISO 15765) is now dominant, older vehicles (pre-2008) may use other protocols. Understanding these is useful, especially when diagnosing older vehicles via the female OBD2 connector. Connector pinouts can help identify the protocol in use:

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and widely used today.
ISO14230-4 (KWP2000): Common in 2003+ Asian vehicles.
ISO 9141-2: Used in EU, Chrysler, and Asian cars (2000-04).
SAE J1850 (VPW): Primarily in older GM vehicles.
SAE J1850 (PWM): Mostly in older Ford vehicles.

ISO-TP for OBD2 Messaging [ISO 15765-2] and the Female Connector

All OBD2 data through the female connector is transmitted using ISO-TP (ISO 15765-2), a transport protocol enabling payloads larger than 8 bytes. This is essential for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly. More details are in our UDS intro.

Often, OBD2 data fits within a single CAN frame. ISO 15765-2 specifies ‘Single Frame’ (SF) usage, where the 1st data byte (PCI field) indicates payload length (excluding padding), leaving 7 bytes for OBD2 communication.

ISO-TP Frame Types: Illustrating the different frame types in ISO-TP protocol used for OBD2 communication, essential for handling data transmission via the female connector.

The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5] Structure via the Female Connector

Understanding the structure of an OBD2 message is key to interpreting data received through the female connector. A ‘Single Frame’ OBD2 CAN message comprises an identifier, data length (PCI field), and data (Mode, parameter ID (PID), and data bytes).

OBD2 Message Structure: Breakdown of an OBD2 message frame, showing the arrangement of identifier, PCI field, Mode, PID, and data bytes, critical for decoding information from the female connector.

Example: OBD2 Request/Response via the Female Connector

Consider a request/response example for ‘Vehicle Speed’.

An external tool sends a request via the female OBD2 connector with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds via CAN ID 0x7E8 with 3 payload bytes, including the speed value in the 4th byte, 0x32 (50 decimal).

Using OBD2 PID 0x0D decoding rules, we find the physical value is 50 km/h.

Next, we’ll explore OBD2 modes and PIDs.

OBD2 Request-Response Example: Demonstrating a typical OBD2 request for vehicle speed and the corresponding response, illustrating data flow through the female connector.

Vehicle Speed PID Example: Focusing on PID 0x0D for vehicle speed, showing how to interpret the data bytes received via the female connector to get a physical value.

OBD2 Service Modes: Overview of the 10 OBD2 service modes, detailing their functions from real-time data to DTC management, all accessed via the female OBD2 connector.

The 10 OBD2 Services (Modes) Accessed via the Female Connector

OBD2 includes 10 diagnostic services (modes). Mode 0x01 provides real-time data, while others manage diagnostic trouble codes (DTCs) or freeze frame data.

Vehicles may not support all OBD2 modes and can include OEM-specific modes beyond the 10 standard ones.

In OBD2 messages, the mode is in the 2nd byte. In requests, the mode is direct (e.g., 0x01), while responses add 0x40 to the mode (e.g., 0x41).

OBD2 Parameter IDs (PIDs) and Data Retrieval via the Female Connector

Each OBD2 mode contains parameter IDs (PIDs). For example, mode 0x01 has ~200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles may only support a subset of PIDs within a mode.

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 ECU indicates support for PIDs 0x01-0x20. PID 0x00 serves as a basic ‘OBD2 compatibility test’. PIDs 0x20, 0x40, …, 0xC0 can then determine support for other mode 0x01 PIDs.

PID Request-Response Flow: Reinforcing the request and response mechanism for PIDs, essential for retrieving specific vehicle parameters through the female connector.

OBD2 PID Tool Interface: Screenshot of an OBD2 PID overview tool, demonstrating how users can interact with PID data and diagnostics via the female connector interface.

Tip: OBD2 PID Overview Tool for Female Connector Data

SAE J1979 and ISO 15031-5 appendices detail scaling information for standard OBD2 PIDs, allowing data decoding into physical values (as explained in our CAN bus intro).

For mode 0x01 PID lookups, use our OBD2 PID overview tool. It aids in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

How to Log and Decode OBD2 Data from the Female Connector

Here’s a practical example of logging OBD2 data using a CANedge CAN bus data logger.

CANedge allows configuration of custom CAN frames for transmission, enabling OBD2 logging. Connect it to your vehicle’s female OBD2 connector using our OBD2-DB9 adapter cable.

OBD2 Data Logger Setup: Illustrating the connection of an OBD2 data logger to the female OBD2 connector for capturing vehicle diagnostic data.

Bit-rate Validation Test: Showing a bit-rate validation test, ensuring correct communication parameters for data logging via the female connector.

Supported PIDs in asammdf: Displaying supported PIDs as seen in asammdf software, showing the results of querying the vehicle through the female connector.

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

ISO 15765-4 outlines how to determine vehicle bit-rate and IDs. Test this with CANedge as follows (see CANedge Intro for details):

Test at 500K bit-rate; if successful, proceed (else try 250K).
Use the identified bit-rate for all communication.
Send ‘Supported PIDs’ requests and review responses.
Determine 11-bit vs. 29-bit IDs based on response IDs.
Identify supported PIDs from response data.

We offer plug-and-play configurations for these tests. Most 2008+ non-EV cars support 40-80 PIDs via 500K bit-rate, 11-bit CAN IDs, and OBD2/OBDonEDS.

As shown in the asammdf GUI screenshot, multiple responses to a single OBD request are common due to the 0x7DF request ID polling all ECUs. Since all OBD2/OBDonEDS ECUs must support service 0x01 PID 0x00, many responses occur, especially to this PID. Fewer ECUs respond to subsequent ‘Supported PIDs’ requests. The ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, reducing busload by specifically requesting responses from it using ‘Physical Addressing’ CAN ID 0x7E0.

#2: Configure OBD2 PID Requests for Female Connector Logging

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

Considerations:

CAN IDs: Use ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses.
Spacing: Add 300-500 ms between OBD2 requests to prevent ECU overload.
Battery Drain: Use triggers to stop transmissions when inactive.
Filters: Filter for OBD2 responses if OEM-specific CAN data is also present.

With configuration complete, the device is ready to log raw OBD2 data from the female connector!

CANedge OBD2 Request List: An example configuration showing a list of OBD2 PID requests set up for transmission via CANedge, demonstrating practical data logging parameters.

Decoded OBD2 Data in asammdf: Visualization of decoded OBD2 data in asammdf using a DBC file, showing how raw data from the female connector can be interpreted.

#3: DBC Decode Raw OBD2 Data from the Female Connector

To analyze and visualize logged data, decode raw OBD2 data into physical values. Decoding information is in ISO 15031-5/SAE J1979 (and Wikipedia). Our free OBD2 DBC file simplifies DBC decoding in most CAN bus software.

Decoding OBD2 data is more complex than standard CAN signals because OBD2 PIDs use the same CAN ID (e.g., 0x7E8). The CAN ID alone is insufficient for signal identification.

Signal identification requires both CAN ID, OBD2 mode, and OBD2 PID, a form of multiplexing called ‘extended multiplexing’, implementable in DBC files.

CANedge: OBD2 Data Logger for Female Connector Interface

The CANedge easily records OBD2 data to an 8-32 GB SD card. Simply connect it to a vehicle’s female OBD2 connector to start logging, and decode data using free software/APIs and our OBD2 DBC.

OBD2 logger intro CANedge

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

OBD2 data, transmitted via the female connector, uses ISO-TP (ISO 15765-2). Most examples so far are single-frame. Multi-frame communication examples follow, requiring flow control frames (see UDS intro). A static flow control frame can be transmitted ~50 ms after the initial request, as shown in the CANedge configuration example.

Multi-frame OBD2 responses require CAN software/API tools supporting ISO-TP, like CANedge MF4 decoders.

Multi-frame Request Example: Showing a multi-frame request message, specifically for vehicle identification number retrieval, demonstrating advanced OBD2 communication techniques.

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

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more (see UDS intro). Retrieve VIN using OBD2 mode 0x09 and PID 0x02:

The tester tool sends a Single Frame request with PCI field (0x02), request service identifier (0x09), and PID (0x02).

The vehicle responds with a First Frame containing PCI, length (0x014 = 20 bytes), mode (0x49), and PID (0x02). Byte 0x01 follows the PID, representing the Number Of Data Items (NODI), in this case 1 (see ISO 15031-5 / SAE J1979). The remaining 17 bytes are the VIN, convertible from HEX to ASC as discussed in our UDS intro.

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

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

This feature enhances data collection efficiency but complicates signal encoding, making generic OBD2 DBC files less useful. It’s generally not recommended. Below is an example trace:

The multi-frame response is similar to the VIN example but includes requested PIDs and their data. PIDs are often ordered as requested (common but not ISO 15031-5 standard).

Decoding via DBC files is complex and generally discouraged unless tools specifically support this method. It represents extended multiplexing with multiple instances throughout the payload. DBC files would need to account for each PID’s payload position, making generalization across vehicles difficult. Handling multiple multi-PID requests via pure DBC manipulation becomes nearly impossible without a method to uniquely identify messages.

Workarounds include custom scripts and recording transmit messages, allowing interpretation of responses based on requests. However, these approaches are challenging to scale.

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

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

The 2-byte DTC value is split per ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’, and the remaining 14 bits define 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.

DTC Decoding Example: Explaining how to decode Diagnostic Trouble Codes (DTCs) received via the female connector, showing the structure and interpretation of DTC data.

OBD2 Data Logging Use Cases via the Female Connector

OBD2 data from cars and light trucks, accessed through the female connector, has various applications:

Logging Car Data

OBD2 data logging aids in fuel cost reduction, driving improvement, prototype testing, and insurance applications.

obd2 logger

Real-time Car Diagnostics

OBD2 interfaces stream human-readable data in real-time for vehicle diagnostics.

obd2 streaming

Predictive Maintenance

IoT OBD2 loggers monitor vehicles in the cloud for predictive maintenance to prevent breakdowns.

predictive maintenance

Vehicle Blackbox Logger

OBD2 loggers serve as ‘black boxes’ for vehicles, providing data for disputes or diagnostics.

can bus blackbox

Have an OBD2 data logging use case? Contact us for free consultation!

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

Need to log/stream OBD2 data?

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

[