How to interface with your car?
OBD-II protocol has been around for quite some time now and it’s been a great breakthrough in communicating with vehicle ECUs and vehicular data analysis. While this protocol opens doors for innovators to work on h/w and s/w that can help troubleshoot vehicles, it also can lead to apps that make driving fun! Whatever be the end product, it all starts with the OBD-II based adapter.
A heads on the adapter, it’s based on the OBD-II ELM327 protocol and works with most cars manufactured post the ’96 era. So it ought to work with your car unless you’ve got a Herbie. Yeah, that’s a laugh. This piece of writing isn’t focussed on setting up, but on how to send/receive data to/from this adapter. Let’s get started in Android!
The OBD Terminal Design
Messing with your Android Terminal without really firing up one physically is a feat made possible through an Android app, voila. This piece of writing again, assumes that you’ve got a rough idea about the Java behind the execution of simple terminal commands. Nevertheless, the OBD terminal is quite simple and wouldn’t necessitate this requirement. Let’s get started from scratch.
OBD-II adapters are bluetooth powered devices that communicate with their Android hosts through sockets. A socket for a particular adapter can be opened (connected) facilitating data exchange through IO streams. An adapter is identified by your Android device by virtue of it’s unique MAC or hardware ID. The MAC address can be viewed under Bluetooth settings -> paired devices -> your adapter’s properties on your Android phone. The MAC address is coupled with UUID (a universal identifier which (assume for the moment) is constant). With these details, you create your RFCOMM socket to interface with your car’s ECU. Now that you’ve created your socket, get the input and output streams linked with this socket to write commands directly to your car and get its response. That’s what’s shown here.
Now you’re set and what’s left is to send commands and receive their outputs and in order to process that, we bind the IO streams objects to their character-oriented stream classes’ objects. This makes communication easier. Now here’s our code.
Writing Commands
Now that’s how our framework looks for the most part! Now let’s go ahead and write some commands directly to the car and analyse the replies. Oh wait, what commands? Let’s take a deeper look into the OBD-II protocol.
Commands are understood as PIDs or process IDs which are basically hex numbers. They conveniently cover all possible commands designed to be handled by the protocol. A list of these commands can be found up here — https://en.wikipedia.org/wiki/OBD-II_PIDs#Mode_01.
Every command skeleton looks something like XX YY. The XX refer to the mode bits (Mode 01 in the aforementioned chart) and the YY refer to the command or PID bits (The first column in the aforementioned chart).
Let’s take a scenario where you’d wish to know your vehicle’s current RPM. Now let’s look up the list of commands to find the one that matches our motive. We see that the command 01 0C could accomplish this. Bingo! Now let’s write this command using our DataOutputStream object and fetch the reply from our car.
Now we have our completed code here.
Now that we’re done, I’d like to explain why the first occurrence of the readLine() method gives the command itself and now the output for which we write it once more (in the next line). This is because the android terminal in the backyard, looks something like this when we execute our command 01 0C.
>01 0c
41 0C 0D 4C
Now, our BufferedReader object captures both the lines — the first line that holds our command and the second that holds the output.
Voila! We’re done with a simple program that measures the RPM of our car at a given time using the OBD-II protocol. Ain’t it as simple? This is the crux of every killer vehicle diagnostics app. The most famous app that hits my mind right now is Torque — https://play.google.com/store/apps/details?id=org.prowl.torque&hl=en.
Hope this works alright for you, cheers!