Obd2 Logger

[Darios Uclaray]

Asan 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.

The CANedge3 can upload recorded OBD2 data through 3G/4G - using your own SIM card. 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 CANedge3 devices can be updated over-the-air. Further, the CANedge3 includes a GPS/IMU, adding data such as position, speed, trip distance, acceleration, attitude and more to your 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.

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.

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).

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:

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.

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.

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.

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.

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.

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 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).

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.

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 (

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.

3a8082e126