How to Log OBD2 Channels: Your Comprehensive Guide to Vehicle Data Acquisition

Are you looking to tap into the wealth of data hidden within your vehicle’s computer? Understanding and logging OBD2 channels is the key to unlocking valuable insights into your car’s performance, health, and driving habits. This guide provides a practical and in-depth look at How To Log Obd2 Channels, making it the #1 resource for enthusiasts, mechanics, and engineers alike.

Whether you’re a seasoned automotive technician or a curious car owner, mastering OBD2 logging opens up a world of possibilities. From diagnosing engine problems to optimizing fuel efficiency and even tracking vehicle performance on the track, the data available through OBD2 is invaluable.

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

Understanding OBD2: The Basics of On-Board Diagnostics

OBD2, or On-Board Diagnostics II, is essentially your car’s internal health monitoring system. It’s a standardized protocol implemented in most modern vehicles that allows you to access diagnostic trouble codes (DTCs) and a wide range of real-time data through the OBD2 connector.

You’ve likely encountered OBD2 in action without even realizing it. Remember that “check engine light” or malfunction indicator light (MIL) on your dashboard? That’s OBD2 signaling a potential issue. When you take your car to a mechanic, they use an OBD2 scanner to understand what’s wrong.

This process involves connecting an OBD2 reader to the OBD2 16 pin connector, typically located near the steering wheel. The scanner sends “OBD2 requests” to the vehicle’s computer, and the car responds with “OBD2 responses.” These responses contain crucial data like speed, fuel level, and DTCs, enabling faster and more accurate troubleshooting.

OBD2 Compatibility: Does Your Car Support Data Logging?

The question often arises: “Does my car even support OBD2 data logging?” The simple answer is: Almost certainly, yes!

Nearly all non-electric vehicles manufactured in recent decades are OBD2 compliant, and most utilize the CAN bus communication protocol. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t guarantee full OBD2 support. To confirm compliance, consider the vehicle’s origin and year of manufacture:

A Brief History of OBD2: From Emission Control to Data Access

The history of OBD2 is rooted in California, where the California Air Resources Board (CARB) mandated OBD systems in all new cars from 1991 onwards for emission control.

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

The OBD2 standard was gradually implemented globally:

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

The Future of OBD2: Trends and Challenges in Vehicle Data Access

While OBD2 is firmly established, its future is evolving. Here are some key trends shaping the landscape:

Originally designed for emission control and testing, legislated OBD2 faces new challenges with the rise of electric vehicles. Electric vehicles (EVs) are not mandated to support OBD2, and in practice, most modern EVs don’t implement standard OBD2 requests. Instead, they often use OEM-specific UDS communication protocols, making data access difficult without reverse engineering efforts. However, successful reverse engineering has been demonstrated in case studies for brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Limitations in data richness and lower-layer protocols in traditional OBD2 have spurred the development of alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). These aim to enhance OBD communication using the UDS protocol as a foundation. For a deeper dive into these protocols, explore our introduction to UDS.

In the age of connected cars, manual emission control checks via OBD2 seem outdated. OBD3 proposes a solution by incorporating telematics into all vehicles. This would involve adding a small radio transponder to cars, allowing for wireless transmission of the vehicle identification number (VIN) and DTCs to a central server via WiFi 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 political concerns regarding surveillance.

Originally intended for stationary emission controls, OBD2 is now widely used by third parties for real-time data generation via OBD2 dongles, CAN loggers and similar tools. However, the German car industry is advocating for restricting this access. Their proposal involves disabling OBD2 functionality during driving and centralizing data collection with manufacturers, giving them control over ‘automotive big data’.

BMW’s SVP Electronics, Christoph Grote, 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“.

Arguments for this change center on security, such as reducing the risk of car hacking, though many perceive it as a commercially motivated move. The future of third-party OBD2 access remains uncertain and could significantly impact the market for OBD2-based services.

Enhance Your CAN Bus Expertise

Want to become a CAN bus expert?

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

Download now

OBD2 Standards: Defining the Framework for Vehicle Diagnostics

On-board diagnostics OBD2 operates as a higher-layer protocol – a language for vehicle communication. CAN (Controller Area Network) bus serves as the communication method, similar to a phone line. This places OBD2 alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

OBD2 standards encompass various aspects, including the OBD2 connector, lower-layer communication protocols, OBD2 parameter IDs (PIDs), and more.

These standards can be visualized using the 7-layer OSI model. Notably, both SAE (US standards) and ISO (EU standards) cover multiple layers, reflecting the global standardization effort. Many standards are technically equivalent, such as SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3.

