Connect an MCU to Your Car's OBD

Onboard diagnostic systems (OBDs) are found in almost every car these days, providing a very rich set of information about parameters like coolant temperature, RPM, and the like.

The information about all these parameters lets us define the state of the vehicle by diagnosing each and every aspect. Here's a guide to getting started with OBD development using your chosen MCU.

First, a quick overview. OBD-II is the protocol that works in most of our cars that date back from a decade ago until now. It's particularly widespread in cars made in Asia, where almost all makers support the protocol, but it is a global protocol and used in cars worldwide. You can find more on OBD here.

Connection to your car's OBD can occur in several ways. One is to use an OBD scan tool, which is readily available for around $30 to $50. Make sure the tool is OBD-II command-set compliant.

You can also use an MCU with a CAN interface. Some devices, like the ELM 327 (actually a PIC 18), come preprogrammed to extract information from the car's OBD-II ports. The STN1110 is also very popular and has the same functionality as the ELM chip.

More generic MCUs with a CAN connection will also work, although the CAN connection only handles the signaling interface. You will also need software to be able to decode the data. The simple LPC1768 mBed module will work (it has an in-built CAN hardware interface with an MCP2551 CAN transceiver).

If the MCU doesn't offer a CAN interface, you can use a CAN module such as Sparkfun's OBD UART with essentially any other device.

The physical connection to OBD uses a special 16-pin connector, which means you will probably want to use an adapter cable. Two common adapters available are OBD-to-DB9 and OBD-to-USB.

Software
You can extract Information from the OBD port only by making requests to the ECU (engine control unit). You request specific parameters by using the PID (Parameter ID) associated with the information of interest. You can request, for instance, the current RPM of the engine. The ECU then returns back a value like "010C" that your MCU or tool will need to translate into a human-readable/understandable form.

The PID "010C," for instance, has two parts. The first byte, "01," depicts the mode of operation. The second byte, "0C," is a hex that corresponds to the respective vehicle parameter.

Not all cars support all the possible PIDs. The PIDs I was able to make work with my 2003 Ford Ikon 1.6, for instance, included:

• 010A
• 0133-No Data
• 010C
• 0105
• 0103
• 0107
• 0105
• 010A
• 010E
• 010F
• 0111

Design example
This design example uses the LPC 1768 in the form of an mBed, which turns out to be a great tool for working with OBD communication. It already has an inbuilt CAN interface/controller, so only a CAN transceiver is needed to get a complete hardware system rolling. For that you can use a breakout board like this:

The developers of the breakout board above provide also a great library to work with mBed LPC1768. That library can be found here. You can look onto the library file ecu_reader.h to add or subtract PIDs depending on the vehicle you may be dealing with.

The following code is an example:

#include "mbed.h"
#include "ecu_reader.h"
#include "globals.h"
 
/*
Create ecu_reader objects
for different CAN bus speeds
*/
ecu_reader obdii1(CANSPEED_125);
ecu_reader obdii2(CANSPEED_250);
ecu_reader obdii3(CANSPEED_500);
 
int main() {
    char buffer[20];
    pc.printf("\n\rCAN-bus demo CANSPEED_500...\n\r");
 
    while (1) {
        if (obdii3.request(ENGINE_RPM, buffer) == 1)
            // Get engine rpm and display on USB port
            pc.printf("%s\n\r", buffer);
        else
            pc.printf("Engine Request failed\n\r");
if(obdii3.request(ENGINE_COOLANT_TEMP, buffer) == 1)
            pc.printf("%s\n\r", buffer);
        else
            pc.printf("Engine Coolant Temp failed\n\r");
 
        if(obdii3.request(VEHICLE_SPEED, buffer) == 1)
            pc.printf("%s\n\r", buffer);
        else
            pc.printf("Vehicle Speed failed\n\r");
 
        if(obdii3.request(THROTTLE,buffer) == 1)
            pc.printf("%s\n\r", buffer);
        else
            pc.printf("Throttle failed\n\r");
 
        if(obdii3.request(MAF_SENSOR,buffer) == 1)
            pc.printf("%s\n\r", buffer);
        else
            pc.printf("Maf sensor failed\n\r");

        wait(1);
    }

  }

That should be enough to get you started working with your vehicle's OBD. There are two things to keep in mind, however.

1) You may need to keep the vehicle ON to run the OBD. This means keeping the key in the on position, not necessarily starting the vehicle. Getting the engine started is needed to get certain parameters, however. RPM, for instance, is visible only when the engine is running.

2) If your system is connected to the OBD while you are cranking the starter, you may see some sharp voltage spikes. Some circuits, like the SparkFun's OBD-II UART, are able to cope up with these spikes. In my experience, although the voltage regulator IC heats up, the device hasn't shown any sort of malfunctioning. I don't know the reason for the spikes, though. The ECU runs directly off the battery so there shouldn't be spikes happening.

Have fun working with your automobile's OBD. Let me know if you have any questions.