What is Data from an OBD2 Scanner Called? Decoding Vehicle Diagnostics

Need a simple, practical intro to OBD2 and understanding the data it provides?

In this guide, we’ll demystify the On-Board Diagnostic (OBD2) protocol, focusing on the crucial question: what is data from an OBD2 scanner called? We’ll cover everything from the OBD2 connector and OBD2 parameter IDs (PIDs) to its link with the CAN bus.

This isn’t just a theoretical overview; it’s a practical introduction designed to equip you with the knowledge to understand, request, and decode OBD2 data. We’ll explore key logging applications and offer practical tips to make you an OBD2 data expert.

Discover why this guide is becoming the #1 resource for understanding OBD2 data.

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

Understanding OBD2 and its Data

OBD2, or On-Board Diagnostics version 2, is essentially your car’s internal health monitoring system. It’s a standardized protocol that allows you to retrieve diagnostic trouble codes (DTCs) and, importantly, real-time data from your vehicle through the OBD2 connector. So, to answer the core question: the data from an OBD2 scanner is primarily called real-time data, diagnostic data, or more specifically, Parameter IDs (PIDs).

You’ve likely already encountered OBD2 in action. Ever seen the malfunction indicator light on your dashboard?

That light, often referred to as the “check engine light,” is your car signaling an issue. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the problem.

The mechanic connects the OBD2 reader to the OBD2 16 pin connector, typically located near the steering wheel. This tool sends ‘OBD2 requests’ to your car, and the car responds with ‘OBD2 responses’. These responses contain valuable information, including speed, fuel level, and Diagnostic Trouble Codes (DTCs). This data empowers mechanics and car enthusiasts alike to efficiently troubleshoot vehicle issues.

Understanding OBD2 data: Real-time information and diagnostic trouble codes are key outputs from an OBD2 scanner.

OBD2 Compatibility: Is Your Car Equipped?

In most cases, yes!

The vast majority of modern non-electric vehicles are OBD2 compliant, and many operate on the CAN bus network. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t guarantee OBD2 support. As scantool.net explains, compliance depends on where and when the car was initially purchased.

Here’s a quick guide to determine OBD2 compatibility:

OBD2 Compliance Guide: Check your car’s origin and purchase date to determine OBD2 compatibility.

A Brief History of OBD2

OBD2’s origins trace back to California. The California Air Resources Board (CARB) mandated OBD in all new vehicles starting from 1991 for emission control.

The Society of Automotive Engineers (SAE) further developed the OBD2 standard, standardizing DTCs and the OBD connector across various manufacturers (SAE J1962).

The OBD2 standard was progressively implemented:

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 as well (EOBD – European On-Board Diagnostics).
2005: OBD2 became mandatory in the US for medium-duty vehicles.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2.
2010: OBD2 was finally mandated in US heavy-duty vehicles.

OBD2 History: From emission control origins to widespread adoption in vehicles.

OBD2 Timeline: A visual overview of the evolution of On-Board Diagnostics.

OBD2 Future: Envisioning OBD3 with remote diagnostics and IoT integration.

The Future of OBD2

OBD2 is firmly established, but its future is evolving. Here are key trends to watch:

Originally designed for emissions control and testing, legislated OBD2 faces a changing landscape with electric vehicles. Interestingly, electric vehicles are not obligated to support OBD2 in its traditional form. In fact, most modern EVs bypass standard OBD2 requests, opting for OEM-specific UDS communication. This shift often makes it challenging to decode data from EVs unless decoding rules are reverse-engineered. However, there are successful cases of reverse engineering, as seen in studies for electric cars like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Limitations in data richness and lower-layer protocols in current OBD2 implementations are driving the development of modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). These protocols aim to improve OBD communication by utilizing the UDS protocol as a foundation. For deeper insight into these protocols, explore our introduction to UDS.

In our connected world, traditional OBD2 testing methods can feel outdated. Manual emission checks are time-consuming and costly. The proposed solution? OBD3 – integrating telematics into all vehicles.

OBD3 envisions adding a small radio transponder to all cars, similar to those used for bridge tolls. This would enable vehicles to transmit their vehicle identification number (VIN) and DTCs wirelessly to a central server for automated checks.

