Understanding the OBD2 Protocol Specification: A Comprehensive Guide for Automotive Experts

Need a detailed breakdown of the Obd2 Protocol Specification?

This guide provides an in-depth exploration of the On-Board Diagnostic (OBD2) protocol specification, essential for anyone working with vehicle diagnostics and data. We delve into the OBD2 connector specifications, OBD2 parameter ID (PID) specifications, and the underlying protocols that define OBD2 communication, including its relationship with the CAN bus.

Note: This is a detailed guide focused on the protocol specification, offering insights into requesting and interpreting OBD2 data, crucial for advanced applications and understanding the nuances of vehicle communication.

Discover why this is becoming the go-to resource for understanding the OBD2 protocol specification.

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

What is the OBD2 Protocol Specification?

The OBD2 protocol specification defines a standardized system for vehicle self-diagnostics. It is more than just a connector; it’s a comprehensive set of rules and standards that dictate how diagnostic trouble codes (DTCs) and real-time data are accessed and interpreted via the OBD2 connector. Understanding the obd2 protocol specification is key to effectively interacting with modern vehicle systems.

You’ve likely encountered the results of the OBD2 protocol in action: the malfunction indicator light on your dashboard signals an issue detected by the vehicle’s self-diagnostic system, as defined by the OBD2 protocol specification. Mechanics use OBD2 scanners, tools designed to communicate according to the obd2 protocol specification, to diagnose these issues.

These scanners connect to the OBD2 16 pin connector, typically found near the steering wheel. The scanner transmits ‘OBD2 requests’ – messages formulated according to the obd2 protocol specification – to the car. The vehicle responds with ‘OBD2 responses’, also adhering to the obd2 protocol specification, providing data such as speed, fuel level, or DTCs. This standardized communication, dictated by the obd2 protocol specification, allows for efficient and consistent troubleshooting across different vehicle makes and models.

OBD2 Compliance and History: Evolution of the Protocol Specification

Determining OBD2 compliance is crucial when working with vehicle diagnostics. The obd2 protocol specification has evolved over time, impacting which vehicles are compliant and the specific standards they adhere to.

In short: Most likely, yes!

For most post-1996 non-electric vehicles, OBD2 support is standard, often operating on the CAN bus. However, the presence of a 16-pin OBD2 connector in older vehicles doesn’t guarantee OBD2 compliance. Some may use the connector but not fully implement the obd2 protocol specification. Compliance is often linked to the vehicle’s market and manufacturing date:

OBD2 History: Driving Forces Behind the Protocol Specification

The obd2 protocol specification has its roots in California. The California Air Resources Board (CARB) mandated OBD in all new vehicles from 1991 onwards for emission control. This initial requirement laid the groundwork for the standardized obd2 protocol specification we know today.

The Society of Automotive Engineers (SAE) played a key role in defining the obd2 protocol specification, recommending the standard and standardizing DTCs and the OBD connector across different manufacturers through SAE J1962. This standardization was crucial for the widespread adoption of OBD2.

The obd2 protocol specification rollout was a phased process:

1996: OBD2 became mandatory in the USA for cars and light trucks, solidifying the obd2 protocol specification as a requirement.
2001: The EU mandated OBD2 for gasoline cars, expanding the global reach of the obd2 protocol specification.
2003: The EU extended the requirement to diesel cars (EOBD), further harmonizing the obd2 protocol specification across different engine types.
2005: OBD2 was required in the US for medium duty vehicles, broadening the scope of vehicles covered by the obd2 protocol specification.
2008: US vehicles were mandated to use ISO 15765-4 (CAN) as the foundation for OBD2, standardizing the communication protocol within the obd2 protocol specification.
2010: OBD2 became mandatory in US heavy duty vehicles, completing the phased implementation of the obd2 protocol specification across vehicle classes.

Future Trends and the OBD2 Protocol Specification

The obd2 protocol specification, while established, continues to evolve with automotive technology. Understanding future trends is essential for anticipating changes in vehicle diagnostics.

OBD2 is expected to remain relevant, but its form and application are changing.

Initially designed for emissions control, the legislated OBD2 has limitations, particularly with electric vehicles. Electric vehicles are not mandated to support OBD2 in its traditional form, and many do not. Instead, they often use OEM-specific UDS communication, deviating from the standard obd2 protocol specification. Decoding data from EVs often requires reverse engineering due to this departure from the standard, as seen in case studies for Tesla, Hyundai/Kia, Nissan and VW/Skoda EVs.

The limitations of the current obd2 protocol specification in data richness and lower-layer protocols have spurred the development of alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). These aim to enhance OBD communication by using the UDS protocol as a base, improving upon the existing obd2 protocol specification. Further details on these protocols can be found in our intro to UDS.

In the era of connected cars, manual emission checks based on the obd2 protocol specification are becoming inefficient. OBD3 proposes a solution by integrating telematics into all vehicles. OBD3 envisions adding a radio transponder to vehicles, enabling 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 or OBD2 data transfer via WiFi/cellular. While convenient and cost-saving, OBD3 raises privacy concerns.

The original obd2 protocol specification was designed for stationary emission controls. Today, third parties extensively use OBD2 for real-time data generation through OBD2 dongles and CAN loggers. However, the German car industry aims to restrict this, as highlighted by BMW’s Christoph Grote in 2017:

“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“

The proposal is to disable OBD2 functionality during driving and centralize data collection with manufacturers, giving them control over ‘automotive big data’. Security concerns, like mitigating car hacking risks, are cited, but many view this as a commercial strategy. The future impact on third-party OBD2 services remains uncertain.

Enhance Your Expertise with Our ‘Ultimate CAN Guide’

Want to deepen your understanding of CAN bus technology?

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

Download now

Key OBD2 Standards Defining the Protocol Specification

The obd2 protocol specification is built upon a set of standards that define various aspects of the system, from the physical connector to the communication protocols. On-board diagnostics, OBD2, is a higher layer protocol, similar to languages built upon a communication method like a phone (CAN). OBD2 is comparable to other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

Specifically, the OBD2 standards within the obd2 protocol specification detail the OBD2 connector, lower-layer protocols, OBD2 parameter IDs (PIDs), and more. These standards are often categorized using the 7-layer OSI model, providing a structured view of the obd2 protocol specification. The following sections will focus on the most critical standards.

Within the OSI model framework for the obd2 protocol specification, SAE and ISO standards cover multiple layers. This reflects the standardization efforts in the USA (SAE) and EU (ISO). Many standards are technically equivalent, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.

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

The 16-pin OBD2 connector, a key component defined by the obd2 protocol specification, provides a standardized physical interface for accessing vehicle data. It is detailed in SAE J1962 and ISO 15031-3.

The illustration shows a Type A OBD2 pin connector (Data Link Connector, DLC). Key aspects of the OBD2 connector specification include:

Location: Typically near the steering wheel, though its exact location can be hidden depending on the vehicle model.
Pin 16: Provides battery power, often active even when the ignition is off, a detail specified within the obd2 protocol specification.
Pinout: Varies depending on the communication protocol used, a critical aspect of the obd2 protocol specification.
CAN bus: In most modern vehicles, CAN bus is the lower-layer protocol, utilizing pins 6 (CAN-H) and 14 (CAN-L) as per the obd2 protocol specification.

OBD2 Connector Types: Type A vs. Type B Specification

The obd2 protocol specification recognizes different connector types, primarily Type A and Type B. Type A is standard in cars, while Type B is common in medium and heavy-duty vehicles.

Both types share similar OBD2 pinouts but differ in power supply outputs: 12V for Type A and 24V for Type B, as specified in the obd2 protocol specification. Baud rates also often differ, with cars typically using 500K and heavy-duty vehicles often using 250K (with increasing support for 500K).

Type B OBD2 connectors have a distinguishing interrupted groove in the middle, aiding in physical differentiation. Type B OBD2 adapter cables are compatible with both Type A and B sockets, while Type A adapters are not compatible with Type B sockets.

OBD2 and CAN Bus Specification [ISO 15765-4]

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in US vehicles, as mandated by ISO 15765, a critical part of the obd2 protocol specification.

ISO 15765-4 (Diagnostics over CAN or DoCAN) specifies restrictions on the CAN standard (ISO 11898) for OBD2 applications.

Specifically, it standardizes the CAN interface for test equipment, focusing on the physical, data link, and network layers within the obd2 protocol specification:

Bit-rate: CAN bus bit-rate must be 250K or 500K, as per the obd2 protocol specification.
CAN IDs: Supports both 11-bit and 29-bit CAN IDs within the obd2 protocol specification.
CAN IDs for Diagnostics: Specific CAN IDs are designated for OBD requests and responses, a defined aspect of the obd2 protocol specification.
Data length: Diagnostic CAN frame data length is fixed at 8 bytes, as per the obd2 protocol specification.
Cable length: OBD2 adapter cable length is limited to a maximum of 5 meters, a physical layer specification within the obd2 protocol specification.

OBD2 CAN Identifiers: 11-bit and 29-bit Addressing Specifications

OBD2 communication, as defined by the obd2 protocol specification, relies on request/response message exchanges.

11-bit CAN IDs are commonly used for OBD2 communication in most vehicles. ‘Functional Addressing’ uses CAN ID 0x7DF, broadcasting requests to all OBD2-compatible ECUs to check for data on the requested parameter (ISO 15765-4). ‘Physical Addressing’ uses CAN IDs 0x7E0-0x7E7 for targeted requests to specific ECUs, though less frequently used.

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

In some vehicles, particularly vans and light/medium/heavy-duty vehicles, 29-bit CAN identifiers are used for OBD2 communication instead of 11-bit IDs, another variation within the obd2 protocol specification.

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

Responses use CAN IDs from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is also represented in ‘J1939 PGN’ form as PGN 0xDA00 (55808), designated in the J1939-71 standard as ‘Reserved for ISO 15765-2’.

OBD2 vs. Proprietary CAN Protocols: Layered Protocol Specification

Vehicle ECUs operate using proprietary CAN protocols defined by the OEM, independent of OBD2. These OEM-specific CAN protocols are tailored to the vehicle brand, model, and year. Interpreting this proprietary data is generally not possible without OEM documentation or reverse engineering.

Connecting a CAN bus data logger to the OBD2 connector may reveal OEM-specific CAN data, typically broadcast at 1000-2000 frames/second. However, newer vehicles often employ a ‘gateway’ that restricts access to OEM CAN data via the OBD2 connector, allowing only OBD2 communication according to the obd2 protocol specification.

In essence, OBD2 functions as an ‘additional’ higher-layer protocol operating alongside the OEM-specific protocol. The obd2 protocol specification provides a standardized diagnostic interface on top of the vehicle’s core communication network.

Bit-rate and ID Validation: Protocol Configuration Specification

The obd2 protocol specification allows for two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in 4 possible combinations. Modern vehicles commonly use 500K and 11-bit IDs, but external tools must systematically validate these parameters.

ISO 15765-4 outlines a systematic initialization sequence to determine the correct combination. This method relies on the requirement that OBD2-compliant vehicles must respond to a mandatory OBD2 request (see OBD2 PID section) and that incorrect bit-rate transmissions will cause CAN error frames.

Newer ISO 15765-4 versions account for OBD communication via OBDonUDS versus OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on emission diagnostic service as per ISO 15031-5/SAE J1979) compared 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, test tools may send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). OBDonUDS-compliant vehicles should have ECUs that respond to this DID.

