Difference between revisions of "F12: OBD-II Android Monitor"

Revision as of 21:41, 13 December 2012

OBD-II Android Monitor

Abstract

Interfacing a PLX Devices Kiwi Bluetooth to an Android mobile device. The PLX Devices Kiwi contains an ELM327 OBD-II to RS232 interpreter that gathers vehicle information. An Android application will be designed to gather real time information from the vehicle such as RPM, MPH, and intake temperature. The designed application will also be able to clear diagnostic trouble codes.

Features & Objectives

The OBD-II Android Monitor project establishes a wireless Bluetooth communication link between an Android mobile device and an automobile’s On-Board Diagnostics system (OBD). Information is transmitted between these components using an ELM Electronics ELM327 microcontroller. The ELM327 converts data from OBD-II protocols to RS-232, emulating the Bluetooth communication to run in serial port profile (SPP). To interface an Android device with the ELM327, an application will be designed. This application will have a graphical user interface (GUI) which will be able to display vehicle information such as MPH and RPM. The objectives for the OBD-II Android Monitor project is shown below.

• Establish communication with vehicle on board diagnostics computer with Android device
• Design and create Android Application with features of:

a) Gather real time vehicle engine information such as Intake temperature, Engine coolant temperature, MPH, RPM, Voltage, etc.

b) Clear check engine lights (CEL)

Team Members and Responsibilities

• Ryan James Cristobal
  • Communication Link Between ELM327 and Android Application
  • Parsing Data from ELM327 for Gauges
• Jonathan Luong
  • Application GUI (Animated Gauges)
  • Data Conversion

Schedule

Parts List & Cost

Hardware

• PLX Devices Kiwi Bluetooth [$99.95]
• ASUS Nexus 7 Tablet (running Android 4.2.1) [$249.95]

Software

• Windows Vista / 7 (32 or 64-bit)
• Eclipse IDE

a) Must be 3.6.2 (Helios) or higher

b) JDT Plugin (newer IDE packages will have this plugin included)

• Android SDK
• ADT Plugin (recommended but not required)

a) 20.0.0 or higher

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

Discuss your hardware design here. Show detailed schematics, and the interface here.

The OBD-II is a computer system built into modern vehicles. The OBD-II is responsible for monitoring and recording vehicle operating information such as temperatures and engine fault codes. Following different protocols such as SAE J1979, SAE J1850, ISO 9141-2, and etc, many users are using the OBD-II interface as a scan tool to diagnose the status of their vehicles. A pinout of the OBD-II connector is shown in Figure 1. There are many OBD-II adapter devices in the market that range from $25-$200. The OBD-II Android Monitor project uses the PLX Kiwi Bluetooth by PLX Devices.

Figure 1. OBD-II Pin Layout

Figure 2 is the block diagram for the OBD-II Android Monitor project. The Nexus 7 tablet communicates with the PLX Bluetooth Kiwi using serial over Bluetooth (SPP). Refer to the Hardware Interface section for details.

Figure 2. Hardware Block Diagram

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

The hardware interface for this project consisted of establishing a Bluetooth communication link for the Kiwi device. Because the project used the Serial Profile Port (SPP) protocol, a specific Universally Unique Identifier (UUID) was needed to enable that protocol. SPP is based off of the RFCOMM which emulates the signals for RS-232 communication. By using SPP, the Kiwi Bluetooth device would be able to send and receive different ASCII values through the serial stream. Similar to RS-232 communication, the PLX Kiwi behaves like a transceiver which will send and receive data from the vehicle's ECU to the Android tablet. Figure 3 below shows the UUID was initialization code for the Android application.

Figure 3. UUID Code

Figure 3 shows the UUID that is specific to SPP. This needed to be changed in the BluetoothChat sample code to enable the program to be used with an SPP device such as the Kiwi Bluetooth. The reason for change is because BluetoothChat is used for communication between two Android devices rather than an Android and SPP device.

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

In preparation of the design for the OBD-II Android Monitor, Android Application Requirements were drafted and shown below.

Android Application Requirements:

R1. The Android OBD-II Monitor application shall have a graphical user interface.

R2. The Android OBD-II Monitor application shall use Bluetooth wireless communication to connect to the ELM327 microcontroller.

R3. The Android OBD-II Monitor application shall be able to clear engine trouble diagnostic codes.

R4. The Android OBD-II Monitor application shall display multiple vehicle parameters on screen.

R4-a. Parameters chosen are MPH, RPM, coolant temperature, intake temperature, engine load percentage, and voltage.

As seen in the requirements, an Android application must be created to interface with an ELM327 microcontroller to retrieve vehicle data. To start with the design, we first focused on how to we wanted our graphical interface to look like. The design in mind was to have gauges and the parameters to be changing as accurately as possible.

After the GUI, the next application design consideration was how to get the desired data from the vehicle. The design of the ELM327 software operates by servicing a single command. This gives our software design a performance drawback due to the fact that we cannot get all of the vehicle parameters simultaneously. To make our application seem "real time", we need to obtain data as efficiently as possible. To do this, we created the data flow algorithm discussed below:

1.) Send first command string

2.) Wait until ">" is received, (which indicates that the ELM327 is ready)

3.) Send next command string

4.) Go back to step 2 and repeat

From the algorithm, constant data flow between the Android application and the ELM327 has been established. The next thing to consider is the method of parsing each message to obtain the desired data. Parsing of data proved to be one of the big challenges faced in this project as the data was not in a consistent format. Data was received with extra spaces, newlines, and null characters. Messages were also often split up randomly when read. To solve our parsing problem, as discussed in the Technical Challenges section, the use of Java String functions and regular expressions was used. More information about the parsing solution will be discussed later.

Software Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

The main purpose of the software implementation was to create an Android application which established a wireless communication link via Bluetooth with the PLX Kiwi device. This was achieved by using the Eclipse IDE, Android Software Development Kit (SDK), and Android Virtual Device (AVD). Written in Java and in API 17, the application was created for Android OS 4.2 (Jelly Bean). Users who are new to the Android environment can find more information and a tutorial guide through this link.

Some features for the application such as enabling Bluetooth, scanning for nearby Bluetooth devices, and connecting to a Bluetooth device were referenced by Google's sample code, Bluetooth Chat [1]. The Bluetooth Chat essentially allows devices to create a Bluetooth socket to communicate between itself and another Bluetooth enabled device. Once the Bluetooth communication link was achieved, the application can send PIDs to and receive data strings from the Kiwi device.

Another feature for the application was to provide a visual representation of the data values in real time for the user. Because the the application received the MPH, RPM, engine load, coolant temperature, oil temperature, and voltage levels from the Kiwi device, six gauges were used (as shown below). It was decided during the designing stage that the tablet would only have one screen to display those values. This was because implementing multiple screens would create more of a distraction for the user (i.e. driver) than a single screen. Any distraction that would require the user to take his/her hands off the steering wheel can be dangerous.

(insert image of 6 gauges)

For this project, there were two key elements to implement the GUI, create the layout and create animations for the layout. There are many ways to make user interfaces as shown in Android's [API Guides]. In the OBD-II Android Monitor, the application GUI used a ImageView to create the background and the foundation of the GUI. The interface also used the RotateAnimation method in the provided in the SKD.

(will cont with GUI)

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

Include sub-sections that list out a problem and solution, such as:

Issues with Getting Data From the ELM327

A big challenge in this project was to parse the incoming data sent by the ELM327. It created a challenge for us due to the inconsistency of format in the data. Examples of inconsistencies would be random added spaces, newlines, null characters, or split messages. The typical operation of the ELM327 is to send a command byte followed by a parameter ID (PID) such as "01 00" followed by a carriage return ('\r') byte.

For example, if we were to send the message to obtain intake temperature, we would send ("01 0F" + '\r') to the ELM327. And get a typical response back of:

ELM327: 01 0F

ELM327: 41 0F 5C

ELM327:

ELM327: >

OR

ELM327: 01

ELM327: 0F 4

ELM327: 1 5C >

From the sample output above, the desired data that we need is the "5C" for this example. As you can see, the "5C" doesn't appear in a predictable manner which makes this a challenge to obtain the data we need. Note that these are only two samples of the possible message format.

To solve this problem, the use of Regular Expressions and built in Java String functions were used. The Java String functions that were utilized were trim(), split(), and matches(). The String.trim() allowed for us to remove any extra padded spaces in front and back of a string message received from the ELM327. String.split() allowed for us to split up the received string message into message bytes using space (" ") as a delimiter. It was desired to split up the received message since the data that follows the PID, is the data we want to retrieve. String.matches() functions by using Regular Expressions to check with selected data. If the data matches the corresponding regular expression then it is parsed, otherwise it is just simply ignored.

The regular expression pattern used to match for MPH, intake temperature, engine load, and coolant temperature was "INSERT REGEX EXPR HERE".

A drawback of using String.matches() and regular expressions is that it is a "hit or miss" scenario. This is due to the fact that the message received will either match or not match with the given regular expression. To address this, all message possibilities must be addressed and accounted for with regular expressions. This is essential to the performance of our application because the more matches obtained will give the user a real time response.

Conclusion

Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

Project Video

Upload a video of your project and post the link here.

Project Source Code

Send me your zipped source code and I will upload this to SourceForge and link it for you.

References

Acknowledgement

We would like the thank the following people for their contributions during this project:

• Preet Kang
• Michael Cox
• Christopher Tugangui
• Ryan Branche

References Used

List any references used in project.

• Setting up Android SDK
• OBD-II Parameter IDs
• PLX Kiwi Bluetooth Device Page
• Regular Expressions Wiki
• Regular Expressions Online Tester

Appendix

You can list the references you used.