Adding an OBD2 Port to a Version 6 STI: A Comprehensive Guide

Are you looking to add OBD2 capabilities to your Version 6 Subaru STI?

While On-Board Diagnostics (OBD2) is a standard feature in most modern vehicles, older models like the Version 6 STI might not have it readily available or in the standardized 16-pin format we know today. This guide will delve into the world of OBD2, explain why you might want to add an OBD2 port to your Version 6 STI, and what’s involved in the process.

Whether you’re a seasoned mechanic or a car enthusiast, understanding OBD2 is crucial for modern vehicle diagnostics and performance tuning. Let’s explore how you can bring your classic STI into the realm of contemporary diagnostics!

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

Understanding OBD2 and Why It Matters for Your Version 6 STI

OBD2, or On-Board Diagnostics II, is essentially your car’s self-reporting system. It’s a standardized protocol that allows access to a wealth of information about your vehicle’s health and performance through a universal OBD2 port. Originally designed for emissions monitoring, OBD2 has become invaluable for diagnosing a wide range of vehicle issues and even enhancing performance.

You’ve likely seen the check engine light (malfunction indicator light) on your dashboard. This is OBD2 in action, signaling that your car has detected a problem. Mechanics use OBD2 scanners to connect to the OBD2 16 pin connector, usually located under the dashboard near the steering wheel, to read diagnostic trouble codes (DTCs) and live data. This data, including parameters like speed, engine temperature, and sensor readings, helps pinpoint problems quickly and efficiently.

For owners of a Version 6 STI, which predates the widespread adoption of OBD2 as we know it, adding an OBD2 port can unlock a new level of diagnostic and tuning capability.

Image showing a malfunction indicator light and an OBD2 scan tool being used, illustrating the basic function of OBD2 diagnostics.

OBD2 Compatibility: Does Your Version 6 STI Have It?

The short answer is: Potentially, but not in the standard OBD2 format.

While the Version 6 STI might have some form of on-board diagnostics, it’s unlikely to be the standardized OBD2 system mandated in later vehicles. Cars manufactured before the OBD2 mandate often used proprietary diagnostic systems or early versions of OBD, which are not compatible with standard OBD2 scanners and ports.

To determine the diagnostic capabilities of your Version 6 STI, you’ll need to consult your vehicle’s service manual or seek advice from a Subaru specialist familiar with older models. You might find a diagnostic port, but it may require specific Subaru diagnostic tools rather than generic OBD2 scanners. This is where the idea of adding an OBD2 port becomes relevant.

Infographic illustrating OBD2 compliance timelines for different regions, highlighting that older vehicles may not be OBD2 compliant.

A Brief History of OBD2 and Its Evolution

Understanding the history of OBD2 helps explain why older cars like the Version 6 STI might not have it in the standard form.

OBD2’s origins trace back to California, where the California Air Resources Board (CARB) mandated on-board diagnostics in new cars from 1991 onwards for emissions control.

The Society of Automotive Engineers (SAE) then standardized the OBD2 protocol, including diagnostic trouble codes (DTCs) and the now-familiar OBD connector (SAE J1962), aiming for consistency across different manufacturers.

The rollout of OBD2 was gradual:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: Required in the EU for gasoline cars.
2003: Required in the EU for diesel cars (EOBD).
2005: OBD2 mandated in the US for medium-duty vehicles.
2008: US vehicles required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 became mandatory for heavy-duty vehicles in the US.

This timeline shows that the Version 6 STI, being a vehicle from the late 1990s, likely predates the widespread adoption of the standardized OBD2 system, especially in markets outside of the US.

Diagram illustrating the history of OBD2 and its connection to emission control and vehicle data access.

Timeline graphic summarizing the key milestones in the history and standardization of OBD2.

Image depicting the future trends of OBD, including OBD3 and remote diagnostics, suggesting the ongoing evolution of vehicle diagnostics.

The Future of OBD and the Relevance of Retrofitting for Classic Cars

While OBD2 continues to evolve with trends like WWH-OBD and OBDonUDS, and the potential for OBD3 with telematics integration, for classic car owners, the focus is often on bringing older vehicles up to modern diagnostic standards. Electric vehicles are moving away from traditional OBD2, utilizing OEM-specific UDS communication, highlighting the changing landscape of vehicle diagnostics.

However, for enthusiasts of cars like the Version 6 STI, adding an OBD2 port isn’t about future trends; it’s about accessing the wealth of diagnostic and performance data that OBD2 offers with readily available tools. This is why retrofitting an OBD2 port to a Version 6 STI can be a worthwhile project. It allows you to use standard OBD2 scanners, loggers, and tuning tools, bridging the gap between classic motoring and modern technology.

Illustration of an OBD2 connector being removed from an electric vehicle, symbolizing the shift in diagnostic approaches for EVs.

Get our ‘Ultimate CAN Guide’

Want to become a CAN bus expert and understand the technical foundation of OBD2?

Get our 12 ‘simple intros’ in one 160+ page PDF:

Download now

OBD2 Standards: The Technical Foundation

OBD2 operates as a higher layer protocol, much like a language spoken over a communication network. In modern cars, this network is typically CAN bus. Understanding OBD2 standards is crucial when considering adding an OBD2 port to an older vehicle.

Key OBD2 standards define:

The OBD2 connector (SAE J1962 / ISO 15031-3)
Lower-layer protocols (e.g., CAN, KWP2000, ISO 9141)
OBD2 parameter IDs (PIDs) (SAE J1979/ ISO 15031-5)

These standards are structured according to the 7-layer OSI model, with both SAE (US standards) and ISO (international standards) contributing. For practical purposes, when adding an OBD2 port, you’ll primarily be concerned with the connector type, the communication protocol your car’s ECU supports or can be adapted to, and understanding how to request and interpret OBD2 data.

Diagram illustrating the OSI model in relation to OBD2 and CAN bus standards, showing the layered structure of communication protocols.

Image of an OBD2 connector pinout diagram, essential for understanding the physical interface and wiring when adding an OBD2 port.

The OBD2 Connector: SAE J1962 and Pinouts

The 16-pin OBD2 connector (Data Link Connector, DLC) is the standardized interface for accessing vehicle data. Specified in SAE J1962 / ISO 15031-3, this connector provides power and communication lines.

Key things to note about the OBD2 connector:

It’s typically located near the steering wheel, though sometimes hidden behind a panel.
Pin 16 provides battery power.
The pinout configuration depends on the communication protocol used.
CAN bus, the most common protocol, uses pins 6 (CAN-H) and 14 (CAN-L).

When adding an OBD2 port to a Version 6 STI, you’ll be wiring this connector to your vehicle’s electrical and data systems, which might involve tapping into existing ECU signals or installing a standalone OBD2-compatible ECU if the original system is not adaptable.

OBD2 Connector Types: A vs. B

You might encounter 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.

The key differences are:

Power supply: Type A is typically 12V, Type B is 24V.
Baud rate: Cars (Type A) often use 500K, heavy-duty vehicles (Type B) often use 250K (sometimes 500K).
Physical distinction: Type B connectors have an interrupted groove in the middle.

For adding an OBD2 port to a Version 6 STI (assuming a 12V system), you’ll be working with a Type A connector.

Illustration comparing OBD2 Connector Type A and Type B, highlighting differences in voltage and physical structure.

Diagram emphasizing the relationship between OBD2 and CAN bus, with reference to the ISO 15765 standard.

OBD2 and CAN Bus: ISO 15765-4 and Protocol Considerations for Retrofitting

Since 2008, CAN bus (ISO 15765) has been the mandated lower-layer protocol for OBD2 in US cars. ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies how OBD2 messages are transmitted over a CAN network.

Key aspects of ISO 15765-4 include:

CAN bus bit-rate: 250K or 500K.
CAN ID length: 11-bit or 29-bit.
Specific CAN IDs for OBD requests and responses.
Diagnostic CAN frame data length: 8 bytes.
Max OBD2 adapter cable length: 5 meters.

When retrofitting OBD2 to a Version 6 STI, you’ll need to ensure compatibility with the chosen OBD2 protocol and potentially integrate a CAN bus interface if the original ECU communication is not CAN-based. Alternatively, some aftermarket ECUs designed for older vehicles may offer built-in OBD2 and CAN bus support, simplifying the process.

OBD2 CAN Identifiers (11-bit, 29-bit)

OBD2 communication relies on request/response message pairs. In most cars, 11-bit CAN IDs are used for OBD2.

Functional Addressing (Request): CAN ID 0x7DF (queries all OBD2-compatible ECUs).
Physical Addressing (Request): CAN IDs 0x7E0-0x7E7 (requests to specific ECUs).
Responses: CAN IDs 0x7E8-0x7EF. Common response IDs are 0x7E8 (ECM) and 0x7E9 (TCM).