Many current devices, like the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger, already facilitate CAN or OBD2 data transfer via WiFi/cellular networks.

While this offers convenience and cost savings, it raises political and privacy concerns regarding surveillance.

Initially designed for stationary emission controls, OBD2 is now widely used by third parties to generate real-time data through OBD2 dongles, CAN loggers and similar devices. However, the German car industry is considering restricting this access.

As Christoph Grote, SVP Electronics at BMW, stated 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 involves disabling OBD2 functionality during driving and centralizing data collection with manufacturers. This would give manufacturers control over ‘automotive big data’.

Arguments for this shift include security enhancements, such as reducing the risk of car hacking. However, many view this as a commercially motivated move. The future of OBD2 data access remains uncertain, but it could significantly disrupt the market for third-party OBD2 services.

OBD2 Future Challenges: Electric vehicles and potential restrictions on data access.

Enhance Your CAN Bus Expertise

Want to become a CAN bus expert?

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

Download now

OBD2 Standards: A Layered Approach

On-board diagnostics, OBD2, operates as a higher-layer protocol (like a language) on top of communication methods like CAN (like a phone line). OBD2 is similar to other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

OBD2 standards define specifications for the OBD2 connector, lower-layer protocols, OBD2 Parameter IDs (PIDs), and more.

These standards can be visualized using the 7-layer OSI model. The following sections highlight the most crucial standards.

In the OSI model, you’ll notice that both SAE and ISO standards cover multiple layers. This reflects the development of OBD standards in the USA (SAE) and EU (ISO). Many standards are technically very similar, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.

OBD2 and CAN Bus in the OSI Model: Illustrating the layered architecture of OBD2 communication.

OBD2 Connector Pinout: Type A female socket Data Link Connector (DLC) diagram.

The OBD2 Connector [SAE J1962]

The 16-pin OBD2 connector is your gateway to accessing vehicle data, as specified in SAE J1962 / ISO 15031-3. This standard defines the physical interface for OBD2 communication.

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

Key features of the OBD2 connector:

Usually located near the steering wheel, but its exact location can vary and may be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout is protocol-dependent.
CAN bus is the most prevalent lower-layer protocol, typically utilizing pins 6 (CAN-H) and 14 (CAN-L).

OBD2 Connector Types: A vs. B

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

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

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

OBD2 Connector Types A and B: Differences in power supply and application.

OBD2 vs CAN Bus: CAN bus as a foundation for OBD2 communication.

OBD2 and CAN Bus [ISO 15765-4]

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all US-sold vehicles, according to ISO 15765.

ISO 15765-4 (Diagnostic communication over Controller Area Network – DoCAN) specifies constraints on the CAN standard (ISO 11898).

It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:

CAN bus bit-rate must be either 250K or 500K.
CAN IDs can be 11-bit or 29-bit.
Specific CAN IDs are designated for OBD requests and responses.
Diagnostic CAN frame data length is fixed at 8 bytes.
The OBD2 adapter cable must not exceed 5 meters.

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

OBD2 communication relies on request/response message exchanges.

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

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

Some vehicles, particularly vans and medium/heavy-duty vehicles, may use extended 29-bit CAN identifiers for OBD2 communication.

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 a ‘J1939 PGN’, specifically PGN 0xDA00 (55808), which is designated as ‘Reserved for ISO 15765-2’ in the J1939-71 standard.

OBD2 Request-Response Framework: Illustrating message exchange for data retrieval.

OBD2 vs Proprietary CAN Bus: Distinguishing standardized OBD2 data from OEM-specific data.

OBD2 vs. Proprietary CAN Protocols

It’s crucial to understand that vehicle ECUs do not depend on OBD2 for their core functions. Original Equipment Manufacturers (OEMs) implement their own proprietary CAN protocols for vehicle control and internal communication. These protocols are often unique to the vehicle brand, model, and year. Interpreting this OEM-specific data is generally not possible without reverse engineering.

Connecting a CAN bus data logger to your car’s OBD2 connector might capture OEM-specific CAN data, typically broadcast at 1000-2000 frames per second. However, many newer vehicles use a ‘gateway’ to block access to this proprietary CAN data via the OBD2 port, allowing only OBD2 communication.

Think of OBD2 as a separate, ‘add-on’ higher-layer protocol existing alongside the OEM-specific protocol. It’s designed for diagnostics and standardized data access, while the OEM protocol handles the vehicle’s core operations.

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, but diagnostic tools should systematically verify this.

ISO 15765-4 provides a recommended initialization sequence to determine the correct combination. This method relies on the fact that OBD2-compliant vehicles must respond to a mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit-rates cause CAN error frames.

Newer versions of ISO 15765-4 consider vehicles that may support OBD communication via OBDonUDS instead of 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 test for OBDonEDS versus OBDonUDS, tools may send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should have ECUs that respond to this DID.

In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars today, while WWH-OBD is mainly used in EU trucks/buses.

OBD2 Bit-rate and CAN ID Validation Flowchart: A systematic approach to protocol detection.

OBD2 Lower-Layer Protocols: CAN and legacy protocols used in OBD2 communication.

Five Lower-Layer OBD2 Protocols

While CAN is dominant today as per ISO 15765, older vehicles (pre-2008) may use other lower-layer protocols for OBD2. Understanding these protocols and their pinouts can be helpful when working with older cars.

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

Transporting OBD2 Messages via ISO-TP [ISO 15765-2]

OBD2 data is transmitted over CAN bus using the ISO-TP (ISO 15765-2) transport protocol. This protocol enables the transmission of data payloads exceeding 8 bytes, which is necessary for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. For more details, see our introduction to UDS.

However, often OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of ‘Single Frame’ (SF) messages. The first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2 communication.

ISO-TP Frame Types for OBD2: Single Frame, First Frame, Consecutive Frame, and Flow Control.

The OBD2 Diagnostic Message: PIDs and Modes [SAE J1979, ISO 15031-5]

To understand OBD2 on CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. In simple terms, an OBD2 message includes an identifier, data length (PCI field), and the data itself. The data is further structured into Mode, Parameter ID (PID), and data bytes.

OBD2 Message Structure: Breakdown of a raw OBD2 CAN frame.

Example: OBD2 Request/Response for Vehicle Speed

Consider this request/response example for the ‘Vehicle Speed’ parameter.

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

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

Let’s delve into OBD2 modes and PIDs.

OBD2 Request and Response Example: Retrieving Vehicle Speed using PID 0x0D.

OBD2 PID 0x0D (Vehicle Speed): Decoding the data into a physical value.

OBD2 Services (Modes): The 10 standardized diagnostic services available in OBD2.

The 10 OBD2 Services (Modes)

OBD2 defines 10 diagnostic services, also known as modes. Mode 0x01 is used for real-time data, while others are for Diagnostic Trouble Codes (DTCs), freeze frame data, and more.

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

In OBD2 messages, the mode is the 2nd byte. In requests, the mode is included directly (e.g., 0x01), while in responses, 0x40 is added to the mode value (e.g., resulting in 0x41).

OBD2 Parameter IDs (PIDs): The Names of OBD2 Data

Within each OBD2 mode, Parameter IDs (PIDs) specify the data being requested or reported. PIDs are essentially the names given to the data points available from an OBD2 scanner.

For example, mode 0x01 includes around 200 standardized PIDs providing real-time data like speed, RPM, and fuel level. However, vehicles typically support only a subset of the PIDs within a mode.

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 its support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs in blocks of 32 PIDs at a time.

OBD2 PIDs in Context: Parameter IDs as part of the OBD2 request-response framework.

OBD2 PID Overview Tool: A resource for exploring and understanding OBD2 Parameter IDs.

Tip: OBD2 PID Overview Tool

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

Our OBD2 PID overview tool is a helpful resource for looking up mode 0x01 PIDs. It aids in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

Logging and Decoding OBD2 Data: A Practical Guide

Let’s walk through a practical example of logging OBD2 data using the CANedge CAN bus data logger.

The CANedge allows custom CAN frame transmission, making it ideal for OBD2 logging.

Connect the CANedge to your vehicle using our OBD2-DB9 adapter cable for easy setup.

OBD2 Data Logger Setup: Connecting a CANedge data logger for OBD2 data capture.

Testing Bit-rate: Verifying successful CAN frame transmission at 500K.

Supported PIDs in asammdf: Reviewing responses to ‘Supported PIDs’ requests in asammdf.

