OBD2 Data Logger - Easily Record & Visualize Your Car Data
Do you want to record OBD2 data from your car?
This intro recaps the basics of OBD2 logging, the top 4 benefits and example use cases. You can also download sample OBD2 data from an Audi A4 (speed, RPM, ...).
Note: In contrast to most OBD2 dongles/scanners, the CANedge lets you log & process your car's data your way - with 100% free software/APIs, incl. browser dashboards:
Learn below why the CANedge is ideal for CAN/OBD2 data logging and telematics.
Tip: Start by checking out our 4 min intro video above!
How does OBD2 data logging work?
First, let us briefly recap the basics of OBD2:
OBD2 offers a standardized set of parameters (OBD2 PIDs) that you can record - and easily decode - across most cars.
To log OBD2 data involves 3 simple steps:
- Configure your OBD2 logger with a list of OBD2 PIDs
- Connect it in your car via an OBD2 adapter to start logging
- Extract the SD and decode the data via the free software/API
For details, see the FAQ further below - or our docs:CLX000 OBD2 guide CANedge OBD2 guide
Top 4 benefits of OBD2 data logging
OBD2 logging lets you collect data from practically any car - below are the top benefits:
OBD2 data lets you e.g. monitor/optimize driving behavior and tune your car. OEMs can use the data to analyze the field performance of new prototype parts
Rare issue diagnostics
Rare issues in cars may occur briefly while driving, yet not during repairs. Logging the OBD2 data lets you analyze the period around an event to troubleshoot the problem
Car fleet management
OBD2 WiFi telematics at fleet level enables e.g. driver behavior research, fuel cost reductions, fewer breakdowns, compliance, dispute handling and predictive maintenance
Data control & custom integration
With an OBD2 WiFi logger, you record the raw time series data, which can be extracted via SD or uploaded to your own server - for easy custom integration via open APIs
Which benefits are relevant to your OBD2 logging use case? Reach out for free sparring!Contact us
The CANedge OBD2 data logger
The CANedge is a pro specs CAN bus data logger with key features:
Log data out-the-box. Standalone - no PC required. Power via CAN / OBD2 connector
Extractable 8-32 GB SD. 2xCAN/LIN. CAN FD. Zero data loss. 50 µs RTC resolution.
Only 8 x 5 x 2 CM. 100G. Aluminium enclosure. 4 LEDs. Modular (add e.g. GPS-to-CAN)
Advanced filters. Transmit lists. Triggers. Cyclic logging. Compression
Industrial SD card. Read data at 80 MB/s. Data encryption for GDPR/CCPA
Popular data format (MF4). Free open source GUI/API. Easily convert via DBC
Software example: OBD2 dashboard for your cars
With the CANedge, you can easily set up free, custom browser dashboards for visualizing your OBD2 data and setting alerts.
You can also combine your OBD2 data with GPS/IMU data by using a CANedge incl. GNSS/IMU.
Check out the online playground - or learn more in our intro!playground dashboards intro other software
Get the 'OBD2 Data Pack'
Want to try working with real OBD2 data?
Download your 'data pack' incl. our OBD2 DBC, 25+ car DBCs and 100+ MB of OBD2 data across 10+ cars!
Use case examples
Below we provide practical examples of how the CANedge can be used for logging OBD2 data.
OEM field testing of vehicle parts
Need to log CAN/OBD2 field data from vehicles in the field?
As an OEM, you may need to do late-stage field tests of prototype equipment. This often requires OBD2 & CAN data from multiple vehicles over e.g. months. The CANedge1 is ideal as it's extremely compact, plug & play and can be pre-configured easily. Data can be collected periodically and analyzed in your favorite CAN tools or the free asammdf GUI/API.canedge1
Vehicle telematics (OBD2 + GNSS/IMU + 3G/4G)
Need to setup OBD2 telematics for on-road vehicle fleets?
The CANedge2 can upload recorded OBD2 data through a WiFi access point, e.g. a 3G/4G hotspot. This enables near real-time wireless OBD2 data transfer from e.g. on-road vehicles to your own cloud server. The OBD2 data can be auto-processed via the open APIs (incl. OBD2 DBC decoding support), while the CANedge2 devices can be updated over-the-air. If you need to add GNSS position or 3D inertial sensor data, you can use a CANedge2 incl. GNSS/IMU.canedge2
Case study: OBD2/CAN telematics
Learn how Volkswagen uses the CANedge2 to log OBD2 and raw CAN data to an SD card - as well as auto-push the data to their own self-hosted server for analysis.
"The CANedge2 got us up-and-running at a rapid pace with robust config options - and the support was outstanding!"learn more 50+ case studies
OBD2 data from an Audi A4
Below you can download OBD2 samples from the CANedge.
You can also download the free open source OBD2 software and try out the process of decoding the raw OBD2 data.Raw OBD2 Decoded OBD2 Software
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:
- Fuel system status
- Engine load
- Coolant temperature
- Fuel trim
- Fuel pressure
- Intake manifold pressure
- Engine RPM
- Vehicle speed
- Intake air temperature
- MAF air flow rate
- Throttle position
- Air status
- Oxygen sensor status
- Runtime since engine start
- Distance with MIL on
- Fuel tank level input
- System vapor pressure
- Absolute load value
- Hybrid battery pack life
- Engine oil temperature
- Engine fuel rate
- Various DTCs
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 multiframe 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 multiframe 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 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 Loggers: Some OBD2 data loggers also support WiFi data transfer. For example, the CANedge2 can log OBD2 data to an SD card and auto-transfer the OBD2 data to a server (cloud, self-hosted) via a WiFi access point (incl. 3G/4G hotspots). This makes OBD2 WiFi 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 Wireshark.
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.
Ready to log OBD2 data from your car?
Get your CANedge today!