Some vehicles, especially larger ones, use extended 29-bit CAN identifiers for OBD2.

Functional Addressing (29-bit): 0x18DB33F1.
Responses (29-bit): 0x18DAF100 to 0x18DAF1FF.

Understanding these CAN IDs is essential for configuring OBD2 scanners and loggers when you’ve added an OBD2 port to your Version 6 STI.

Diagram showing the request-response frame structure in OBD2 communication, highlighting the role of PIDs and data parameters.

Image contrasting OBD2 CAN bus data with proprietary OEM-specific CAN bus data, emphasizing the standardized nature of OBD2.

OBD2 vs. Proprietary CAN Protocols: Implications for Retrofitting

It’s important to remember that OBD2 is an additional protocol layered on top of the OEM’s proprietary CAN communication within the vehicle. Your Version 6 STI’s original ECU operates using Subaru’s own communication protocols, not OBD2.

When you add an OBD2 port, you are essentially creating a gateway to access a subset of vehicle data in a standardized format. This might involve:

Adapting the original ECU: If possible, reprogramming or adding modules to your STI’s ECU to support OBD2 communication and output data in the required format. This is often complex and may not be feasible with older ECUs.
Installing an aftermarket OBD2-compatible ECU: Replacing the original ECU with a modern aftermarket ECU that supports OBD2 and is compatible with the Version 6 STI’s engine and systems. This is a more comprehensive but potentially more costly solution.
Using an OBD2 interface module: Employing a standalone module that intercepts data from the original ECU and translates it into OBD2-compliant messages. This can be a simpler approach for basic OBD2 functionality but might have limitations in data availability.

The choice depends on your technical expertise, budget, and desired level of OBD2 integration.

Bit-rate and ID Validation: Ensuring Correct Communication

OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern cars commonly use 500K and 11-bit IDs.

When setting up your OBD2 system after retrofitting, you’ll need to validate the correct bit-rate and ID configuration. ISO 15765-4 provides a validation sequence to determine the correct settings. This involves sending specific OBD2 requests and checking for valid responses. Tools like CAN bus analyzers or OBD2 scanners with protocol auto-detection can assist with this process.

Flowchart illustrating the process of OBD2 bit-rate and CAN ID validation as per ISO 15765-4, important for ensuring correct communication settings.

Image showcasing the five lower-layer OBD2 protocols, including CAN, KWP2000, SAE J1850, and ISO 9141, highlighting the diversity of communication methods.

Five Lower-Layer OBD2 Protocols: Beyond CAN

While CAN bus is dominant today, older OBD2 systems used other lower-layer protocols. If you’re working with a very early OBD2 implementation or considering alternative protocols for your Version 6 STI retrofit, be aware of these:

ISO 15765 (CAN bus): Predominant in modern vehicles.
ISO14230-4 (KWP2000): Used in some 2003+ vehicles, particularly in Asia.
ISO 9141-2: Common in EU, Chrysler, and Asian cars in the early 2000s.
SAE J1850 (VPW & PWM): Used primarily in older GM and Ford vehicles, respectively.

Pinouts of the OBD2 connector can sometimes indicate the protocol in older vehicles. However, for a Version 6 STI retrofit, focusing on CAN bus compatibility is generally the most practical approach due to the widespread availability of CAN-based OBD2 tools and components.

ISO-TP: Transporting OBD2 Messages

OBD2 messages are transported over CAN bus using ISO-TP (ISO 15765-2), a transport protocol that allows for messages longer than the 8-byte CAN data payload. This is necessary for transmitting data like VIN or DTCs.

ISO-TP handles segmentation, flow control, and reassembly of larger OBD2 messages. However, many common OBD2 parameters fit within a single CAN frame, using ‘Single Frame’ (SF) format as defined by ISO 15765-2.

Diagram illustrating different ISO-TP frame types used in OBD2 communication, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.

The OBD2 Diagnostic Message: Modes and PIDs

An OBD2 message, in its simplest form, consists of an identifier, data length (PCI field), and data. The data itself is structured into:

Mode (Service): Defines the type of diagnostic request (e.g., request current data, read DTCs).
Parameter ID (PID): Specifies the specific data parameter being requested within a mode (e.g., vehicle speed, engine RPM).
Data Bytes: Contain the actual data values or parameters.

Breakdown of an OBD2 message structure, explaining the components like Mode, PID, and Data Bytes within a CAN frame.

Example: OBD2 Request/Response for Vehicle Speed

Let’s illustrate with an example: requesting vehicle speed.

Request: An OBD2 scanner sends a request message with CAN ID 0x7DF, containing Mode 0x01 and PID 0x0D (Vehicle Speed).
Response: The car responds with CAN ID 0x7E8, including the vehicle speed value in the data bytes.

By consulting OBD2 PID documentation, you can decode the data bytes into physical values (e.g., km/h, mph). When retrofitting OBD2, ensuring your chosen ECU or interface module correctly handles these request/response sequences is crucial.

Example of an OBD2 request and response sequence for Vehicle Speed, showing the CAN IDs and data payload.

Detailed example of OBD2 PID 0x0D (Vehicle Speed), illustrating the request frame, response frame, and data interpretation.

Diagram outlining the 10 standard OBD2 service modes (modes 0x01 to 0x0A), each serving different diagnostic functions.

The 10 OBD2 Services (Modes)

OBD2 defines 10 diagnostic services (modes), each identified by a mode number (0x01 to 0x0A). Key modes include:

Mode 0x01: Show current data (real-time parameters).
Mode 0x02: Show freeze frame data (data recorded when a DTC is set).
Mode 0x03: Show stored DTCs.
Mode 0x04: Clear DTCs and emission-related diagnostic information.

Not all vehicles support all OBD2 modes, and some manufacturers may implement OEM-specific modes beyond the standard 10. In OBD2 messages, the mode is the second byte. In responses, 0x40 is added to the requested mode number.

OBD2 Parameter IDs (PIDs)

Within each OBD2 mode, Parameter IDs (PIDs) specify the particular data parameter you are requesting. Mode 0x01, for example, has approximately 200 standardized PIDs for real-time data like speed, RPM, and fuel level.

A crucial PID for OBD2 compatibility testing is Mode 0x01 PID 0x00. If an ECU supports OBD2 services, it must support this PID. Responding to PID 0x00, the ECU indicates which PIDs in the range 0x01-0x20 it supports. PIDs 0x20, 0x40, and so on, similarly indicate support for subsequent PID ranges within Mode 0x01.

(Repeated image – consider replacing or removing one instance)

Screenshot of an OBD2 PID overview tool, demonstrating a resource for looking up and understanding OBD2 PIDs and their descriptions.

Tip: OBD2 PID Overview Tool

Resources like OBD2 PID overview tools are invaluable for understanding and decoding OBD2 data. These tools provide scaling information for standard OBD2 PIDs, allowing you to convert raw data bytes into meaningful physical values. When working on your Version 6 STI OBD2 retrofit, such tools can help verify data accuracy and troubleshoot communication issues.

OBD2 PID overview tool

Practical Steps for Adding an OBD2 Port to Your Version 6 STI (Conceptual Overview)

While a detailed step-by-step guide for adding an OBD2 port to a Version 6 STI is beyond the scope of this article due to the vehicle-specific nature of the process, here’s a conceptual overview of the steps involved:

Assess your Version 6 STI’s existing diagnostic capabilities: Determine if there’s any existing diagnostic port and what type of system it uses. Consult service manuals and expert resources.
Choose an OBD2 implementation approach: Decide whether to adapt the original ECU (if feasible), install an aftermarket ECU, or use an OBD2 interface module.
Select an OBD2-compatible ECU or interface: Choose components that are compatible with the Version 6 STI’s engine and systems and support the desired OBD2 functionality.
Wiring and electrical connections: Wire the OBD2 connector (SAE J1962) to the chosen ECU or interface module, ensuring correct pinouts for power, ground, CAN communication lines, and any other necessary signals.
ECU configuration and programming: Configure the new ECU or interface module for OBD2 communication, including setting the correct CAN bit-rate, CAN IDs, and supported PIDs. This might involve custom programming or using pre-configured settings if available.
Testing and validation: Connect an OBD2 scanner to the newly installed OBD2 port and verify communication. Test basic OBD2 functions like reading PIDs (e.g., vehicle speed, engine RPM) and DTCs. Use OBD2 PID tools and CAN bus analyzers for in-depth validation.
Troubleshooting and refinement: Address any communication issues, data errors, or functionality problems. Refine wiring, ECU configuration, or programming as needed.

Important Considerations:

Complexity: Retrofitting OBD2 to an older vehicle can be a complex undertaking requiring electrical wiring, ECU programming, and diagnostic expertise.
Vehicle-specific knowledge: Thorough knowledge of the Version 6 STI’s electrical and engine management systems is essential.
Professional assistance: Consider seeking help from a qualified mechanic or automotive electronics specialist experienced in classic car modifications and OBD2 retrofitting.
Safety: Exercise caution when working with vehicle electrical systems. Disconnect the battery before making any wiring changes.

OBD2 Data Logging and Decoding: Next Steps After Retrofitting

Once you’ve successfully added an OBD2 port to your Version 6 STI, you can leverage the power of OBD2 data logging and analysis. Tools like the CANedge CAN bus data logger can be invaluable for this.

The CANedge allows you to:

Configure custom CAN frames to transmit OBD2 requests.
Log OBD2 data to an SD card when connected via an OBD2-DB9 adapter cable.
Decode and analyze logged data using free software and DBC files.

Diagram illustrating the use of an OBD2 data logger to send requests and receive responses for OBD2 PIDs, enabling data acquisition for analysis.

Screenshot of OBD2 Supported PIDs test responses in asammdf software, displaying the data received from PID requests.

Step-by-Step OBD2 Data Logging with CANedge (Conceptual after Retrofit)

Test bit-rate, IDs, and supported PIDs: Use CANedge or similar tools to validate the correct bit-rate and CAN ID configuration for your OBD2 setup. Send ‘Supported PIDs’ requests (Mode 0x01 PID 0x00) to determine which PIDs your system supports.
Configure OBD2 PID requests: Create a transmit list in CANedge to request the specific OBD2 PIDs you want to log (e.g., engine RPM, coolant temperature, boost pressure). Consider using ‘Physical Addressing’ CAN IDs (0x7E0-0x7E7) for more targeted requests. Add appropriate spacing between requests to avoid overloading the ECU.
DBC decode raw OBD2 data: Use an OBD2 DBC file (like the free one provided by CSS Electronics) and CAN bus analysis software (e.g., asammdf) to decode the raw OBD2 data into physical values for analysis and visualization.

Example of an OBD2 transmit list configuration in CANedge software, showing PID requests for data logging.

Screenshot from asammdf software displaying decoded and visualized OBD2 data, showing engine parameters plotted over time.

OBD2 Multi-Frame Examples: VIN and DTCs

OBD2 also supports multi-frame communication using ISO-TP for data that exceeds a single CAN frame. Examples include requesting the Vehicle Identification Number (VIN) and Diagnostic Trouble Codes (DTCs).

Example 1: OBD2 Vehicle Identification Number (VIN)

To retrieve the VIN using OBD2, you use Mode 0x09 and PID 0x02. This typically involves a multi-frame response due to the VIN’s length.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

Requesting DTCs (Mode 0x03) also often involves multi-frame responses if multiple DTCs are stored. DTCs are 2-byte codes that can be decoded using OBD2 DTC lookup tools.

Diagram explaining the structure and interpretation of OBD2 Diagnostic Trouble Codes (DTCs), showing the breakdown of the 2-byte DTC value.

OBD2 Data Logging Use Cases: Unleashing the Potential of Your Retrofitted Port

Adding an OBD2 port to your Version 6 STI opens up various exciting use cases:

Performance Monitoring and Tuning

Log engine parameters like boost pressure, air-fuel ratio, RPM, and throttle position to monitor performance, diagnose issues, and fine-tune your STI for optimal power and efficiency.

obd2 logger

Real-time Diagnostics

Use OBD2 interfaces and software to stream live data for real-time diagnostics, allowing you to monitor your STI’s health while driving and quickly identify potential problems.

obd2 streaming

Track Days and Performance Analysis

Record data during track days to analyze driving performance, identify areas for improvement, and optimize your STI’s setup for circuit driving.

predictive maintenance

Classic Car Telemetry and Data Display

Integrate OBD2 data with custom gauges or digital displays to create a modern telemetry system for your classic STI, blending vintage charm with contemporary data visualization.

can bus blackbox

Do you have an OBD2 data logging use case for your project car? Reach out for free consultation!

For more introductory guides, explore our tutorials section or download the comprehensive ‘Ultimate Guide’ PDF [https://www.csselectronics.com/pages/can-bus-ultimate-guide]

Ready to explore OBD2 data logging for your Version 6 STI?

Get your OBD2 data logger and start analyzing your car’s performance today!

Buy now Contact us

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

[