#1: Bit-rate, ID, and Supported PID Testing

As discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a vehicle. The CANedge can be used for this testing as follows (see the CANedge Intro for details):

Transmit a CAN frame at 500K to check for success (if unsuccessful, try 250K).
Use the identified bit-rate for subsequent communication.
Send multiple ‘Supported PIDs’ requests and analyze the responses.
Determine 11-bit or 29-bit IDs based on response IDs.
Identify supported PIDs based on response data.

We provide plug-and-play configurations to simplify these tests.

Most 2008+ non-EV vehicles support 40-80 PIDs via 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

The asammdf GUI screenshot illustrates multiple responses to a single OBD request. This is because the 0x7DF request ID polls all ECUs for responses. As all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, multiple responses are common for this PID. Subsequent ‘Supported PIDs’ requests typically receive fewer responses. Notice that the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs. This means busload can be reduced by directing subsequent communication specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.

#2: Configuring OBD2 PID Requests

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

Consider these factors when configuring requests:

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

With these configurations, your device is ready to log raw OBD2 data!

CANedge OBD2 PID Request Example: A sample transmit list for requesting specific OBD2 PIDs.

OBD2 Data Visualization in asammdf: DBC decoded and visualized OBD2 data using asammdf.

#3: DBC Decoding of Raw OBD2 Data

To analyze and visualize logged data, you need to decode the raw OBD2 data into ‘physical values’ (e.g., km/h, °C).

Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. We also provide a free OBD2 DBC file to simplify DBC decoding in most CAN bus software tools.

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

The solution is to use the CAN ID, OBD2 mode, and OBD2 PID for signal identification. This is a form of multiplexing called ‘extended multiplexing‘, which can be implemented in DBC files.

CANedge: Your OBD2 Data Logging Solution

The CANedge makes OBD2 data recording to an 8-32 GB SD card easy. Simply connect it to a car or truck to start logging and decode data using free software/APIs and our OBD2 DBC.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples [ISO-TP]

OBD2 communication uses ISO-TP (transport protocol) as per ISO 15765-2. While most examples have been single-frame, multi-frame communication is essential for larger data sets.

Multi-frame OBD2 communication requires flow control frames (see our UDS intro). In practice, a static flow control frame can be transmitted approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example.

Analyzing multi-frame OBD2 responses requires CAN software/API tools that support ISO-TP, like the CANedge MF4 decoders.

OBD2 Multi-frame Request Example: Requesting Vehicle Identification Number (VIN).

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval

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

The tool sends a Single Frame request with PCI field (0x02), 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). Following the PID is byte 0x01, the Number Of Data Items (NODI), in this case 1 (ISO 15031-5 / SAE J1979). The subsequent 17 bytes represent the VIN, convertible from HEX to ASCII.

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 (excluding unsupported ones), potentially using multiple frames via ISO-TP.

This method increases data collection efficiency, but signal encoding becomes request-specific, complicating generic OBD2 DBC file use. We generally advise against this method in practice. Here’s an example trace:

The multi-frame response resembles the VIN example but includes requested PIDs and their corresponding data. PIDs are often ordered as requested, but this is not strictly mandated 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. It involves extended multiplexing with payload position variations, making generic DBC files difficult to apply across different vehicles. Custom scripts and recording request messages can offer workarounds, but these are challenging to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval

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

The 2-byte DTC value is structured according to 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 response from an ECU with 6 stored DTCs.

OBD2 DTC Decoding: Interpreting Diagnostic Trouble Code data structure.

OBD2 Data Logging Use Cases

OBD2 data from cars and light trucks has diverse applications:

Car Data Logging

OBD2 data can be used for fuel efficiency improvement, driving behavior analysis, prototype testing, and insurance applications.
obd2 logger

Real-time Car Diagnostics

OBD2 interfaces enable real-time streaming of human-readable OBD2 data for vehicle issue diagnosis.
obd2 streaming

Predictive Maintenance

IoT OBD2 loggers can monitor vehicles in the cloud to predict and prevent breakdowns.
predictive maintenance

Vehicle Black Box Logging

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

Have an OBD2 data logging application? Contact us for a free consultation!
Contact us

Explore more introductions 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

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN