As mentioned in previous article today I would be talking about OBD-II integration in Lizzie using a Bluetooth serial communication with an ELM327 adapter that fits on a OBD-II port in your car. OBD stands for On Board Diagnostics which is connected to the ECU (Engine Control Unit) and provides a ton of information (both real-time and from logs) which you can use for things like monitoring and diagnosing your vehicle for performance and maintenance. My use case in Lizzie is to read real time data, log it in reference to places that I visit (using GPS), study my driving patterns and then use that data for building intelligence like what are my driving habits, determining road conditions based on average driving speeds at different places, anticipating travel times based on previous data and so on. Apart from all this it would also be cool to have a warning if the speed is unusual at some point (by unusual I mean – not normal based on my driving patterns). So now let’s talk about the practical stuff.
Before we talk any further, here is a video of the communication happening with a simulator.
For doing my development and testing for the integration I am using an Android application that simulates an OBD-II ELM-327 Bluetooth connection (available here). Having an exact replica of a an ELM-327 device helps in making sure that we are in a position to talk to the real ECU right from the experimentation and prototyping stage. The communication happens on RS-232 specifications using AT commands (which are ancient and are being used from along time – I have worked with modems using AT commands in the past). It’s a serial communication and this article on Wikipedia would help you in understanding what is Serial communication and how it works.
Once you have connected to the ELM-327 and established a communication channel (I am using RFComm framework on Windows 10) you send out an “ATZ” command which resets the OBD-II adapter – the Adapter responds with a version of ELM software running on the adapter, next few commands are for setting up and negotiating the format of communication (message formatting etc.) to which the adapter should respond with “OK” if everything is fine, else you should adjust your requests to other variants. Once the format negotiation is complete the next steps are to go ahead and query the data from the adapter. Remember it’s a serial communication so you send a command and then wait for a response (which happens almost instantly but try to do it asynchronously to avoid blocking the execution of your application and keep it responsive). Bit’s are sent one at a time and the same happens with response, it’s not parallel so you have to write you code accordingly (which means block on a different thread until you have received the complete data and avoid any mutable state because you might have partial reads and it might become a synchronization nightmare).
The values in responses received are encoded as hex values and need to be decoded and some require additional calculation after decoding to get the actual values. This article on Wikipedia can be used as reference for OBD-II commands and responses and how to decode them. My OBD communication module is ready for integration is ready to be plugged into Lizzie and now I am working on building a dialog system.
I will be back with updates soon.
Until then…
Leave a Reply