OBD2 Data Logger - Easily Record & Visualize Your Car Data

The OBD2 protocol (SAE J1979) specifies a range of standardized vehicle data that you can log from your car. Note, however, that each car differs in what OBD2 data is supported - and in particular older cars often support fewer parameters.

With that said, we've listed some of the standard OBD2 parameters that are often available:

For further details, see the OBD2 PID Wiki page or the SAE J1979 standard.

To decode raw OBD2 data from a CANedge OBD2 data logger into physical values (km/h, rpm, ...), you need a database of decoding rules and suitable OBD2 software.

For this purpose, we provide a 100% free OBD2 DBC file, which contains the majority of the standardized Mode 01 (aka Service 01) OBD2 PID decoding rules as found on e.g. the OBD2 PID Wiki page.

The OBD2 DBC file uses extended multiplexing to enable OBD2 decoding. For more on this, see our DBC intro and our OBD2 intro (where we explain how to interpret raw CAN frames with OBD2 responses).

You can load your raw OBD2 data and the OBD2 DBC file in one of our free software tools (e.g. asammdf or our OBD2 dashboard integrations). This lets you visualize your decoded OBD2 data such as Speed, Engine Speed, MAF, Fuel Level etc.

One of the benefits of using this approach is that you can easily modify the OBD2 DBC to include additional proprietary OBD2 PIDs. You can also combine the OBD2 DBC with e.g. proprietary CAN DBC files to enable both CAN/OBD2 car data logging.

What is UDS?

The Unified Diagnostic Services protocol (UDS, ISO 14229-1) is a communication protocol used within automotive ECU communication. An UDS diagnostic tool can be used to send requests messages into the CAN bus, with the purpose of e.g. retrieving information from specific ECUs. While OBD2 is intended as an on-board diagnostics protocol (for while the vehicle is moving), UDS is intended as an off-board diagnostic protocol (for when the vehicle is standing still).

How to make UDS requests over ISO-TP (ISO 15765-2)

Requesting OBD2 PIDs is relatively simple: An OBD2 scan tool or OBD2 data logger sends a specific CAN frame (the OBD2 request) and if the car supports the OBD2 PID, it responds with a single CAN frame. In contrast, UDS requests may require performing transport protocol requests. For example, you can use the UDS service 0x22 to request data by identifier. In this case, the communication flow may be as follows:

• An 'UDS data logger' sends a request frame specifying the service ID (SID) and data identifier (DID) of interest
• The car responds with a first frame, which contains the SID, DID, total message length and initial payload bytes
• Shortly after the first frame, the UDS logger acknowledges the first frame by sending a flow control frame
• After this, the ECU sends consequtive frames with the remaining payload of the message

In other words, to log UDS data requires that the UDS tool can send custom CAN frames and flow control frames. Further, the software tools must be able to re-construct multi-frame UDS responses in order to extract the payload and decode it.

UDS and OBD2 extended PIDs for car data logging

The UDS service ID (SID) and the data identifiers (DID) are sometimes combined into one ID and referred to as an 'extended OBD2 PID' - for example 0x220101. Recording UDS data via service 0x22 requests is sometimes used to extract car data beyond what is available through service 01 OBD2 PID requests. For example, some electric cars provide access to State of Charge (SoC%) via UDS requests under service 0x22.

Using the CANedge as an UDS data logger

The CANedge can be configured to send UDS requests. This is done by sending a request frame and adding a flow control frame within X ms after the request. When done right, this triggers the full sequence of UDS responses. The resulting log files with UDS responses can e.g. be loaded in tools like CANalyzer (by converting the MF4 data to Vector ASC) for decoding. Alternatively, the multi-frame UDS response data can be processed via our free Python CAN bus API e.g. to push parameters to a Grafana UDS dashboard. Our github API examples library contains UDS response data and an UDS DBC file for decoding State of Charge (SoC%) from a Hyundai Kona EV. To learn more about this, see our EV data logger article or contact us.

Most likely. The majority of cars and light trucks use the OBD2 standard as their on-board diagnostics methodology. In particular, OBD2 has been mandatory in USA since 1996 and in EU since 2003 (here it is denoted EOBD, but it is basically the same).

However, even if your vehicle supports OBD2, you may be unable to log the data you want. First, each vehicle model (brand/year) differs in terms of what OBD2 data parameters are supported. In particular, older cars often have more limited support for e.g. real-time parameters like speed, RPM etc. Further, some car manufacturers have begun restricting access to the OBD2 data to better control their vehicle data. And finally, while the vast majority of cars use CAN as the signal protocol for OBD2, you may encounter cases for old US cars (pre 2008) or e.g. some EU brands where another protocol is used instead.

Note: A useful check is to review your OBD2 connector in your car. To use a CAN logger to record OBD2 data, it's necessary that you have "metal pins" in the CAN High (pin 6) and CAN Low (pin 14) pins of the OBD2 connector - see our OBD2 connector illustration (the red pins). If in doubt, send us a picture for review.

There are 5 OBD2 signal protocols in total:

• ISO 15765 (CAN): Dominant, as it's required in all vehicles sold in the USA since 2008
• SAE J1850: Standard of the Ford Motor Company
• SAE J1850: Standard of General Motors
• ISO 9141-2: Used by Chrysler and some EU/Asian vehicles
• ISO 14230 (KWP2000): Mainly used by EU manufacturers

The CANedge/CLX000 supports CAN based OBD2 - if in doubt whether your car is supported, contact us.

If you do not have access to your car to visually screen the OBD2 connector, you can do a rough protocol check for the specific car here: OBD2 compatibility (cars). For further guidance on the basics, check our simple intro to OBD2.

Note: With an OBD2 logger, you can also check what Mode 01 OBD2 parameter IDs are supported in your car. To do so, you request 'Supported PIDs' parameters (ID 00, 20, 40, 60, 80, A0, C0). Once you've logged these, you can review the response data bytes bit-by-bit to see if a PID is supported not (see the Wikipedia OBD2 PID article for details).

Generally speaking, you'll be logging OBD2 data from cars and light trucks. In contrast, if you're aiming to log data from heavy-duty vehicles like trucks, tractors, excavators etc, you will typically need to record J1939 data. The J1939 protocol is a standardized protocol used in most heavy-duty vehicles today, meaning that data can be decoded across vehicle brands (similar to the case of OBD2). To decode J1939 data, a J1939 DBC file is required - and you can use the CANedge/CLX000 as a J1939 data logger as well.

Both the CANedge and CLX000 data logger series can be used as OBD2 data loggers.

If your main goal is to log data to an SD card, we recommend the CANedge series - it is the 2nd generation of the CLX000 and optimized for logging. Further, if you wish to be able to auto-upload your log files to your own server we recommend the CANedge2. This device is particularly useful if you aim to set up OBD2 telematics workflows and OBD2 dashboards.

If you wish to also be able to stream OBD2 data in real-time via USB to your PC, we recommend the CLX000 series, e.g. the CL2000.

If in doubt, please contact us - we'll be able to help find the best fit quickly based on a few details on your use case.

Yes, the CLX000 series enables real-time streaming of raw CAN data and OBD2 data via USB - see our OBD2 streaming intro.

If you connect a CAN logger like the CANedge or CLX000 to your car via the OBD2 connector, it will by default start recording raw CAN bus data (in most cars). This raw CAN data is "broadcasted" by the car sensors and used by the car itself to communicate.

In some cases, you may want to log this raw CAN data - e.g. if you are the Original Equipment Manufacturer (OEM) of the car. In this case you will know what each CAN ID and data bytes represent and you'll have a CAN database (DBC file) that you can use to decode the raw CAN data. However, if you're not the vehicle OEM, the only way to decode the raw CAN data will be by hacking your car and reverse engineer the data. In some cases, you can be lucky and find partial databases for your specific car model/year online - e.g. from projects like opendbc.

In most cases, if you're not the car OEM, your main option for collecting data will be via the OBD2 protocol. Today, almost all cars base their OBD2 communication on CAN bus. OBD2 is available only "on-request", in contrast to the raw CAN bus data. To log OBD2 data, you're basically sending a specific custom CAN frame into the vehicle CAN bus. Essentially you're using the CAN bus to send a command to the car to respond with the requested data. The car may respond to your request, assuming the specific OBD2 PID is supported by the car (which is to some extent up to the OEM to decide).

There is a massive number of OBD2 device types on the market - below we outline the main groups:

OBD2 Scanners: These are typically used by mechanics/technicians for diagnostic purposes - e.g. to identify what causes your malfunction indicator lamp (MIL) to be turned on. The OBD2 scanners typically include built-in databases for diagnostic trouble codes (DTCs) and functionality for clearing these. OBD2 bluetooth scanners and OBD2 WiFi scanners also exist for more convenient access to OBD2 diagnostic codes via smartphone.

OBD2 Dongles: While not a "formal" definition, OBD dongles typically refer to small, low cost and simple-to-use consumer oriented bluetooth OBD2 readers. They typically provide data via e.g. a smartphone app, allowing you to get a real-time view of your vehicle's performance. They are great for plug-and-play consumer purposes, but offer very limited flexibility in terms of use cases. Typically these devices use an ELM327 microcontroller.

OBD2 Data Loggers: An OBD logger can be used to record OBD2 timeseries data to an SD card in "standalone mode" (i.e. no PC or app required). The data can be extracted via USB or an extractable SD card for later analysis. The CANedge1 is an example of a CAN bus data logger that can be used as an OBD2 data logger.

OBD2 WiFi/LTE Loggers: Some OBD2 data loggers also support WiFi or 3G/4G data transfer. For example, the CANedge2/CANedge3 can log OBD2 data to an SD card and auto-transfer the OBD2 data to a server (cloud, self-hosted) via WiFi/LTE. This makes the CANedge loggers ideal for OBD2 telematics - e.g. to enable wireless access to car codes and parameters like speed, MAF, RPM etc. This type of solution is also ideal for creating OBD2 dashboards to visualize data across car fleets.

OBD2 Interfaces: Some CAN interfaces can also serve as OBD2 interfaces, allowing for real-time streaming of OBD2 data to a PC via USB. For example, the CLX000 enables USB streaming of OBD2 data to a PC via SavvyCAN.

In most cases, yes.

Typically, when you connect e.g. a CANedge to your vehicle, it'll turn on/off with the ignition, since the OBD2 connector typically uses the IGN power supply. This means that the CANedge will not drain any power from the vehicle battery when turned off.

However, in some vehicles the OBD2 connector power supply will be directly wired to the battery, meaning that the CANedge may still be turned on when the car is off. Normally this is not an issue as the power drain from the logger itself is minimal (<1W). However, if you're polling OBD2 data from the ECUs, this may "wake up" the ECUs while the car is off. This can result in some power drain if the car is off for a longer duration.

You can quickly verify if your logger turns on/off with your vehicle by evaluating the LEDs after the car has been turned off for 15-20 minutes - if the LEDs are not lit, the CANedge is turned off.

In case the CANedge/CLX000 does not turn off with the vehicle - and you know the vehicle will be turned off for longer durations - you can disconnect the device during this period. Alternatively, you can configure the CANedge to start/stop transmitting based on broadcasted CAN data patterns. For example, if your car emits a specific CAN ID or data byte pattern when the ignition is turned on/off, this can be used to toggle the transmit functionality of the CANedge. Finally, you can use a DB9-DC splitter cable and a DC-cigarette receptacle adapter to power the CANedge car data logger via your cigarette power supply. This is typically linked to the ignition, forcing the device to turn off with the vehicle. For details, see the CANedge Docs.

Your car may have a built-in GPS, though it's rarely possible to extract the data via OBD2 or the proprietary CAN data. For practical purposes, we recommend using a CANedge incl. GNSS/IMU. This lets you record GNSS/IMU data timesynced with the CAN/OBD2 data that you record from your car via Channel 1.