Modern vehicles contain sophisticated onboard computers that monitor engine performance, emissions, and dozens of other parameters. The OBD-II (On-Board Diagnostics II) standard, mandated in all US vehicles since 1996, provides a standardized way to access this data. This project explores building custom software interfaces to read and display real-time vehicle information.
Project Overview#
The goal was to create a custom gauge display system using:
- An ELM327-based interface board to communicate with the vehicle
- Custom C# software to decode and display the data
- Eventually, an ARM microcontroller with an LCD for a standalone dashboard
This project started with software development and proof-of-concept on a PC, with plans to migrate to embedded hardware for a finished in-vehicle installation.
The ELM327 Interface#
The ELM327 chip handles all the low-level protocol details for communicating with vehicle computers. It supports multiple OBD-II protocols:
- SAE J1850 PWM
- SAE J1850 VPW
- ISO 9141-2
- ISO 14230-4 KWP
- ISO 15765-4 CAN
The chip automatically detects which protocol the vehicle uses and translates everything to simple ASCII commands over RS-232 serial. This makes it accessible from PCs, microcontrollers, or smartphones without needing to implement complex automotive protocols.
Understanding PIDs#
Parameter IDs (PIDs) are standardized codes for requesting specific information from the vehicle. Common PIDs include:
010C- Engine RPM010D- Vehicle Speed0105- Engine Coolant Temperature010F- Intake Air Temperature0111- Throttle Position0104- Calculated Engine Load
The vehicle responds with hexadecimal data that must be decoded according to formulas specified in the SAE J1979 standard. For example:
- RPM: (256×A + B) / 4
- Speed: A (km/h)
- Coolant Temp: A - 40 (°C)
Where A and B are the hex bytes returned by the vehicle.
Initial Software Development#
I developed a C# WinForms application to:
- Communicate with the ELM327 over serial
- Send PID requests
- Parse and decode responses
- Display data in real-time
The initial version was a testing tool to understand the protocols and verify correct communication. Getting reliable communication required proper timing—sending requests too quickly could overflow the vehicle’s buffer, while waiting too long made the display laggy.
Technical Challenges#
PID response parsing: Different vehicles return data in slightly different formats. The software needed to handle variations in response structure.
Update rates: Some PIDs update faster than others. RPM changes rapidly, while coolant temperature is essentially static. The software needed to poll different parameters at appropriate rates.
Error handling: Vehicles sometimes don’t respond to certain PIDs, either because they don’t support that parameter or because the sensor has failed. Robust error handling was essential.
Dashboard Application#
The dashboard application took the test software further, creating a graphical interface with:
- Real-time gauge displays
- Data logging to CSV files
- Configurable update rates
- Support for multiple simultaneous PIDs
This served as a proof-of-concept for the standalone hardware version. Having a working PC implementation made it easier to debug the embedded version later—I could compare outputs to ensure the ARM microcontroller was decoding data correctly.
Future Development#
The original plan was to build a standalone dashboard using:
- STM32 ARM Cortex-M3 microcontroller
- Color LCD display
- SD card for logging
- Custom PCB to integrate everything
This would create an in-vehicle gauge display showing information not available on the stock dashboard, with data logging for performance analysis or diagnostics.
Potential Applications#
Performance monitoring: Log acceleration runs, track day data, or fuel economy
Diagnostics: Read and clear trouble codes without expensive scan tools
Custom gauges: Display parameters the manufacturer doesn’t show
Data analysis: Export logged data for detailed analysis of driving patterns or engine performance
Source Code#
The C# test application and early dashboard code are available in the sourceforge archive. The code is released under GPL v3, free to modify and redistribute.
The project demonstrates interfacing with automotive systems using low-cost hardware and open-source software. While commercial OBD-II scan tools and apps are now ubiquitous, building your own provides deeper understanding of vehicle communication protocols and complete control over the interface.
Editor’s Note (2025): This article combines OBD-II project posts from 2009. The language has been updated for clarity and dead links removed. While smartphone apps now provide similar functionality more conveniently, building custom OBD-II interfaces remains educational and useful for specialized applications. Modern vehicles (2016+) may use additional proprietary protocols beyond standard OBD-II for accessing certain parameters. The source code mentioned is available in historical archives but would require updating for modern development environments.