OBD2 Port Numbers Explained: Your Guide to Pinouts and Standards

Want to understand the Obd2 Port Numbers in your car?

This comprehensive guide dives deep into the On-Board Diagnostic (OBD2) port, focusing specifically on the OBD2 port numbers, pinouts, and related standards. We’ll break down the complexities of the 16-pin OBD2 connector, explaining what each pin is for and how it relates to vehicle diagnostics and communication protocols.

If you’re looking to understand your car’s diagnostic port, whether for DIY repairs, data logging, or simply to understand how mechanics communicate with your vehicle, this guide is for you.

Learn below why this has become the go-to resource for understanding OBD2 port numbers.

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

Demystifying the OBD2 Port: More Than Just a Connector

The OBD2 port is your car’s gateway to its internal diagnostic system. It’s a standardized 16-pin connector that allows access to a wealth of information, from engine performance data to diagnostic trouble codes (DTCs). Understanding the OBD2 port numbers – the function of each pin – is crucial for anyone working with vehicle diagnostics.

You’re likely familiar with the check engine light on your dashboard. This light signals an issue detected by your car’s onboard computer. Mechanics use an OBD2 scanner to pinpoint these issues by connecting to the OBD2 16 pin connector, typically located near the steering wheel. This connection allows the scanner to send ‘OBD2 requests’ and receive ‘OBD2 responses’ containing valuable data like speed, fuel level, and DTCs. But behind this simple connection lies a standardized system of port numbers, each with a specific purpose.

Understanding the OBD2 system and its malfunction indicator light is the first step in vehicle diagnostics.

OBD2 Port Compatibility: Is Your Car Equipped?

The good news is, most likely, yes!

Nearly all modern non-electric cars are equipped with an OBD2 port and often utilize CAN bus for communication. However, with older vehicles, even if you spot a 16-pin OBD2 connector, it might not fully support OBD2. A key indicator of OBD2 compliance is the vehicle’s purchase location and year:

Check this guide to determine if your car is OBD2 compliant based on region and year of purchase.

A Brief History of OBD2 and Its Port Standardization

OBD2 originated in California, driven by the California Air Resources Board (CARB) requirement for OBD systems in all new cars from 1991 onwards for emission control.

The Society of Automotive Engineers (SAE) recommended the OBD2 standard, which included standardized DTCs and, importantly, the OBD connector and its pin assignments across all manufacturers, documented in SAE J1962.

The OBD2 standard adoption unfolded progressively:

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

The history of OBD2 is closely tied to emission control regulations and standardization across vehicle manufacturers.

A timeline illustrating the key milestones in the development and adoption of OBD2 standards worldwide.

The future of OBD may involve remote diagnostics and integration with cloud-based services for enhanced vehicle monitoring.

The Future of OBD2: Adapting to Modern Vehicles

OBD2 is firmly established, but its evolution is ongoing.

Here are key trends shaping its future:

While legislated OBD2 was initially for emissions control, electric vehicles (EVs) aren’t obligated to support it. Most modern EVs bypass standard OBD2 requests, opting for OEM-specific UDS communication. This shift makes accessing data from EVs challenging without reverse-engineering efforts. However, there are successful cases of data decoding from EVs like Tesla, Hyundai/Kia, Nissan, and VW/Skoda.

Recognizing OBD2’s limitations in data richness and protocol variety, alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These aim to improve OBD communication using the UDS protocol as a foundation. For more on these protocols, see our UDS protocol intro.

In our connected world, manual OBD2 checks seem outdated. OBD3, incorporating telematics, is a potential solution. 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 or the CANedge3 3G/4G CAN logger already facilitate data transfer via WiFi/cellular. While convenient and cost-saving, OBD3 raises privacy concerns.

Historically, OBD2 was for repair shop servicing. However, its widespread use for real-time data generation by third parties via OBD2 dongles, CAN loggers and similar devices is being challenged. The German car industry proposes to limit third-party access, suggesting “turning off” OBD2 while driving and centralizing data collection with manufacturers. This move, intended to enhance security and control automotive data, is viewed by some as commercially motivated and could disrupt the OBD2 third-party service market.

Electric vehicles are increasingly moving away from traditional OBD2, opting for proprietary diagnostic protocols.

Enhance Your CAN Bus Expertise

Eager to become a CAN bus expert?

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

Download now

OBD2 Standards: Pinpointing the Port Numbers and Protocols

On-board diagnostics, OBD2, operates as a higher layer protocol, much like a language, while CAN bus serves as the communication method, akin to a phone line. OBD2 is comparable to other CAN-based protocols such as J1939, CANopen, and NMEA 2000.

OBD2 standards define the OBD2 connector port numbers (pinouts), lower-layer protocols, OBD2 parameter IDs (PIDs), and more. These standards are structured within a 7-layer OSI model. Notably, both SAE and ISO standards cover several layers, reflecting OBD standards in the USA (SAE) and EU (ISO). Many standards are technically similar, such as SAE J1979 versus ISO 15031-5 and SAE J1962 versus ISO 15031-3.

The OSI model illustrates how OBD2 and CAN bus standards interact across different communication layers.

A detailed pinout diagram of the OBD2 connector, highlighting the function of each port number.

Decoding the OBD2 Connector: SAE J1962 and Port Number Functions

The 16-pin OBD2 connector, standardized by SAE J1962 / ISO 15031-3, provides easy access to vehicle data. This standard is crucial for understanding OBD2 port numbers and their functions.

The illustration shows a Type A OBD2 pin connector (Data Link Connector, DLC). Key points regarding the OBD2 port numbers include:

The connector is typically near the steering wheel, but its exact location can vary.
Pin 16 is dedicated to battery power supply, often active even when the ignition is off.
The OBD2 pinout, or the function of each port number, depends on the communication protocol used.
CAN bus, the most common lower-layer protocol, typically utilizes pins 6 (CAN-High) and 14 (CAN-Low).

OBD2 Connector Types: A vs. B and Port Number Variations

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

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

Visually, Type B connectors have an interrupted groove in the middle, distinguishing them from Type A. Type B OBD2 adapter cables are compatible with both Type A and B sockets, but Type A adapters will not fit into Type B sockets. Understanding these connector types and their pinout variations is key when working with different vehicle classes.

Understanding the differences between OBD2 connector Type A and Type B is crucial for compatibility and power considerations.

This diagram illustrates the relationship between OBD2 and CAN bus within the ISO15765 framework.

OBD2 and CAN Bus: ISO 15765-4 and Port Number Communication

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in US vehicles, as per ISO 15765. This standard heavily influences how OBD2 port numbers are utilized for communication.

ISO 15765-4 (Diagnostics over CAN or DoCAN) specifies restrictions on the CAN standard (ISO 11898) for OBD2. 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 are reserved for OBD requests/responses.
Diagnostic CAN frame data length is fixed at 8 bytes.
OBD2 adapter cable length must not exceed 5 meters.

OBD2 CAN Identifiers: 11-bit, 29-bit and Port Number Addressing

OBD2 communication is built around request/response message exchanges through the OBD2 port numbers assigned for CAN communication (pins 6 and 14).

In most cars, 11-bit CAN IDs are used for OBD2. ‘Functional Addressing’ ID 0x7DF queries 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 frequent response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module).

Some vehicles, particularly vans and medium/heavy-duty vehicles, use extended 29-bit CAN identifiers for OBD2 communication instead of 11-bit IDs, still utilizing the designated OBD2 port numbers for CAN.

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

Understanding the request and response frame structure is key to interpreting data transmitted through the OBD2 port numbers.

OBD2 operates alongside proprietary CAN bus protocols, providing a standardized interface for diagnostics while OEM systems handle vehicle control.

OBD2 vs. Proprietary CAN Protocols: Parallel Systems via the Same Port

It’s important to note that your car’s ECUs operate using OEM-specific proprietary CAN protocols, independent of OBD2, even though both systems might utilize the same physical OBD2 port numbers (pins 6 and 14 for CAN). These OEM protocols are brand, model, and year-specific. Interpreting this proprietary data is typically not possible without OEM tools or reverse engineering.

Connecting a CAN bus data logger to your OBD2 port may capture OEM-specific CAN data, often broadcast at 1000-2000 frames/second. However, newer cars often implement a ‘gateway’ that restricts OBD2 port access to OBD2 communication only, blocking OEM data.

Think of OBD2 as a parallel, ‘extra’ higher-layer protocol operating through the OBD2 port alongside the OEM-specific protocol.

Bit-rate and ID Validation: Ensuring Correct Port Number Communication

OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in 4 potential combinations for communication via the OBD2 port numbers assigned to CAN. Modern cars commonly use 500K and 11-bit IDs, but diagnostic tools should systematically validate this.

ISO 15765-4 outlines a systematic initialization sequence to determine the correct combination, illustrated in the flowchart. This method relies on the mandatory OBD2 response to a specific request (see OBD2 PID section) and the detection of CAN error frames caused by incorrect bit-rates.

Newer ISO 15765-4 versions consider OBD communication via OBDonUDS in addition to OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on emission diagnostic service as per ISO 15031-5/SAE J1979) versus WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).

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

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

A flowchart illustrating the process of validating bit-rate and CAN ID combinations for establishing OBD2 communication through the port.

An overview of the five lower-layer protocols used in OBD2, including CAN and older standards, and their relationship to OBD2 port numbers.

Five Lower-Layer OBD2 Protocols: Beyond CAN and Port Number Pinouts

While CAN (ISO 15765) is dominant in modern OBD2 systems and utilizes specific OBD2 port numbers (pins 6 and 14), older cars (pre-2008) might use one of four other lower-layer protocols. Understanding these protocols and their corresponding OBD2 port number assignments is important for diagnosing older vehicles. The pinouts themselves can help identify the protocol in use:

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

ISO-TP: Transporting OBD2 Messages Through the Port

OBD2 data, communicated via the OBD2 port, uses ISO-TP (ISO 15765-2) transport protocol over CAN bus. ISO-TP enables transmission of payloads exceeding 8 bytes, 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. See our UDS intro for details.

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

Understanding ISO-TP frame types is crucial for interpreting multi-frame OBD2 messages transmitted through the port.

The OBD2 Diagnostic Message: Port Number Data Structure

To understand OBD2 communication via the port, consider a ‘Single Frame’ OBD2 CAN message. In simplified terms, it comprises an identifier, data length (PCI field), and data. The data section includes Mode, parameter ID (PID), and data bytes.

This diagram breaks down the structure of an OBD2 message, showing the arrangement of mode, PID, and data bytes within the CAN frame.

Example: OBD2 Request/Response via the Diagnostic Port

Consider a ‘Vehicle Speed’ parameter request/response example to illustrate OBD2 port communication.

An external tool sends a request to the car via the OBD2 port (pins 6 and 14) with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds through the same OBD2 port numbers with CAN ID 0x7E8 and 3 payload bytes, including the Vehicle 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 delve into OBD2 modes and PIDs and how they are accessed via the OBD2 port numbers.

This illustrates a request and response sequence for vehicle speed, showing CAN IDs and data flow through the OBD2 port.

A detailed example of OBD2 PID 0x0D (Vehicle Speed), demonstrating how data is encoded and interpreted.

An overview of the 10 OBD2 service modes, each designed for specific diagnostic functions accessible via the OBD2 port.

The 10 OBD2 Services (Modes) and Port Number Interactions

OBD2 defines 10 diagnostic services (modes). Mode 0x01 provides real-time data, while others handle diagnostic trouble codes (DTCs) or freeze frame data, all accessed through the OBD2 port.

Vehicles aren’t required to support all 10 OBD2 modes and might include OEM-specific modes beyond these standards.

In OBD2 messages transmitted via the port, the mode is the 2nd byte. In requests, the mode is direct (e.g., 0x01), but in responses, 0x40 is added to the mode (e.g., resulting in 0x41).

OBD2 Parameter IDs (PIDs) and Diagnostic Port Access

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 typically support only a subset of PIDs within each mode, accessible through the OBD2 port.

One PID is particularly important: mode 0x01 PID 0x00. If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to this PID, the ECU indicates support for PIDs 0x01-0x20. Thus, PID 0x00 acts as a basic ‘OBD2 compatibility test’ via the diagnostic port. PIDs 0x20, 0x40, …, 0xC0 similarly determine support for subsequent mode 0x01 PIDs.

This diagram reiterates the request and response frame structure in OBD2 communication, emphasizing the role of PIDs in data requests via the port.

An OBD2 PID overview tool, useful for exploring and understanding the parameter IDs available in service mode 01.

Tip: OBD2 PID Overview Tool for Port Data Interpretation

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

For mode 0x01 PID lookups, our OBD2 PID overview tool is invaluable. It aids in constructing OBD2 request frames and dynamically decoding OBD2 responses received through the port.

OBD2 PID overview tool

Logging and Decoding OBD2 Data from the Diagnostic Port

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

The CANedge allows configuration of custom CAN frames for transmission, making it suitable for OBD2 logging. Connection to your vehicle is simple using our OBD2-DB9 adapter cable, interfacing directly with the OBD2 port numbers.

Illustrating how an OBD2 data logger requests PID data through the OBD2 port and receives responses.

Reviewing responses to ‘Supported PIDs’ requests in asammdf to identify vehicle capabilities.

#1: Bit-rate, IDs & Supported PIDs Verification via OBD2 Port

ISO 15765-4 guides the process of determining vehicle-specific bit-rates and IDs. Use CANedge to test this (see CANedge Intro):

Send a CAN frame at 500K to the OBD2 port and check for success (if not, try 250K).
Use the verified bit-rate for subsequent OBD2 port communication.
Send multiple ‘Supported PIDs’ requests and analyze responses.
Response IDs indicate 11-bit or 29-bit CAN ID usage via the OBD2 port.
Response data reveals supported PIDs.

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

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-compliant ECUs must support service 0x01 PID 0x00, many responses to this PID are typical. Subsequent ‘Supported PIDs’ requests receive fewer ECU responses. The ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, allowing for reduced busload by directing requests to this ECU using ‘Physical Addressing’ CAN ID 0x7E0 for subsequent communication via the OBD2 port.

#2: Configuring OBD2 PID Requests for Data Logging via the Port

After identifying supported PIDs, bit-rate, and CAN IDs, configure your transmit list with relevant PIDs for logging data from the OBD2 port.

Consider these points:

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

With configuration complete, your device is set to log raw OBD2 data from the port!

An example list of CANedge OBD2 PID requests configured for data logging via the OBD2 port.

asammdf software allows DBC decoding and visualization of OBD2 data logged from the port.

#3: DBC Decoding of Raw OBD2 Port Data

To analyze and visualize logged data, decode raw OBD2 data into ‘physical values’ (km/h, °C). Decoding information is in ISO 15031-5/SAE J1979 (and Wikipedia). We provide a free OBD2 DBC file for easy DBC decoding of raw OBD2 port data in most CAN bus software tools.

Decoding OBD2 data is more complex than regular CAN signals because different OBD2 PIDs use the same CAN ID (e.g., 0x7E8). The CAN ID alone isn’t sufficient to identify payload signals.

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

CANedge: Your OBD2 Data Logger for Port Monitoring

The CANedge simplifies OBD2 data recording to an 8-32 GB SD card. Simply connect it to a vehicle’s OBD2 port to start logging and use free software/APIs and our OBD2 DBC for data decoding.

OBD2 logger intro CANedge

OBD2 Multi-Frame Examples: ISO-TP Communication via the Port

OBD2 communication, including multi-frame exchanges, utilizes ISO-TP transport protocol as per ISO 15765-2 through the OBD2 port. Most examples so far have been single-frame. Here, we provide multi-frame communication examples.

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

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

Example of a multi-frame request message for retrieving the Vehicle Identification Number via the OBD2 port.

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

The Vehicle Identification Number (VIN) is crucial for telematics and diagnostics (see our UDS intro). To get the VIN using OBD2 requests via the port, use mode 0x09 and PID 0x02:

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

The vehicle responds with a First Frame containing PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is byte 0x01 (Number Of Data Items – NODI), in this case 1 (ISO 15031-5 / SAE J1979). The remaining 17 bytes are the VIN, convertible from HEX to ASC.

Example 2: OBD2 Multi-PID Request (6x) via the Diagnostic Port

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

This feature enhances data collection frequency and efficiency but complicates signal encoding, making generic OBD2 DBC files less useful. We advise against this method practically. Below is an example trace:

The multi-frame response resembles the VIN example, but the payload includes requested PIDs and their data. PIDs are often ordered as requested, common but not ISO 15031-5 standard requirement.

DBC decoding is challenging, so this approach is not recommended for practical data logging unless using tools with specific built-in support. It involves extended multiplexing with payload position-specific PID encoding, complicating DBC generalization across vehicles with varying PID support. Managing multiple multi-PID requests further complicates DBC handling.

Workarounds include custom scripts and recording transmit messages to interpret responses in conjunction with requests, but these are difficult to scale.

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

OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’, retrieves emissions-related DTCs via the OBD2 port. No PID is in the request. Targeted ECUs respond with the number of stored DTCs (possibly 0), each DTC being 2 data bytes. Multi-frame responses are necessary for more than 2 DTCs.

The 2-byte DTC value is structured per ISO 15031-5/ISO 15031-6. The first 2 bits define ‘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 DTCs stored, retrieved through the OBD2 port.

Visual representation of OBD2 DTC decoding, showing the structure of DTC codes and their interpretation.

OBD2 Data Logging Use Cases: Leveraging Port Data

OBD2 data from cars and light trucks, accessed through the OBD2 port, has diverse applications:

Car Data Logging

OBD2 data aids in reducing fuel costs, improving driving habits, testing prototype parts, and insurance applications.

obd2 logger

Real-time Car Diagnostics

OBD2 interfaces enable real-time streaming of human-readable OBD2 data for diagnosing vehicle issues.

obd2 streaming

Predictive Maintenance

IoT OBD2 loggers in the cloud monitor cars and light trucks for predictive maintenance, preventing breakdowns.

predictive maintenance

Vehicle Black Box Logger

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

can bus blackbox

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

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

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

[