How-to Guide for OBDII Reader App Development

Why does your vehicle need it?

1. Have you ever thought about different vehicle parameters being displayed in your own Android application? If so, then you've come to the right place. We will discuss what it takes to develop an OBDII reader application.

First, let's take a quick look at the protocols used in vehicles for diagnostics.

OBD is an acronym for “on-board diagnostics” and refers to vehicle's self-diagnostics and reporting capability. Originally it was intended to help mechanics run quick vehicle diagnostics. The early versions of it allow checking for possible problems with the engine. Nowadays, in addition to preserving the “diagnostics” part, this system has been dramatically enhanced and allows a vehicle owner to be in control of different parameters like the current fuel consumption rate, gear and transmission modes, GPS module and so on. For a full understanding of how it works and the history behind it, you can read the full article on Wikipedia called “On-board diagnostics”.

Necessary materials

First of all, you would need a OBD2 Appareils adapter to be able to use the OBDII interface. There are many adapters from different manufacturers. Some of them have a COM interface, others have a USB interface, and some have a Bluetooth interface. Theoretically, any adapter can be used by the Android application, but in practice, your best choice is the Bluetooth interface.Also, adapters can be differentiated by supported OBDII protocols (i.e. by supported vehicles).So if you have a car within reach and good OBDII adapter we can start developing OBDII reader application.

Hold on - do you really have a car close enough to your development environment? Actually we can use a simulator for a start. The one that worked for me is OBDSim: it is an open source project available for different platforms. Since Bluetooth is not supported on Windows, rebuilding it from scratch in Linux will be necessary. Please note that most likely it will require you to modify the source code and change RFCOMM channel to the first available instead of channel 1.

What's more, a hardware emulator can be used instead of a real car. I used ECUsim 2000 standard with ISO 15765 (CAN) protocol enabled. As for the OBDII adapter - I used ELM327 v.1.5 adapter.

Developing the application

Let's start with describing the protocol that is used for communication between Android device and OBDII adapter/vehicle. It is text-based polling type protocol. This means that all you need is to send a command to receive a response. And knowing what commands to send is key.

We will connect to the adapter through Bluetooth. It seems that Bluetooth Low Energy API is just the thing we should use. However, since it is now supported only by several devices, it is too early to use it.

The protocol supports some AT commands like turning echo and control line feed. Another part of the protocol is OBDII control protocol itself.

The general workflow of the application functionality should go like this:

1) connect to the OBDII adapter through Bluetooth;

2) initialize OBDII adapter with AT commands;

3) continuously get data from the vehicle through issuing the corresponding PID codes.

Connecting to the OBDII adapter is straightforward. But one thing you need to do before connecting is to select the Bluetooth device. Displaying an alert dialogue with single choice items is a good way to go:

ShowShow code

Don’t forget to save the selected device address somewhere. Now we can connect to the selected device:

ShowShow code

The UUID I mentioned represents a “serial” interface through Bluetooth. Of course, this code should be executed in a non-UI thread. Also, I would recommend checking this article for details and a solution of a bug in Android that can lead to connection failure in some cases. We  can now make the data exchange. We will use a OBD-Java-API library for this. The library is pretty simple to use. It has several classes, which correspond to different OBD commands. Don't forget to initialize the OBDII adapter first by issuing configuration commands:

ShowShow code

We are now ready to issue any other commands:

ShowShow code

Here I should point that this library has some issues with parsing response and it often crashes because of poor error handling. The first flaw is the “performCalculations” method present in all command classes. It would be good to check the buffer size before accessing buffer data, because in some cases the response may be shorter than required. Of course, the problem of a shorter response is on the OBDII adapter/vehicle side, but the library should be ready for such issues.

Apart from this, there are some other issues, so this library still requires improvements or can be used simply as a reference.

The obtained data can be stored somewhere for further analysis, for example, on the ElasticSearch instance.

Right now, we are working on a Hours of Service application for commercial vehicle drivers and will continue sharing our experience on OBDII in our blog. Meanwhile, you can find more information on developing applications for latest IoT gadgets in our experience section Apps for Connected Devices.

View more: