Need to understand the OBD2 pinout? This guide provides a simple, practical introduction to the On-Board Diagnostic (OBD2) system, focusing on the crucial OBD2 connector pinout, OBD2 protocols, and how it all connects to your car’s data.
Note: This is a practical guide, so you’ll also learn about the OBD2 connector pin functions, common configurations, and what the OBD2 pinout means for diagnosing and accessing your vehicle’s data.
Discover why this is becoming a go-to resource for understanding the OBD2 pinout.
You can also watch our OBD2 intro video above – or get the PDF
In this article
Author: Martin Falch (updated January 2025)
Download as PDF
What is OBD2?
OBD2 is your car’s built-in diagnostic system. It’s a standardized protocol that allows you to retrieve diagnostic trouble codes (DTCs) and real-time data through the OBD2 connector. Understanding the OBD2 pinout is key to interfacing with this system.
You’ve likely already encountered OBD2:
Ever seen the malfunction indicator light on your dashboard?
That’s your car signaling an issue. Mechanics use an OBD2 scanner to pinpoint the problem. To do this, they connect an OBD2 reader to the OBD2 16 pin connector, usually located near the steering wheel. This tool sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’ containing data like speed, fuel level, or DTCs – crucial for efficient troubleshooting. The OBD2 pinout is the interface through which this communication happens.
Does my car support OBD2?
In short: Most likely!
Almost all modern non-electric cars are OBD2 compliant and often utilize CAN bus. For older vehicles, even with a 16-pin OBD2 connector present, OBD2 support isn’t guaranteed. Compliance can be estimated based on the car’s purchase location and date:
OBD2 history
OBD2 originated in California, driven by the California Air Resources Board (CARB) requirement for OBD in all new cars from 1991 onwards for emission control.
The Society of Automotive Engineers (SAE) recommended the OBD2 standard, standardizing DTCs and the OBD connector pinout across manufacturers (SAE J1962).
The OBD2 standard adoption unfolded in stages:
- 1996: OBD2 became mandatory in the USA for cars and light trucks.
- 2001: Required in the EU for gasoline cars.
- 2003: Required in the EU for diesel cars (EOBD).
- 2005: OBD2 required in the US for medium-duty vehicles.
- 2008: US cars mandated to use ISO 15765-4 (CAN) as the OBD2 foundation.
- 2010: OBD2 finally required in US heavy-duty vehicles.
OBD2 future
OBD2 is set to remain relevant, but its form is evolving.
Key trends to note:
Originally intended for emissions control, legislated OBD2 isn’t mandatory for electric vehicles. Consequently, most modern EVs don’t support standard OBD2 requests, opting instead for OEM-specific UDS communication. This makes data decoding from EVs challenging without reverse engineering – though some progress has been made, as seen in case studies for electric cars including Tesla, Hyundai/Kia, Nissan and VW/Skoda EVs.
OBD2 implementations 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) are emerging. These aim to enhance OBD communication using the UDS protocol. For more on these protocols, refer to our intro to UDS.
In today’s connected world, manual emission checks via OBD2 seem outdated. The proposed solution? OBD3 – integrating telematics into all cars.
OBD3 envisions adding a small radio transponder to vehicles, enabling the car’s VIN and DTCs to be wirelessly transmitted 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 cost-effective and convenient, OBD3 raises political concerns regarding surveillance.
Originally 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:
“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“
- Christoph Grote, SVP Electronics, BMW (2017)
The proposal is to disable OBD2 functionality during driving, centralizing data collection with manufacturers. This would give them control over ‘automotive big data’, argued on security grounds (e.g., reducing car hacking risks), though many see it as a commercial strategy [https://www.navixy.com/blog/obd-trackers-what-future-awaits/]. Whether this trend materializes remains to be seen, but it could significantly impact the OBD2 third-party service market.
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
On-board diagnostics, OBD2, is a higher-layer protocol (like a language). CAN is a communication method (like a phone). OBD2 is similar to other CAN-based higher-layer protocols like J1939, CANopen and NMEA 2000.
Specifically, OBD2 standards define the OBD2 connector pinout, lower-layer protocols, OBD2 parameter IDs (PIDs), and more. Understanding the OBD2 pinout is fundamental to working with OBD2 systems.
These standards can be viewed in a 7-layer OSI model. The following sections highlight the most important aspects, especially concerning the OBD2 connector pinout.
Notice in the OSI model that both SAE and ISO standards cover several layers, reflecting US (SAE) and EU (ISO) OBD standards. Some standards are technically very similar, such as SAE J1979 vs. ISO 15031-5 and SAE J1962 vs. ISO 15031-3, particularly regarding the OBD2 connector pinout.
The OBD2 connector [SAE J1962] and Pinout
The 16-pin OBD2 connector is your easy access point to your car’s data, standardized under SAE J1962 / ISO 15031-3. The OBD2 pinout, as defined in this standard, is crucial for ensuring compatibility and proper communication.
The illustration above shows a typical Type A OBD2 connector pinout (also known as the Data Link Connector, or DLC). Let’s break down key aspects of the OBD2 pinout:
- The connector is usually near the steering wheel, but can be hidden.
- Pin 16 provides battery power (often active even when the ignition is off).
- The OBD2 pinout configuration varies based on the communication protocol used by the vehicle.
- CAN bus is the most common lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are frequently used in the OBD2 pinout.
Here’s a table summarizing the common OBD2 pinout for Type A connectors:
| Pin | Name | Description |
|---|---|---|
| 1 | Manufacturer Discretionary | Often unused, manufacturer specific |
| 2 | SAE J1850 Bus+ | For PWM and VPW protocols |
| 3 | Manufacturer Discretionary | Often unused, manufacturer specific |
| 4 | Chassis Ground | Ground for the vehicle chassis |
| 5 | Signal Ground | Ground for signal circuits |
| 6 | CAN High (CAN-H) | CAN bus high signal |
| 7 | ISO 9141-2 K-Line | K-line for ISO 9141-2 and ISO 14230-4 |
| 8 | Manufacturer Discretionary | Often unused, manufacturer specific |
| 9 | Manufacturer Discretionary | Often unused, manufacturer specific |
| 10 | SAE J1850 Bus- | For PWM and VPW protocols |
| 11 | Manufacturer Discretionary | Often unused, manufacturer specific |
| 12 | Manufacturer Discretionary | Often unused, manufacturer specific |
| 13 | Manufacturer Discretionary | Often unused, manufacturer specific |
| 14 | CAN Low (CAN-L) | CAN bus low signal |
| 15 | ISO 9141-2 L-Line | L-line for ISO 9141-2 and ISO 14230-4 |
| 16 | Battery Power | Vehicle battery positive voltage |
OBD2 connector pinout – type A vs. B
You might encounter both Type A and Type B OBD2 connectors. Type A is typical in cars, while Type B is common in medium and heavy-duty vehicles. The OBD2 pinout is similar, but power supply and sometimes baud rates differ.
Type A and Type B share similar OBD2 pinouts but differ in power supply outputs (12V for Type A, 24V for Type B). Baud rates can also vary, with cars typically using 500K, and heavy-duty vehicles often using 250K (though 500K support is increasing).
Visually, Type B OBD2 connectors have an interrupted groove in the middle, distinguishing them from Type A. A Type B OBD2 adapter cable is compatible with both Type A and B sockets, while a Type A adapter will only fit Type A sockets. Understanding these OBD2 pinout variations is important for selecting the right equipment.
OBD2 and CAN bus [ISO 15765-4]
Since 2008, CAN bus has been mandatory for OBD2 in US cars as per ISO 15765. This standard impacts the OBD2 pinout usage, particularly pins 6 and 14 for CAN 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 test 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 is limited to 5 meters.
These specifications ensure reliable communication through the OBD2 pinout when using CAN bus.
OBD2 CAN identifiers (11-bit, 29-bit)
OBD2 communication always involves request/response messages. These messages are transmitted via the OBD2 pinout using specific CAN identifiers.
Most cars use 11-bit CAN IDs for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, which queries all OBD2-compatible ECUs for data on the requested parameter (ISO 15765-4). CAN IDs 0x7E0-0x7E7 can be used for ‘Physical Addressing’ requests to specific ECUs (less common).
ECUs respond with 11-bit IDs 0x7E8-0x7EF. The most common response ID is 0x7E8 (ECM, Engine Control Module), and to a lesser extent 0x7E9 (TCM, Transmission Control Module). These IDs are transmitted through the CAN pins in the OBD2 pinout.
Some vehicles, especially vans and medium/heavy-duty vehicles, use extended 29-bit CAN identifiers for OBD2 communication.
Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
Responses use CAN IDs 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is sometimes seen in ‘J1939 PGN’ form, specifically PGN 0xDA00 (55808), which J1939-71 standard marks as ‘Reserved for ISO 15765-2’. Again, the OBD2 pinout, specifically pins 6 and 14, carries these CAN signals.
OBD2 vs. proprietary CAN protocols
It’s important to understand that your car’s ECUs don’t rely on OBD2 for their primary functions. OEMs implement proprietary CAN protocols for vehicle control. These protocols are often specific to the vehicle brand, model, and year. This OEM-specific data may or may not be accessible through the OBD2 pinout.
Connecting a CAN bus data logger to your car’s OBD2 connector might reveal OEM-specific CAN data (typically broadcast at 1000-2000 frames/second). However, many newer cars use a ‘gateway’ that blocks access to this data via the OBD2 connector, only allowing OBD2 communication. The OBD2 pinout in these cases is primarily for standardized diagnostics.
Think of OBD2 as a standardized ‘add-on’ protocol running in parallel with the OEM-specific protocol. Both may be present on the OBD2 connector pinout, but access to the OEM data may be restricted.
Bit-rate and ID validation
OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern cars commonly use 500K and 11-bit IDs. External tools should systematically verify these parameters to ensure proper communication via the OBD2 pinout.
ISO 15765-4 recommends 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 OBD2 PID section) and that incorrect bit-rates cause CAN error frames. Proper OBD2 pinout connection is essential for this validation process.
Newer ISO 15765-4 versions account for OBD communication via OBDonUDS versus OBDonEDS. This article mainly focuses on OBD2/OBDonEDS (OBD on emission diagnostic service per ISO 15031-5/SAE J1979) rather than WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service per ISO 14229, ISO 27145-3/SAE J1979-2).
To test for OBDonEDS vs OBDonUDS, tools can send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). OBDonUDS-supporting vehicles should have ECUs that respond to this DID, again, communicated through the OBD2 pinout.
OBDonEDS (aka OBD2, SAE OBD, EOBD, or ISO OBD) is common in most non-EV cars today, while WWH-OBD is mainly used in EU trucks/buses.
Five lower-layer OBD2 protocols
CAN is the dominant lower-layer protocol for OBD2 today (ISO 15765). However, older cars (pre-2008) might use other protocols. The OBD2 pinout can sometimes hint at the protocol used.
Here are the five lower-layer protocols used for OBD2:
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and now widely used. Uses pins 6 and 14 in the OBD2 pinout.
- ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ cars, especially in Asia. Uses pin 7 (K-line) in the OBD2 pinout.
- ISO 9141-2: Used in EU, Chrysler & Asian cars (2000-04). Uses pins 7 (K-line) and 15 (L-line) in the OBD2 pinout.
- SAE J1850 (VPW): Mostly in older GM cars. Uses pin 2 in the OBD2 pinout.
- SAE J1850 (PWM): Mostly in older Ford cars. Uses pins 2 and 10 in the OBD2 pinout.
Transporting OBD2 messages via ISO-TP [ISO 15765-2]
OBD2 data communication over CAN bus uses ISO-TP (ISO 15765-2) as the transport protocol. This protocol is crucial when transmitting data payloads exceeding 8 bytes, like VIN or DTCs. ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages, all transmitted through the OBD2 pinout. For more details, see our intro to UDS.
Often, OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 uses ‘Single Frame’ (SF) format. The first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2 communication within the CAN frame, sent via the OBD2 pinout.
The OBD2 diagnostic message [SAE J1979, ISO 15031-5]
To understand OBD2 communication via CAN, consider a raw ‘Single Frame’ OBD2 CAN message. An OBD2 message consists of an identifier, data length (PCI field), and data. The data is structured into Mode, parameter ID (PID), and data bytes, all transmitted and received through the OBD2 pinout.
Example: OBD2 request/response
Consider a request/response example for ‘Vehicle Speed’.
An external tool sends a request message to the car with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds via CAN ID 0x7E8 with 3 payload bytes, including the Vehicle Speed value in the 4th byte, 0x32 (50 decimal). This entire exchange occurs via the OBD2 pinout.
Using OBD2 PID 0x0D decoding rules, the physical value is determined to be 50 km/h.
Next, we’ll explore OBD2 modes and PIDs in more detail, which are fundamental to interpreting data received through the OBD2 pinout.
The 10 OBD2 services (aka modes)
There are 10 standardized OBD2 diagnostic services (or modes). Mode 0x01 provides real-time data, while others are used for DTCs or freeze frame data. These modes are accessed via requests and responses through the OBD2 pinout.
Vehicles don’t need to support all OBD2 modes and might have 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 in responses, 0x40 is added to the mode (e.g., resulting in 0x41). These mode bytes are part of the data transmitted via the OBD2 pinout.
OBD2 parameter IDs (PID)
Each OBD2 mode contains parameter IDs (PIDs). Mode 0x01, for example, 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. Requests for specific PIDs are sent through the OBD2 pinout.
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. This makes PID 0x00 a useful ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to check support for other mode 0x01 PIDs. These PID requests and responses are central to OBD2 communication via the OBD2 pinout.
Tip: OBD2 PID overview tool
SAE J1979 and ISO 15031-5 appendices contain scaling information for standard OBD2 PIDs, enabling you to decode data into physical values (as explained in our CAN bus intro). This decoding process is applied to data received through the OBD2 pinout.
For quick lookup of mode 0x01 PIDs, use our OBD2 PID overview tool. It assists in constructing OBD2 request frames and dynamically decoding responses.
OBD2 PID overview tool
How to log and decode OBD2 data
Here’s a practical example of logging OBD2 data using the CANedge CAN bus data logger. Connecting the CANedge to your vehicle’s OBD2 pinout allows you to capture diagnostic data.
The CANedge allows custom CAN frame transmission, enabling OBD2 logging. Connect it to your vehicle using our OBD2-DB9 adapter cable for easy setup and data capture via the OBD2 pinout.
The responses to ‘Supported PIDs’ can be reviewed in asammdf
#1: Test bit-rate, IDs & supported PIDs
As discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a vehicle. Test this with CANedge as follows:
- Send a CAN frame at 500K and check for success (if not, try 250K).
- Use the verified bit-rate for further communication.
- Send multiple ‘Supported PIDs’ requests and analyze the responses received through the OBD2 pinout.
- Response IDs will indicate 11-bit or 29-bit.
- Response data reveals supported PIDs.
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 the OBD2/OBDonEDS protocol.
As shown in the asammdf GUI screenshot, multiple responses to a single OBD request are common when using the 0x7DF request ID, as it polls 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 will receive fewer responses. Notably, the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs in this example. Bus load can be reduced by specifically querying only this ECU using ‘Physical Addressing’ CAN ID 0x7E0 for subsequent communication via the OBD2 pinout.
#2: Configure OBD2 PID requests
After identifying supported PIDs, bit-rate, and CAN IDs, configure your transmit list with desired PIDs. Ensure proper configuration to leverage the OBD2 pinout effectively.
Consider these points:
- CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses.
- Spacing: Add 300-500 ms intervals between OBD2 requests (ECU spamming can cause no response).
- Battery drain: Use triggers to stop transmission when the vehicle is inactive to prevent ECU ‘wake-up’.
- Filters: Filter to record only OBD2 responses if OEM-specific CAN data is also present on the OBD2 pinout.
With these configurations, the device is ready to log raw OBD2 data from your vehicle’s OBD2 pinout.
An example list of CANedge OBD2 PID requests
asammdf lets you DBC decode and visualize OBD2 data
#3: DBC decode raw OBD2 data
To analyze and visualize logged data, decode the raw OBD2 data into ‘physical values’ (e.g., km/h, °C). This decoding is essential for making sense of the data captured via the OBD2 pinout.
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 data in most CAN bus software tools.
Decoding OBD2 data is more complex than standard CAN signals because different OBD2 PIDs use the same CAN ID (e.g., 0x7E8). CAN ID alone isn’t enough to identify the payload signals.
Solution: Use CAN ID, OBD2 mode, and OBD2 PID to identify signals. This ‘extended multiplexing’ is implementable in DBC files. Correctly interpreting data from the OBD2 pinout relies on this decoding.
CANedge: OBD2 data logger
The CANedge easily records OBD2 data to an 8-32 GB SD card. Connect to a car/truck via the OBD2 pinout to start logging. Decode data with free software/APIs and our OBD2 DBC.
OBD2 logger intro CANedge
OBD2 multi-frame examples [ISO-TP]
OBD2 communication, including multi-frame exchanges, uses ISO-TP (ISO 15765-2). Multi-frame communication is essential for data like VIN and DTCs, transmitted via the OBD2 pinout.
Multi-frame OBD2 requires flow control frames (see our UDS intro). Static flow control frames (e.g., 50 ms after the initial request) can be used, as shown in the CANedge configuration example.
Multi-frame OBD2 responses need CAN software/API tools with ISO-TP support, like CANedge MF4 decoders. These tools are crucial for processing data correctly received through the OBD2 pinout.
Example 1: OBD2 Vehicle Identification Number (VIN)
The Vehicle Identification Number (VIN) is important for telematics and diagnostics. Retrieve it via OBD2 using mode 0x09 and PID 0x02, communicated through the OBD2 pinout.
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, indicating Number Of Data Items (NODI), in this case 1. The remaining 17 bytes are the VIN, convertible from HEX to ASCII. This entire exchange happens via the OBD2 pinout.
Example 2: OBD2 multi-PID request (6x)
External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU responds with data for supported PIDs (unsupported PIDs omitted), possibly across multiple frames via ISO-TP. This data is transmitted via the OBD2 pinout.
This efficient method increases data collection frequency, but the signal encoding is request-specific, complicating generic OBD2 DBC file use. We advise against this method in practice. Here’s 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, which is common but not strictly required by ISO 15031-5. Interpreting these complex responses requires careful handling of data from the OBD2 pinout.
Decoding this response via DBC files is difficult. It involves extended multiplexing with multiple instances throughout the payload. Generalizing DBC across vehicles with varying supported PIDs becomes challenging. Handling multiple multi-PID requests further complicates DBC manipulation.
Workarounds involve custom scripts and recording transmit messages to interpret responses in context. However, these approaches are difficult to scale. Therefore, for practical OBD2 data logging via the OBD2 pinout, simpler, single-PID requests are generally recommended.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs)
Use OBD2 mode 0x03 (‘Show stored Diagnostic Trouble Codes’) to request emissions-related DTCs. No PID is 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. This communication occurs through the OBD2 pinout.
The 2-byte DTC value is split into two parts (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. Understanding DTCs is crucial for diagnosing vehicle issues based on data from the OBD2 pinout.
Example below shows a request to an ECU with 6 stored DTCs.
OBD2 data logging – use case examples
OBD2 data from cars and light trucks has many applications:
Logging data from cars
OBD2 data can reduce fuel costs, improve driving habits, test prototype parts, and inform insurance models. All this data is accessible via the OBD2 pinout.
obd2 logger
Real-time car diagnostics
OBD2 interfaces stream human-readable data in real-time, aiding vehicle issue diagnosis using data accessed through the OBD2 pinout.
obd2 streaming
Predictive maintenance
IoT OBD2 loggers monitor cars and trucks in the cloud to predict and prevent breakdowns, leveraging continuous data from the OBD2 pinout.
predictive maintenance
Vehicle blackbox logger
OBD2 loggers act as ‘black boxes’ for vehicles or equipment, providing data for disputes or diagnostics, all recorded from the OBD2 pinout.
can bus blackbox
Do you have an OBD2 data logging use case? Contact us for free consultation!
Contact us
For more introductions, see 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
[