The OBD2 Connector [SAE J1962]: Your Gateway to Vehicle Data

The 16-pin OBD2 connector, standardized in SAE J1962 / ISO 15031-3, provides easy access to your vehicle’s data.

The illustration shows a typical Type A OBD2 pin connector, also known as a Data Link Connector (DLC). Key points to note:

The connector is usually near the steering wheel, but its exact location may vary and be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout configuration depends on the communication protocol used.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are typically connected.

OBD2 Connector Types: Type A vs. Type B

You might 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 share similar OBD2 pinouts, they differ in power supply outputs (12V for Type A, 24V for Type B) and often in baud rates (cars typically use 500K, heavy-duty vehicles often 250K, with recent support for 500K).

Type B OBD2 connectors have a distinguishing interrupted groove in the middle. A Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, whereas a Type A adapter will not fit a Type B socket.

OBD2 and CAN Bus [ISO 15765-4]: The Communication Foundation

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all US cars, as per ISO 15765.

ISO 15765-4, also known as Diagnostics over CAN or DoCAN, specifies restrictions applied to 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 length must not exceed 5 meters.

OBD2 CAN Identifiers (11-bit, 29-bit): Addressing Vehicle ECUs

OBD2 communication always involves request/response message pairs.

In most cars, 11-bit CAN IDs are used for OBD2. The ‘Functional Addressing’ ID, 0x7DF, queries all OBD2-compatible ECUs to check if they have data for the requested parameter (as defined in ISO 15765-4). ‘Physical Addressing’ requests to specific ECUs can be made using CAN IDs 0x7E0-0x7E7, though this is less common.

ECUs respond with 11-bit IDs ranging from 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 light/medium/heavy-duty vehicles, may utilize extended 29-bit CAN identifiers for OBD2 communication instead of 11-bit IDs.

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

OBD2 vs. Proprietary CAN Protocols: Navigating Vehicle Networks

It’s crucial to understand that your car’s electronic control units (ECUs) operate using proprietary CAN protocols defined by the original equipment manufacturer (OEM), independently of OBD2. These OEM-specific CAN protocols are unique to vehicle brands, models, and years. Interpreting this data is typically not possible without OEM documentation or reverse engineering.

Connecting a CAN bus data logger to your OBD2 port may reveal OEM-specific CAN data, often broadcast at high rates (1000-2000 frames/second). However, many newer vehicles employ a ‘gateway’ that restricts access to this CAN data, allowing only OBD2 communication through the OBD2 connector.

In essence, OBD2 functions as an ‘additional’ higher-layer protocol operating alongside the OEM-specific communication network.

Bit-rate and ID Validation for Robust OBD2 Logging

OBD2 can utilize two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern cars commonly use 500K and 11-bit IDs, but robust OBD2 logging tools should systematically verify these parameters.

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

Newer versions of ISO 15765-4 account for vehicles supporting OBD communication via OBDonUDS rather than 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).

Testing for 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). Vehicles supporting OBDonUDS must have ECUs that respond to this DID.

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

Five Lower-Layer OBD2 Protocols: A Historical Perspective

While CAN (ISO 15765) is the dominant lower-layer protocol for OBD2 today, especially in vehicles post-2008, older cars may utilize other protocols. Understanding these is helpful when working with pre-2008 vehicles. The pinouts of the OBD2 connector can sometimes indicate 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+ cars, particularly in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian cars around 2000-2004.
SAE J1850 (VPW): Primarily used in older GM vehicles.
SAE J1850 (PWM): Primarily used in older Ford vehicles.

Transporting OBD2 Messages via ISO-TP [ISO 15765-2]: Handling Larger Data Payloads

OBD2 data communication over CAN bus relies on the ISO-TP (ISO 15765-2) transport protocol. This protocol enables the transmission of data payloads exceeding the 8-byte CAN frame limit. 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 of these larger messages. For more details, refer to our introduction to UDS.

However, much 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.

Decoding the OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]

To effectively log and interpret OBD2 data, understanding the structure of an OBD2 CAN message is crucial. A simplified OBD2 message consists of an identifier, a data length indicator (PCI field), and the data payload. The payload is further structured into Mode, parameter ID (PID), and data bytes.

Example: OBD2 Request and Response for Vehicle Speed

Let’s illustrate with an example of requesting and receiving ‘Vehicle Speed’ data.

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 with a CAN ID 0x7E8 message containing 3 payload bytes. The vehicle speed value is encoded in the 4th byte, 0x32 (decimal 50).

