-
-
After connecting to the vehicle via a bluetooth ELM327 adapter, live vehicle telemetry is shown in a table.
Inspiration
Before studying computer science, I worked as an automotive technician. I saw how difficult it can be for drivers to understand what is happening inside their vehicles without expensive diagnostic equipment or specialized knowledge. That experience inspired me to combine my automotive background with Python and build a tool that makes vehicle data easier to access and understand.
What It Does
My OBD-II Telemetry App connects to a vehicle through an OBD-II Bluetooth adapter and retrieves live engine data, including:
- Engine RPM
- Vehicle speed
- Coolant temperature
- Throttle position
- Battery voltage
The application sends standard OBD-II commands, receives the vehicle's raw responses, and converts them into readable measurements. For example, engine RPM is calculated from two response bytes using:
$$ \text{RPM} = \frac{256A + B}{4} $$
where (A) and (B) are hexadecimal values returned by the vehicle.
How I Built It
I built the project in Python using the bleak library for Bluetooth Low Energy communication. The application:
- Scans for nearby Bluetooth devices.
- Allows the user to select an OBD-II adapter.
- Connects to the adapter and discovers its Bluetooth services and characteristics.
- Identifies the characteristics used to send commands and receive notifications.
- Sends initialization commands to the ELM327-compatible adapter.
- Requests specific OBD-II parameter IDs.
- Parses the responses and displays readable telemetry data.
I structured the communication asynchronously so the application could receive Bluetooth notifications without blocking the rest of the program. I also added a response queue and timeout handling to prevent the application from waiting indefinitely when an adapter does not respond.
Challenges I Faced
The most difficult part was establishing reliable Bluetooth communication. Different OBD-II adapters expose different services and characteristics, so I could not assume that every device would use the same configuration.
Bluetooth behavior also varied between operating systems. My adapter was not always stable on macOS, which made testing more difficult. To continue developing without depending entirely on a physical vehicle, I experimented with simulated Bluetooth devices and mock OBD-II responses.
Another challenge was parsing responses from the ELM327 adapter. Responses can contain command echoes, spaces, prompt characters, carriage returns, or incomplete data. I had to clean and validate each response before converting the hexadecimal values into useful measurements.
What I Learned
This project taught me how asynchronous programming works in a real application. I gained experience with Python's asyncio, Bluetooth Low Energy communication, notification callbacks, queues, timeouts, hexadecimal data, and automotive communication protocols.
I also learned that hardware-software integration requires more than writing code. Debugging often involves examining the operating system, Bluetooth stack, adapter behavior, vehicle protocol, and application logic together.
Most importantly, I learned how to approach an unfamiliar technical problem incrementally: first discovering a device, then establishing a connection, sending one command, receiving one response, and gradually building those pieces into a working telemetry application.
What's Next
I plan to expand the application with diagnostic trouble-code support, data logging, a live graphical dashboard, and AI-assisted troubleshooting. My long-term goal is to create an accessible diagnostic assistant that not only displays vehicle data but also helps users understand what that data may mean.
Log in or sign up for Devpost to join the conversation.