OBDonEDS (aka OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV vehicles, while WWH-OBD is mainly used in EU trucks/buses.

Five Lower-Layer OBD2 Protocols: Historical Protocol Specifications

While CAN is now dominant, the obd2 protocol specification historically included four other lower-layer protocols used in older vehicles (pre-2008). Pinouts can help identify the protocol in older vehicles:

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and widely used today, as per the current obd2 protocol specification.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ Asian cars, part of earlier obd2 protocol specification implementations.
ISO 9141-2: Used in EU, Chrysler & Asian cars in 2000-04, another protocol from older obd2 protocol specification versions.
SAE J1850 (VPW): Mostly used in older GM cars, a North American legacy protocol within the obd2 protocol specification history.
SAE J1850 (PWM): Mostly used in older Ford cars, another North American legacy protocol within the obd2 protocol specification history.

ISO-TP Specification for OBD2 Messaging [ISO 15765-2]

OBD2 messages, as defined by the obd2 protocol specification, are transported over CAN bus using ISO-TP (ISO 15765-2), a transport protocol enabling payloads exceeding 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 for these larger messages. More details are available in our intro to UDS.

For smaller OBD2 data that fits within a single CAN frame, ISO 15765-2 specifies ‘Single Frame’ (SF) usage. The first data byte (PCI field) indicates payload length (excluding padding), leaving 7 bytes for OBD2 communication.

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

Understanding the OBD2 diagnostic message structure is crucial for interpreting OBD2 communication according to the obd2 protocol specification. As defined by [SAE J1979, ISO 15031-5], a ‘Single Frame’ OBD2 CAN message comprises an identifier, data length (PCI field), and data. The data field is further structured into Mode, parameter ID (PID), and data bytes.

OBD2 Request/Response Example: Protocol in Action

Consider a request/response example for ‘Vehicle Speed’ to illustrate the obd2 protocol specification in action.

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

Referring to OBD2 PID 0x0D decoding rules, we find that 0x32 corresponds to a physical value of 50 km/h. This example demonstrates the request and response structure defined by the obd2 protocol specification.

The 10 OBD2 Services (Modes) Specification

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

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

In OBD2 messages, the mode is located in the 2nd byte. In requests, the mode is directly included (e.g., 0x01), while in responses, 0x40 is added to the mode (e.g., resulting in 0x41), a detail within the obd2 protocol specification.

OBD2 Parameter IDs (PIDs) Specification

Each OBD2 mode contains parameter IDs (PIDs), as specified in the obd2 protocol specification.

For example, mode 0x01 includes approximately 200 standardized PIDs for real-time data such as speed, RPM, and fuel level. However, vehicles typically support only a subset of these PIDs within each mode.

One PID, 0x00 in mode 0x01, is particularly significant. 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 fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for subsequent mode 0x01 PIDs.

OBD2 PID Overview Tool: Decoding Protocol Specifications

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

For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool can be used. This tool aids in constructing OBD2 request frames and dynamically decoding OBD2 responses, simplifying interaction with the obd2 protocol specification.

OBD2 PID overview tool

Practical OBD2 Data Logging and Decoding Based on Protocol Specification

This section provides a practical example of logging OBD2 data using the CANedge CAN bus data logger, demonstrating the application of the obd2 protocol specification.

The CANedge allows configuration of custom CAN frames for transmission, enabling OBD2 logging. It connects to vehicles via our OBD2-DB9 adapter cable.

Verifying bit-rate by sending a CAN frame at 500K

Reviewing responses to ‘Supported PIDs’ in asammdf

Step #1: Bit-rate, ID, and Supported PID Validation as per Protocol Specification

As per ISO 15765-4, you need to determine the bit-rate and IDs used by the vehicle. Use CANedge as follows (see CANedge Intro for details):

Test at 500K: Send a CAN frame at 500K and check for success (if not, try 250K).
Bit-rate Confirmation: Use the validated bit-rate for further communication.
Supported PID Requests: Send ‘Supported PIDs’ requests and examine responses.
ID Type Determination: Response IDs indicate 11-bit vs. 29-bit.
PID Support Check: Response data reveals supported PIDs, aligning with the obd2 protocol specification.

Plug & play configurations for these tests are available. Most post-2008 non-EV cars support 40-80 PIDs via 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

The asammdf GUI screenshot shows multiple responses to a single OBD request due to the 0x7DF request ID polling all ECUs. As all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are common. Subsequent ‘Supported PIDs’ requests receive fewer responses. The ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, reducing busload by targeting requests to this ECU using ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configuring OBD2 PID Requests Based on Protocol Specification

Once supported OBD2 PIDs, bit-rate, and CAN IDs are identified, configure your transmit list with relevant PIDs.

Considerations for configuration, based on the obd2 protocol specification:

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

With configuration complete, the device is ready to log raw OBD2 data according to the obd2 protocol specification!

Example CANedge OBD2 PID request list

DBC decoding and visualization of OBD2 data in asammdf

Step #3: DBC Decoding of Raw OBD2 Data as per Protocol Specification

For data analysis and visualization, decode raw OBD2 data into ‘physical values’ (e.g., km/h, °C).

Decoding information is in ISO 15031-5/SAE J1979 and online resources like Wikipedia. We offer a free OBD2 DBC file for easy DBC decoding of raw OBD2 data in most CAN bus software tools.

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

Signal identification requires CAN ID, OBD2 mode, and OBD2 PID. This ‘extended multiplexing’ is implemented in DBC files.

CANedge: OBD2 Data Logger Compliant with Protocol Specification

The CANedge facilitates easy OBD2 data recording to an 8-32 GB SD card. Connect to a vehicle to start logging and decode data using free software/APIs and our OBD2 DBC, ensuring compliance with the obd2 protocol specification.

OBD2 logger intro

CANedge

OBD2 Multi-Frame Examples: ISO-TP in Protocol Specification

OBD2 communication, as per the obd2 protocol specification, uses ISO-TP (transport protocol) as defined in ISO 15765-2. While single-frame communication is common, multi-frame examples illustrate the protocol’s capabilities for larger data sets.

Multi-frame OBD2 communication requires flow control frames (see our UDS intro). A static flow control frame transmitted ~50 ms after the initial request frame can manage this, as shown in the CANedge configuration example.

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

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval as per Protocol Specification

Vehicle Identification Number (VIN) retrieval, relevant for telematics and diagnostics, uses mode 0x09 and PID 0x02 as defined in the obd2 protocol specification.

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, i.e., 0x09 + 0x40), and PID (0x02). Byte 0x01 following the PID is the Number Of Data Items (NODI), here 1. The remaining 17 bytes are the VIN, convertible from HEX to ASC.

Example 2: OBD2 Multi-PID Request (6x) and Protocol Specification Limits

The obd2 protocol specification allows requesting up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU responds with data for supported PIDs (excluding unsupported ones), possibly across multiple frames via ISO-TP.

This efficient method increases data collection frequency but results in signal encoding specific to the request method, complicating generic OBD2 DBC file use. This approach is not generally recommended. The example trace below illustrates this:

The multi-frame response is similar to the VIN example, but includes requested PIDs and their data. PIDs are often ordered as requested, though not strictly required by ISO 15031-5.

DBC decoding of such responses is complex and not recommended for practical data logging unless using tools with specific built-in support. Extended multiplexing and payload position variations across vehicles complicate DBC generalization. Managing multiple multi-PID requests further challenges DBC-based decoding.

Custom scripts and recording transmit messages can help, interpreting responses based on requests, but these methods are difficult to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval as per Protocol Specification

OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’, retrieves emissions-related DTCs as per the obd2 protocol specification. No PID is included in the request. Responding ECUs indicate the number of stored DTCs (possibly 0), with each DTC occupying 2 data bytes. Multi-frame responses are necessary for more than 2 DTCs.

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. 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 Data Logging Use Cases Leveraging Protocol Specification

OBD2 data from cars and light trucks, accessed through adherence to the obd2 protocol specification, has diverse applications:

Logging data from cars

OBD2 data is used for fuel efficiency, driving improvement, prototype testing, and insurance applications.

obd2 logger

Real-time car diagnostics

OBD2 interfaces stream human-readable data for real-time vehicle issue diagnosis.

obd2 streaming

Predictive maintenance

IoT OBD2 loggers monitor vehicles in the cloud for predictive breakdown prevention.

predictive maintenance

Vehicle blackbox logger

OBD2 loggers serve as ‘black boxes’ for data in disputes or diagnostics.

can bus blackbox

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

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

Need to log/stream OBD2 data?

Get your OBD2 data logger today!

Buy now

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

[