By consulting the OBD2 PID specifications for PID 0x0D, we can determine that 0x32 corresponds to a physical value of 50 km/h.

Now, let’s delve into OBD2 modes and PIDs in more detail.

The 10 OBD2 Services (Modes): Accessing Different Diagnostic Information

OBD2 defines 10 diagnostic services, also referred to as modes. Mode 0x01 provides access to current real-time data, while other modes are used for retrieving and clearing diagnostic trouble codes (DTCs) or accessing freeze frame data.

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

In OBD2 messages, the mode is located in the second byte. In a request message, the mode is included directly (e.g., 0x01). In a response message, 0x40 is added to the mode value (e.g., resulting in 0x41 for a response to mode 0x01).

OBD2 Parameter IDs (PIDs): Requesting Specific Data Points

Within each OBD2 mode, parameter IDs (PIDs) are used to specify the exact data point being requested.

For instance, mode 0x01 contains approximately 200 standardized PIDs providing real-time data on parameters like speed, RPM, and fuel level. However, vehicles typically support only a subset of the available PIDs within a mode.

One PID holds special significance:

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to PID 0x00, the ECU indicates its support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental OBD2 compatibility test. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 are used to determine support for subsequent ranges of mode 0x01 PIDs.

Tip: Utilizing an OBD2 PID Overview Tool for Efficient Data Lookups

The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBD2 PIDs, enabling you to convert raw data into physical values, as explained in our CAN bus introduction.

For quick lookups of mode 0x01 PIDs, our OBD2 PID overview tool is invaluable. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

How to Log and Decode OBD2 Channels: A Practical Guide

Now, let’s get to the core of how to log OBD2 channels. This section provides a hands-on example of OBD2 data logging using the CANedge CAN bus data logger.

The CANedge allows for custom CAN frame transmission, making it ideal for OBD2 logging. Simply configure the device, connect it to your vehicle using our OBD2-DB9 adapter cable, and you’re ready to start logging.

Verify bit-rate by sending a CAN frame at 500K and checking for successful transmission.

Review responses to ‘Supported PIDs’ requests using asammdf.

#1: Testing Bit-rate, IDs, and Supported PIDs: Initial Configuration

As discussed earlier, ISO 15765-4 outlines the process for determining the correct bit-rate and CAN IDs for a specific vehicle. You can use the CANedge to perform these tests (refer to the CANedge Intro for detailed instructions):

Bit-rate Validation: Send a CAN frame at 500K and check for successful transmission. If unsuccessful, try 250K.
Bit-rate Configuration: Use the validated bit-rate for all subsequent communication.
Supported PIDs Discovery: Send multiple ‘Supported PIDs’ requests and analyze the responses.
CAN ID Length Determination: Based on response IDs, identify whether 11-bit or 29-bit IDs are in use.
Supported PID List: Analyze response data to determine the specific PIDs supported by the vehicle.

We provide plug-and-play configuration files to streamline these tests.

Most non-EV cars manufactured in 2008 or later typically support 40-80 PIDs using a 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, which polls all ECUs for responses. Because all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses are often received for this PID. Subsequent ‘Supported PIDs’ requests usually elicit fewer responses as fewer ECUs support those specific PIDs. Notice that the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs, suggesting that bus load could be reduced by directing subsequent requests specifically to the ECM using ‘Physical Addressing’ with CAN ID 0x7E0.

#2: Configuring OBD2 PID Requests: Selecting Data Channels for Logging

Once you’ve identified the supported OBD2 PIDs, bit-rate, and CAN IDs, you can configure your data logger to request the specific PIDs you want to log.

Consider these factors when configuring your OBD2 PID requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses to each request, especially after identifying the primary ECU providing the desired data.
Request Spacing: Introduce a delay of 300-500 ms between consecutive OBD2 requests. Overly frequent requests can overwhelm ECUs and lead to dropped responses.
Power Management: Implement triggers to stop data transmission when the vehicle is inactive. This prevents unnecessary battery drain by avoiding continuous “wake-up” signals to ECUs.
Data Filtering: Apply filters to record only OBD2 responses. This is particularly useful if your vehicle also broadcasts OEM-specific CAN data, allowing you to focus on the relevant OBD2 channels.

With these configurations in place, your data logger is ready to record raw OBD2 data from your selected channels.

Example list of CANedge OBD2 PID requests for data logging.

asammdf enables DBC decoding and visualization of logged OBD2 data.

#3: DBC Decoding Raw OBD2 Data: Converting Raw Values to Physical Units

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

The necessary decoding information is specified in ISO 15031-5/SAE J1979 and is also available on resources like Wikipedia. For convenience, we provide a free OBD2 DBC file that simplifies DBC decoding of raw OBD2 data in most CAN bus software tools.

Decoding OBD2 data is slightly more complex than standard CAN signal decoding because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is insufficient to uniquely identify the signals within the payload.

To resolve this, decoding must consider the CAN ID, OBD2 mode, and OBD2 PID to correctly identify each signal. This technique is known as ‘extended multiplexing‘ and can be implemented in DBC files.

CANedge: Your Dedicated OBD2 Data Logger

The CANedge offers a straightforward solution for recording OBD2 data directly to an 8-32 GB SD card. Simply connect it to your vehicle’s OBD2 port to begin logging. Decode your data using free software/APIs and our OBD2 DBC for easy analysis.

OBD2 logger intro

CANedge Product Page

OBD2 Multi-Frame Examples [ISO-TP]: Handling Larger Data Transmissions

All OBD2 data communication utilizes the ISO-TP (transport protocol) as defined in ISO 15765-2. While many examples involve single-frame communication, some OBD2 operations require multi-frame exchanges.

Multi-frame OBD2 communication necessitates flow control frames (see our UDS intro for details). 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.

Furthermore, processing multi-frame OBD2 responses requires CAN software/API tools with ISO-TP support, such as the CANedge MF4 decoders.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and other applications (see our UDS introduction for more information). To retrieve the VIN using OBD2, you use mode 0x09 and PID 0x02:

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

The vehicle responds with a First Frame that includes the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is the byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes contain the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction.

Example 2: OBD2 Multi-PID Request (6x) – Advanced Data Acquisition

External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU will respond with data for the supported PIDs (excluding unsupported ones), potentially using multi-frame responses as per ISO-TP.

This advanced feature allows for higher-frequency and more efficient data collection. However, it also complicates signal encoding, making generic OBD2 DBC files less suitable for these use cases. We generally advise against using this method unless specifically required. Here’s an example trace:

The multi-frame response structure is similar to the VIN example but includes the requested PIDs and their corresponding data. In practice, the PIDs in the response are often ordered as they were requested, though this is not strictly mandated by the ISO 15031-5 standard.

Decoding these responses using generic DBC files is challenging. Therefore, we don’t recommend this approach for practical data logging unless you are using a tool with built-in support for multi-PID requests. This method introduces extended multiplexing with multiple instances within the payload, and DBC files would need to account for the specific payload position of each PID, making it difficult to create generalized DBCs applicable across different vehicles with varying PID support. Furthermore, managing multiple such multi-PID requests via pure DBC manipulations becomes complex, as you lose a clear method to distinguish between messages.

Workarounds could involve custom scripts and recording transmit messages from your testing tool. The script could then interpret response messages in context with the corresponding request messages. However, such approaches are generally difficult to scale and manage efficiently.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) – Identifying Vehicle Issues

OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’, allows you to retrieve emissions-related DTCs. No PID is included in the request. The targeted ECU(s) respond with the number of stored DTCs (potentially zero if none are present), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than two 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 request to an ECU with 6 stored DTCs.

OBD2 Data Logging – Use Case Examples: Applications Across Industries

OBD2 data logging from cars and light trucks has diverse applications:

Logging Data from Cars: Fuel Efficiency, Driving Behavior, and More

OBD2 data can be used to optimize fuel consumption, improve driving habits, test prototype components, and inform insurance telematics.

obd2 logger for vehicle data

Real-time Car Diagnostics: On-the-Spot Troubleshooting

OBD2 interfaces enable real-time streaming of human-readable OBD2 data, facilitating immediate diagnosis of vehicle issues.

obd2 streaming for real-time analysis

Predictive Maintenance: Proactive Vehicle Health Monitoring

Cars and light trucks equipped with IoT OBD2 loggers can be monitored in the cloud to predict and prevent breakdowns.

predictive maintenance with OBD2 data

Vehicle Blackbox Logger: Event Recording and Data for Disputes

An OBD2 logger can function as a ‘black box’ for vehicles or equipment, providing valuable data for accident analysis, warranty claims, and diagnostic investigations.

can bus blackbox for vehicle event recording

Do you have a specific OBD2 data logging application in mind? Contact us for expert guidance!

Explore our guides section for more introductory resources, or download the comprehensive ‘Ultimate Guide’ PDF.

Ready to start logging and streaming OBD2 data?

Get your OBD2 data logger today!

Buy OBD2 Data Loggers Now

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN