Are you looking for a straightforward and practical guide to understanding the OBD2 system, specifically focusing on the 19 Ram Obd2 Connector Pinout? You’ve come to the right place.
This article provides a detailed introduction to the On-Board Diagnostics II (OBD2) protocol, including the specifics of the OBD2 connector, OBD2 Parameter IDs (PIDs), and its connection to the CAN bus system.
This is designed as a practical guide, so you’ll not only learn the theory but also gain insights into requesting and interpreting OBD2 data, key logging applications, and valuable practical tips, especially relevant to RAM truck owners and technicians working on them.
Discover why this is becoming a leading resource for understanding the 19 RAM OBD2 connector pinout and the broader OBD2 system.
You can also explore our introductory video on OBD2 or download the PDF version of our comprehensive CAN bus guide.
Article Contents
Author: Martin Falch (Updated January 2025)
Download as PDF
Understanding OBD2 and its Relevance to Your 19 RAM Truck
OBD2 is essentially the built-in self-diagnostic system in your vehicle. It’s a standardized protocol that enables the extraction of diagnostic trouble codes (DTCs) and real-time data through the OBD2 connector. For owners and technicians working with 19 RAM trucks, understanding OBD2 is crucial for effective vehicle maintenance and diagnostics.
You’ve likely already encountered OBD2 in action. Ever seen the malfunction indicator light, often called the “check engine light,” illuminate on your RAM’s dashboard?
That’s your truck’s way of signaling a problem. When you take your vehicle to a mechanic, they use an OBD2 scanner to pinpoint the issue.
To do this, they connect an OBD2 reader to the OBD2 16-pin connector, typically located beneath the dashboard near the steering column in most vehicles, including 19 RAM models. This tool sends ‘OBD2 requests’ to the truck, and the truck responds with ‘OBD2 responses’. These responses can contain a wealth of information, from speed and fuel level to critical Diagnostic Trouble Codes (DTCs). This data allows for quicker and more accurate troubleshooting, saving time and money on vehicle repairs, particularly important for maintaining the performance of your 19 RAM truck.
Understanding OBD2: On-Board Diagnostics and the Malfunction Indicator Light (MIL) for vehicle issue alerts.
OBD2 Compatibility: Is Your 19 RAM Equipped?
The good news for 19 RAM owners is: Yes, almost certainly!
Nearly all modern non-electric vehicles, including the 19 RAM series, support OBD2 and often operate on the CAN bus protocol. For older vehicles, even if a 16-pin OBD2 connector is present, it might not fully support the OBD2 protocol. A key factor in determining OBD2 compliance is the vehicle’s manufacturing date and original market.
Generally, for vehicles sold new in:
- USA: OBD2 compliance has been mandatory for cars and light trucks since 1996.
- EU: Mandatory for gasoline cars from 2001 and diesel cars (EOBD) from 2003.
Considering the 19 RAM is a recent model, it will undoubtedly be OBD2 compliant. However, for older vehicles, especially pre-1996 models, verification might be needed.
OBD2 Compliance Guide: Determine if your vehicle is OBD2 compliant based on purchase location and year (EU, US, CAN).
A Brief History of OBD2: From Regulation to Standard
The origin of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated OBD for all new vehicles starting in 1991 for emissions control.
The OBD2 standard, as we know it today, was largely shaped and recommended by the Society of Automotive Engineers (SAE). They standardized Diagnostic Trouble Codes (DTCs) and the physical OBD connector, documented under SAE J1962, ensuring uniformity across different vehicle manufacturers. This standardization is what makes tools and knowledge about the 19 RAM OBD2 connector pinout universally applicable.
The rollout of the OBD2 standard was a phased process:
- 1996: OBD2 became mandatory in the USA for cars and light trucks, including many models similar in class to the 19 RAM.
- 2001: Required in the EU for gasoline-powered cars.
- 2003: Extended to diesel cars in the EU (EOBD).
- 2005: OBD2 was mandated in the US for medium-duty vehicles.
- 2008: US vehicles were required to adopt ISO 15765-4 (CAN) as the foundation for OBD2 communication.
- 2010: OBD2 compliance was finally extended to heavy-duty vehicles in the US.
OBD2 Historical Timeline: Evolution of On-Board Diagnostics for emission control and vehicle data access.
OBD2 History Timeline Overview: Key milestones in the development and standardization of On-Board Diagnostics.
OBD2 Future Trends: Envisioning OBD3 with remote diagnostics, emissions testing, cloud integration, and IoT.
The Future of OBD2: Trends and Innovations
OBD2 is expected to remain a standard in vehicle diagnostics, but its form and function are evolving. While your 19 RAM truck utilizes current OBD2 standards, the future is bringing changes.
Here are some key trends shaping the future of OBD2:
Originally designed for emissions control, legislated OBD2 has an interesting implication: electric vehicles are not strictly required to support OBD2 in its traditional form. This is evident in the fact that most modern EVs do not support standard OBD2 requests. Instead, they often use OEM-specific UDS communication protocols. Decoding data from these EVs can be challenging unless reverse engineering efforts reveal the communication rules. However, for vehicles like the 19 RAM, which are not electric, OBD2 remains the standard.
Modern alternatives are emerging to address the limitations of current OBD2 implementations, particularly in data richness and lower-layer protocols. These include WWH-OBD (World-Wide Harmonized OBD) and OBDonUDS (OBD on UDS). Both are designed to enhance OBD communication by using the UDS protocol as a base. For a deeper dive into these protocols, refer to our introduction to UDS.
In our increasingly connected world, traditional OBD2 testing methods can seem outdated. Manual emission control checks are time-consuming and costly.
The proposed solution is OBD3 – integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder to vehicles, similar to those used for bridge tolls. This would allow the car’s vehicle identification number (VIN) and DTCs to be transmitted wirelessly via WiFi to a central server for automated checks.
Many devices today already facilitate the transfer of CAN or OBD2 data via WiFi or cellular networks, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.
While offering convenience and cost savings, OBD3 also raises political and privacy concerns related to surveillance.
Initially designed for stationary emission controls, OBD2 is now widely used by third parties to generate real-time vehicle data through OBD2 dongles, CAN loggers and similar devices. However, there’s a push from some sectors of the automotive industry to limit this third-party access.
There’s a proposal to potentially “turn off” OBD2 functionality during normal driving, collecting data centrally by manufacturers instead. This would give manufacturers greater control over automotive data, creating an ‘automotive big data’ ecosystem controlled by them.
The rationale often cited is security, aiming to reduce the risk of car hacking. However, many view this as a commercially motivated move. Whether this trend will materialize and disrupt the market for third-party OBD2 services remains to be seen.
OBD2 Future Challenges: Electric Vehicles and potential limitations on data access through the OBD2 connector.
Enhance Your CAN Bus Expertise
Want to deepen your understanding of CAN bus technology?
Access our collection of 12 ‘simple introductions’ in a comprehensive 160+ page PDF guide:
Download now
OBD2 Standards: A Layered Approach
On-board diagnostics, OBD2, is a higher-layer protocol, functioning like a language. In contrast, CAN is the communication method, akin to a telephone line. This makes OBD2 comparable to other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.
The OBD2 standards specifically define aspects such as the OBD2 connector, lower-layer communication protocols, OBD2 Parameter IDs (PIDs), and more. Understanding these standards, particularly the 19 RAM OBD2 connector pinout, is essential for anyone working with vehicle diagnostics.
These standards can be visualized using the 7-layer OSI model. Notably, both SAE and ISO standards cover various layers. This reflects the development of OBD standards in the USA (SAE) and Europe (ISO). Many of these standards are technically very similar, for example, SAE J1979 is largely equivalent to ISO 15031-5, and SAE J1962 mirrors ISO 15031-3.
OBD2 and CAN Bus in the OSI Model: Illustrating the 7-layer OSI model with ISO 15765 and ISO 11898 standards.
OBD2 Connector Pinout Diagram: Socket Female Type A Data Link Connector (DLC) pin assignments.
The OBD2 Connector: SAE J1962 and Your 19 RAM
The 16-pin OBD2 connector is your gateway to accessing vehicle data, including in your 19 RAM truck. It is standardized under SAE J1962 / ISO 15031-3. For anyone needing to interface with their vehicle’s diagnostics, understanding the 19 RAM OBD2 connector pinout is the starting point.
The illustration above shows a typical Type A OBD2 pin connector, also known as the Data Link Connector (DLC). This is the standard connector type you’ll find in your 19 RAM and most passenger vehicles.
Key points about the OBD2 connector include:
- It is usually located near the steering wheel, but sometimes it may be hidden behind a panel. In 19 RAM trucks, it’s typically found under the dashboard on the driver’s side.
- Pin 16 always provides battery power, often even when the ignition is off, which is crucial for some diagnostic tools and data loggers.
- The OBD2 pinout varies depending on the communication protocol used by the vehicle.
- CAN bus is the most prevalent lower-layer protocol. Therefore, pins 6 (CAN-High) and 14 (CAN-Low) are generally connected in vehicles using CAN for OBD2, including 19 RAM models.
OBD2 Connector Types: A vs. B
While Type A is standard for cars and light trucks like the 19 RAM, you may encounter Type B connectors, especially in medium and heavy-duty vehicles.
Both Type A and Type B OBD2 connectors share similar pinouts but differ in power supply output. Type A typically provides 12V, while Type B is designed for 24V systems, common in larger trucks. Baud rates can also differ, with cars usually using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing in newer heavy-duty vehicles).
Visually, a Type B OBD2 connector has a distinguishing interrupted groove in the middle, unlike the Type A. This physical difference is important for adapter compatibility. A Type B OBD2 adapter cable is generally compatible with both Type A and B sockets, whereas a Type A adapter will not fit into a Type B socket. For 19 RAM trucks, you’ll typically use Type A adapters.
OBD2 Connector Types A and B: SAE J1962 standard connectors, differentiating between 12V (Type A) and 24V (Type B) for cars, vans, and trucks.
OBD2 vs. CAN Bus ISO15765: Comparing OBD2 diagnostic protocol with CAN bus communication standard.
OBD2 and CAN Bus: ISO 15765-4 and Your 19 RAM
Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, as per ISO 15765. This is the communication backbone for OBD2 in your 19 RAM truck.
ISO 15765-4, also known as Diagnostics over CAN (DoCAN), sets specific constraints on the CAN standard (ISO 11898) for OBD2 applications.
Specifically, ISO 15765-4 standardizes the CAN interface for diagnostic equipment at the physical, data link, and network layers, specifying:
- CAN bus bit-rate: Must be either 250K or 500K. 19 RAM trucks typically use 500K.
- CAN IDs: Can be 11-bit or 29-bit. 11-bit is more common in passenger vehicles.
- Specific CAN IDs: Defined for OBD requests and responses.
- Diagnostic CAN frame data length: Fixed at 8 bytes.
- OBD2 adapter cable length: Maximum length of 5 meters.
OBD2 CAN Identifiers: 11-bit and 29-bit
OBD2 communication is structured around request and response messages.
In most cars, including many light-duty trucks similar to the 19 RAM, 11-bit CAN IDs are used for OBD2. The ‘Functional Addressing’ ID is 0x7DF. This ID is used to query all OBD2-compliant Electronic Control Units (ECUs) to see if they have data related to the requested parameter, as per ISO 15765-4. In contrast, CAN IDs in the range 0x7E0-0x7E7 are used for ‘Physical Addressing’, allowing requests to be sent to specific ECUs, though this is less common.
ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most common response ID is 0x7E8, typically from the Engine Control Module (ECM), and sometimes 0x7E9 from the Transmission Control Module (TCM).
In some vehicles, particularly larger vehicles like vans and medium to heavy-duty trucks, you may find OBD2 communication using extended 29-bit CAN identifiers instead of 11-bit IDs. While less common in light trucks like the 19 RAM, it’s worth noting.
In 29-bit CAN, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
Responses, when using 29-bit IDs, are typically in the range of 0x18DAF100 to 0x18DAF1FF, often 18DAF110 and 18DAF11E. This response ID is sometimes also represented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which in the J1939-71 standard is designated as ‘Reserved for ISO 15765-2’.
OBD2 Request and Response Frames: Illustrating the structure of OBD2 communication with PID data parameters.
OBD2 vs. Proprietary CAN Bus: Contrasting OBD2 standardized data with OEM-specific CAN bus data protocols.
OBD2 vs. Proprietary CAN Protocols: What You Need to Know for Your 19 RAM
It’s crucial to understand that your 19 RAM truck’s Electronic Control Units (ECUs) operate primarily on proprietary CAN protocols defined by the manufacturer, not OBD2. Each Original Equipment Manufacturer (OEM) develops their own CAN protocols, often specific to vehicle brand, model, and year. This proprietary data is generally inaccessible and undecipherable to those outside the OEM, unless reverse engineering is employed.
When you connect a CAN bus data logger to your 19 RAM’s OBD2 connector, you might observe OEM-specific CAN data, typically broadcast at high rates (1000-2000 frames/second). However, in many newer vehicles, a ‘gateway’ module restricts access to this proprietary CAN data through the OBD2 port, allowing only standardized OBD2 communication. The presence of a gateway in your 19 RAM might limit the extent of data you can access via OBD2.
In essence, OBD2 should be seen as an additional, higher-layer protocol that runs alongside the OEM-specific protocol. It’s designed for diagnostics and standardized data access, separate from the vehicle’s core operational network.
Bit-Rate and ID Validation for Reliable OBD2 Communication
As discussed, OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential protocol combinations. Modern vehicles, including the 19 RAM, commonly use 500K and 11-bit IDs. Diagnostic tools should systematically verify these parameters to ensure correct communication.
ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination. This process leverages the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (refer to the OBD2 PID section for details). Incorrect bit-rate usage will result in CAN error frames, which can be detected to refine the communication settings.
Newer versions of ISO 15765-4 consider vehicles that may support 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) as opposed to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service, as per ISO 14229, ISO 27145-3/SAE J1979-2).
To test for OBDonEDS vs. OBDonUDS, advanced tools may send additional 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 vehicles today, including the 19 RAM, while WWH-OBD is more common in EU trucks and buses.
OBD2 Bit-rate and CAN ID Validation Flowchart: ISO 15765-4 compliant process for validating OBD2 communication parameters.
OBD2 Five Lower-Layer Protocols: Diagram illustrating the five OBD2 protocols including CAN (ISO 15765), KWP2000, SAE J1850, and ISO 9141.
Five Lower-Layer OBD2 Protocols: Understanding Legacy Systems
While CAN (ISO 15765) is the dominant lower-layer protocol for OBD2 today, especially in vehicles like the 19 RAM, older vehicles (pre-2008) may use one of four other protocols. Understanding these legacy protocols can be helpful when working with older vehicles. Pinouts can sometimes indicate the protocol in use.
The five lower-layer OBD2 protocols are:
- ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and now the most common protocol.
- ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, especially in Asia.
- ISO 9141-2: Used in EU, Chrysler, and Asian vehicles in the 2000-2004 period.
- SAE J1850 (VPW): Variable Pulse Width Modulation, primarily used in older GM vehicles.
- SAE J1850 (PWM): Pulse Width Modulation, mainly used in older Ford vehicles.
ISO-TP: Transporting OBD2 Messages via ISO 15765-2
All OBD2 data communication over CAN bus utilizes a transport protocol called ISO-TP (ISO 15765-2). This protocol is essential because it enables the transmission of data payloads larger than the standard 8-byte CAN frame limit. This is crucial in OBD2 for tasks like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often require more than 8 bytes. ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. For a more detailed explanation, refer to our introduction to UDS.
However, many OBD2 data requests and responses fit within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF) format. In a Single Frame, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes available for OBD2-related communication.
ISO 15765-2 Frame Types for OBD2: Diagram illustrating Single Frame, First Frame, Consecutive Frame, and Flow Control frame types in ISO-TP.
The OBD2 Diagnostic Message: SAE J1979, ISO 15031-5 in Practice
To better understand OBD2 communication over CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message comprises a CAN identifier, a data length indicator (PCI field), and the data itself. The data portion is further structured into Mode, Parameter ID (PID), and data bytes. Understanding this structure is key to interpreting data from your 19 RAM OBD2 connector pinout.
OBD2 Message Structure Breakdown: Diagram explaining the raw OBD2 frame, including Mode, PID, ID, and data bytes.
Example: OBD2 Request/Response Sequence
Let’s consider a practical example: requesting ‘Vehicle Speed’.
In this scenario, an external diagnostic tool sends a request message to the vehicle (like your 19 RAM) with CAN ID 0x7DF and a 2-byte payload: Mode 0x01 and PID 0x0D. The vehicle responds with a message via CAN ID 0x7E8 and a 3-byte payload. This payload includes the vehicle speed value in the 4th byte, in this case, 0x32 (which is 50 in decimal).
By consulting the OBD2 PID documentation for PID 0x0D, we find that this value represents vehicle speed. Applying the decoding rules, we determine that the physical value is 50 km/h.
Next, we will delve deeper into OBD2 modes and PIDs, which are fundamental to understanding the data you can retrieve from your 19 RAM OBD2 connector pinout.
OBD2 Request and Response Example: Illustrating a request with CAN ID 7DF and response with 7E8 for Vehicle Speed PID.
OBD2 PID Example – Vehicle Speed 0D: Detailed example of OBD2 Parameter ID 0D for retrieving vehicle speed data.
OBD2 Services and Modes: Overview of the 10 OBD2 diagnostic services or modes, including current data, freeze frame, and DTC clearing.
The 10 OBD2 Services (Modes)
OBD2 defines 10 diagnostic services, also referred to as modes. Each mode serves a different diagnostic purpose. Mode 0x01, for example, is used to access current, real-time data parameters. Other modes are used for retrieving and clearing Diagnostic Trouble Codes (DTCs), accessing freeze frame data, and more. Understanding these modes is crucial for effectively using the 19 RAM OBD2 connector pinout for diagnostics.
It’s important to note that vehicles are not required to support all 10 OBD2 modes. Additionally, manufacturers may implement OEM-specific modes beyond the 10 standardized modes. Your 19 RAM truck will support a subset of these standard modes, and possibly some proprietary ones.
In OBD2 messages, the mode is specified in the second byte of the data payload. In a request message, the mode is included directly (e.g., 0x01). In the response message, 0x40 is added to the requested mode (e.g., a response to mode 0x01 will start with 0x41).
OBD2 Parameter IDs (PIDs): Accessing Specific Data
Within each OBD2 mode, Parameter IDs (PIDs) are used to specify the exact data parameter being requested or reported. For mode 0x01, which provides real-time data, there are approximately 200 standardized PIDs. These PIDs cover a wide range of parameters, including speed, RPM, engine load, fuel level, and many more. However, a vehicle, including your 19 RAM, typically supports only a subset of these defined PIDs within mode 0x01 and other modes.
One PID, PID 0x00 in mode 0x01, is particularly significant.
If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. When this PID is requested, the vehicle ECU responds by indicating which PIDs from 0x01 to 0x20 it supports. This makes PID 0x00 an essential tool for verifying basic OBD2 compatibility and for discovering supported PIDs. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 are used to determine support for subsequent ranges of mode 0x01 PIDs (0x21-0x40, 0x41-0x60, and so on).
OBD2 Request and Response Frames: Detailed view of OBD2 communication frames, highlighting PID data parameters.
OBD2 PID Overview Tool: Screenshot of a tool for exploring OBD2 Parameter IDs (PIDs) in service 01.
Tip: Using an OBD2 PID Overview Tool
The appendices of SAE J1979 and ISO 15031-5 provide detailed scaling and decoding information for standard OBD2 PIDs. This information is essential for converting raw OBD2 data into meaningful physical values. For example, speed values are typically encoded in a way that requires a specific formula to convert the raw byte value into km/h or mph. Our CAN bus introduction explains this process in more detail.
To simplify working with mode 0x01 PIDs, we offer an OBD2 PID overview tool. This tool is designed to help you construct OBD2 request frames and dynamically decode OBD2 responses. It’s an invaluable resource for anyone working with OBD2 data, including diagnostics on a 19 RAM truck.
OBD2 PID overview tool
Logging and Decoding OBD2 Data: A Practical Guide for Your 19 RAM
In this section, we’ll walk through a practical example of how to log OBD2 data from your 19 RAM truck using a CANedge CAN bus data logger. The CANedge is versatile and can be configured to transmit custom CAN frames, making it ideal for OBD2 data logging.
To get started, you’ll need to connect the CANedge to your 19 RAM’s OBD2 port using an OBD2-DB9 adapter cable.
OBD2 Data Logger Setup: Illustrating OBD2 data logging with PID requests 7DF and responses 7E8.
OBD2 Bit Rate Validation: Confirming successful CAN frame transmission at 500K bit rate for OBD2.
Supported PIDs Test Responses: Reviewing responses to ‘Supported PIDs’ requests using asammdf tool.
Step #1: Test Bit-Rate, CAN IDs, and Supported PIDs on Your 19 RAM
As previously mentioned, ISO 15765-4 provides a method to determine the correct bit-rate and CAN IDs for OBD2 communication with a specific vehicle. Here’s how to do this with the CANedge (refer to the CANedge Introduction for detailed setup instructions):
- Bit-rate Test: Start by sending a CAN frame at 500K. Check if the transmission is successful. If not, try 250K. Most modern vehicles, including the 19 RAM, use 500K.
- Use Correct Bit-rate: Once you’ve identified the correct bit-rate, use it for all subsequent OBD2 communication.
- Request Supported PIDs: Send multiple ‘Supported PIDs’ requests (Mode 0x01, PID 0x00) and analyze the responses.
- Determine CAN ID Type: Based on the response IDs, determine whether the vehicle is using 11-bit or 29-bit CAN IDs for OBD2 communication. In most passenger vehicles and light trucks like the 19 RAM, 11-bit IDs are standard.
- Identify Supported PIDs: Analyze the response data to see which PIDs are supported by your 19 RAM truck. This will inform you about the data parameters you can access.
We provide pre-configured CANedge configurations to automate these tests, simplifying the setup process.
Most 2008 and newer non-EV vehicles typically support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol. This likely applies to your 19 RAM.
As illustrated in the asammdf GUI screenshot, you may observe multiple responses to a single OBD request, especially when using the functional address CAN ID 0x7DF. This happens because 0x7DF is a broadcast request, and all OBD2/OBDonEDS-compliant ECUs respond. Since all compliant ECUs must support service 0x01 PID 0x00, you often see numerous responses to this PID in particular. For subsequent ‘Supported PIDs’ requests (e.g., for PID ranges 0x21-0x40, 0x41-0x60, etc.), fewer ECUs typically respond. Notice that the ECM ECU (0x7E8) often supports all the PIDs supported by other ECUs in the example. To reduce bus load, you could switch to ‘Physical Addressing’ and send subsequent requests to the ECM ECU specifically using CAN ID 0x7E0.
Step #2: Configure OBD2 PID Requests for Your 19 RAM Data Logging
Once you’ve determined the supported OBD2 PIDs for your 19 RAM, along with the correct bit-rate and CAN IDs, you can configure your CANedge to request the specific PIDs you’re interested in logging.
Consider these points when configuring your OBD2 PID requests:
- CAN IDs: For efficiency, switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to target specific ECUs and avoid multiple responses to each request, especially if you are primarily interested in data from the ECM.
- Request Spacing: Introduce a delay of 300-500 ms between each OBD2 request. Sending requests too rapidly (spamming the ECUs) can sometimes cause them to stop responding.
- Battery Management: To prevent battery drain, especially during extended logging sessions when the vehicle is off, use triggers to stop PID requests when the vehicle is inactive. Some CAN loggers offer features to detect ignition status and automatically start/stop logging.
- Data Filtering: If your 19 RAM also outputs OEM-specific CAN data alongside OBD2, set up filters to record only OBD2 responses. This helps keep your log files focused and manageable.
After configuring these settings, your CANedge is ready to log raw OBD2 data from your 19 RAM truck!
CANedge OBD2 PID Request List Example: Example configuration showing a list of OBD2 PID requests for CANedge data logging.
Decoded OBD2 Data Plot in asammdf: Visual plot of decoded OBD2 data using asammdf with a CAN bus DBC file.
Step #3: DBC Decode Raw OBD2 Data for Analysis
To make sense of the raw OBD2 data you’ve logged from your 19 RAM, you need to decode it into physical values (e.g., km/h, °C, RPM). This is where DBC (CAN database) files come in.
The necessary decoding information is defined in ISO 15031-5/SAE J1979 and is also available in resources like Wikipedia. To simplify this process, we provide a free OBD2 DBC file. This DBC file makes it easy to DBC decode raw OBD2 data in most CAN bus software tools, including the free asammdf tool.
Decoding OBD2 data is somewhat more complex than decoding standard CAN signals. This complexity arises because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is not enough to identify the specific signal within the payload.
To correctly decode OBD2 data, you need to consider the CAN ID, the OBD2 mode, and the OBD2 PID. This is a form of multiplexing, known as ‘extended multiplexing‘, which can be effectively managed using DBC files. Our OBD2 DBC file is designed to handle this extended multiplexing, allowing you to decode your 19 RAM OBD2 data accurately.
CANedge: Your OBD2 Data Logging Solution
The CANedge offers a streamlined way to record OBD2 data directly to an SD card (supports 8-32 GB cards). Simply connect the CANedge to your 19 RAM’s OBD2 port or any other compatible vehicle to start logging. You can then decode and analyze the logged data using free software and APIs and our OBD2 DBC file.
OBD2 logger intro
CANedge product details
OBD2 Multi-Frame Examples: ISO-TP in Action
As discussed, OBD2 communication uses the ISO-TP transport protocol (ISO 15765-2). Most examples so far have focused on single-frame communication. Here, we’ll look at examples of multi-frame communication, which are necessary for larger OBD2 data payloads, such as VIN or DTCs. These examples are relevant to advanced diagnostic procedures on your 19 RAM truck.
Multi-frame OBD2 communication relies on 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. This approach is demonstrated in the CANedge configuration example shown in the original article.
Analyzing multi-frame OBD2 responses requires CAN software and API tools that support ISO-TP, like the CANedge MF4 decoders.
OBD2 Multi-Frame Request: Example of a multi-frame request message for Vehicle Identification Number (VIN) retrieval.
Example 1: Retrieving the Vehicle Identification Number (VIN) via OBD2
The Vehicle Identification Number (VIN) is critical for vehicle identification, telematics applications, diagnostics, and more. Retrieving the VIN from your 19 RAM truck using OBD2 requests involves using mode 0x09 and PID 0x02.
To retrieve the VIN, the diagnostic tool sends a Single Frame request with PCI field (0x02), request service identifier (0x09), and PID (0x02).
The vehicle responds with a First Frame containing 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 (see ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes constitute the VIN itself, which can be converted from HEX to ASCII format using methods described in our UDS introduction.
Example 2: OBD2 Multi-PID Request (Requesting 6 PIDs at Once)
OBD2 allows diagnostic tools to request data for up to 6 mode 0x01 PIDs in a single request frame. The ECU should respond with data for all supported PIDs from the request (omitting data for unsupported PIDs), potentially using multi-frame responses via ISO-TP if necessary.
This multi-PID request feature can increase data collection efficiency and frequency. However, it also means that the signal encoding is tightly linked to the specific request method, making the use of generic OBD2 DBC files challenging for these use cases. We generally advise against using multi-PID requests for routine data logging unless you have tools specifically designed to handle them.
Below is an example trace illustrating a multi-PID request and response:
The multi-frame response structure is similar to the VIN example, but the payload includes the requested PIDs themselves, followed by the data for each PID. In practice, the PIDs in the response are often ordered as they were requested, but this is not strictly mandated by ISO 15031-5.
Decoding these multi-PID responses using generic DBC files is complex. Therefore, for practical data logging, especially on vehicles like the 19 RAM, we recommend sticking to single-PID requests unless you are using specialized tools that are designed to handle multi-PID responses. The complexity arises from the extended multiplexing and the need to account for payload position of each PID, which can vary across different vehicle models and supported PID sets.
Example 3: Diagnostic Trouble Codes (DTCs) Retrieval via OBD2
You can use OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’, to retrieve emissions-related Diagnostic Trouble Codes (DTCs) from your 19 RAM. The request for DTCs in mode 0x03 does not include a PID. The targeted ECU(s) will respond with the number of DTCs currently stored (which may be zero if no DTCs are active), 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 as per ISO 15031-5 and ISO 15031-6. The first two bits define the DTC ‘category’, and the remaining 14 bits form a 4-digit code (displayed in hexadecimal format), as shown in the visual below. Decoded DTC values can be looked up using various online OBD2 DTC lookup tools, such as repairpal.com.
The example below illustrates a response from an ECU with 6 stored DTCs.
OBD2 DTC Decoding Example: Illustrating the interpretation of OBD2 Diagnostic Trouble Codes (DTCs) using DBC.
OBD2 Data Logging: Use Case Examples for Your 19 RAM and Beyond
OBD2 data, especially from vehicles like your 19 RAM truck, has numerous applications across various sectors:
Vehicle Data Logging for Cars and Trucks
OBD2 data logging from vehicles like the 19 RAM can be used for a wide range of purposes, including fuel efficiency analysis, driver behavior improvement, testing of prototype vehicle components, and insurance telematics.
Explore OBD2 Loggers
Real-Time Vehicle Diagnostics
OBD2 interfaces enable real-time streaming of vehicle data, which is invaluable for diagnosing vehicle issues and monitoring performance in real-time, whether in a workshop or during on-road testing of your 19 RAM.
Learn about OBD2 Streaming
Predictive Maintenance and Fleet Management
Integrating OBD2 data logging with IoT solutions allows for remote vehicle monitoring, predictive maintenance scheduling, and improved fleet management for businesses operating 19 RAM trucks or similar vehicles.
Discover Predictive Maintenance Solutions
Vehicle Black Box Recording
An OBD2 logger can serve as a ‘black box’ for vehicles and equipment, recording critical data that can be used in incident analysis, warranty claims, and diagnostic investigations, providing crucial insights into vehicle operation and events involving your 19 RAM.
Explore CAN Bus Black Box Loggers
Do you have a specific OBD2 data logging use case in mind? Contact us for a free consultation!
Contact Us for Expert Advice
For more in-depth introductions to CAN bus and related technologies, explore our guides section or download our comprehensive ‘Ultimate Guide’ PDF.
Ready to start logging and streaming OBD2 data from your 19 RAM or other vehicles?
Get your OBD2 data logger today!
Buy OBD2 Data Loggers Now Contact Us for Support
Recommended Resources
OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA
CANEDGE2 – PRO CAN IoT LOGGER
CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN
