Tinkering With ODB II And The CAN Bus

[Debrah] is taking his next project out to the garage. He built his own CAN bus reader using a dsPIC.

The nice thing about working with Control Area Network is that it’s a universal standard found on every modern production line automobile. And because of this, the chip you need in order to communicate using that protocol will cost just over a dollar. [Debraj] chose the MCP2551, which comes in several different 8-pin packages. There is even an application note tailored for use with the dsPIC33F family.

The project is running on both 5V and 3.3V rails. This complicates things just a bit, but a level converter makes sure that there’s no communications problems between the chips. A four line character LCD acts as the output during the tests (you can see this in the clip after the break) but he’s already got a second version which looks quite a bit better on the dashboard.

What else can be done with this hack? Well, we’ve seen a method used to read control buttons from the steering wheel before. It all depends on what data your vehicle is transmitting and one way to find that out is to build some hardware and start logging the packets.http://www.youtube.com/watch?v=NHou_66MbgQ

13 thoughts on “Tinkering With ODB II And The CAN Bus

  1. This only works on vehicles that have OBD-II over CAN. Older vehicles used other protocols to implement OBD-II. There is no security in these protocols, and you can spoof whatever data you’d like. It might not end well though.

    I wrote an article about CAN in automotive here, and I’m working on a CAN development board to make building CAN devices easy.

  2. There’s a typo in the title. It’s OBD, not an open document database :p

    But that’s an interesting project. With the OBD II port you’re not going to get too much information, though, as practically all cars only put out the diagnostic information that way. For Mercedes I’m even quite positive that the OBD interface is connected to an entirely separate CAN bus that’s completely separated from everything the car itself uses.

    The most interesting application would be listening to the interior CAN bus that usually controls everything not absolutely mission critical and is running on a slower speed than the engine bus.
    For the engine bus you should be damn sure to not mess anything up buswise by connecting an additional device and even then you will just be flooded by messages as all kinds of control units are going to be very busy senders. And unfortunately there’s nothing really standardized outside the OBD interface and you will have a hard time finding out what messages contain which data.

    The interior bus will not be as crowded but still feature a lot of the engine data and much more that’s usually not forwarded to the engine bus. Given the nature of CAN it’s practically also not a problem to just “spoof” messages (there’s nothing to really spoof, as CAN has no endpoint addressing) and hence control some things via a microcontroller. There’s even commercially available hardware to e.g. turn your car into a light organ once you unlock it. Essentially those devices only listen for the message for door unlock and then send messages to turn on and off all kinds of lights.

    There’s even a project which I don’t remember the name of that has been building a car PC optimized software package that transforms Windows XP into something halfway decently usable on small touch screens. And it features a quite sophisticated part solely for listening to and sending CAN messages. Listening is e.g. to control the car PC by steering wheel buttons thought for the radio and sending is e.g. to transmit text to be displayed in the dashboard for songs played, navigation directions etc.

    A car with a CAN bus and a proper adapter to listen to it and talk is a giant toy!

    1. Actually the standard/vanilla PIDs only contain diagnostic and basic info. Vendors have their own PIDs that reach into the control software and can modify almost anything. The mods are to parameters and tables – you cannot change the sw structure.
      IMO, looking at individual control codes will not buy anything except for simple devices. The more complex devices generate specific control codes based on other devices [like speed, temp, etc] and/or a current state in the control program.

  3. i’ve found most ODB II tends to be slow for updates especially since you poll for it. decoding the rest of the CAN bus data if you are able too is much better. RPM etc can be 500ms or worse off.

    lots of the obd ii pid’s are oem specific, but lots of people have decoded them or gotten hold of internal docs.

  4. Is the level translator strictly required? I know on the larger dsPICs, the ECAN module pins are also placed on 5V tolerant I/O pins that’ll accept up to 5.5V. Maybe the PDIP dsPIC lets you remap functions to its 5V tolerant pins.

    I think the input high threshold on the MCP2551 is like 2.6V or something, so a high from the dsPIC output would still be registered on the transceiver side.

  5. Can something like this be used to cap the speed reported through the OBD II port? I drive a car that has a device plugged into the OBD II port that compares the speed reported through the port to the speed limit in the area. I would like to put something inline between the device and the port that will only report a speed to greater than 70 MPH to the big brother device plugged into the car.

  6. Hi,

    Anyone here can help me understand if there is a common protocol to communicate with the ECU via the OBD II port to control or limit the top speed of the vehicle, like the speed limit posted or max safe speed allowed by state law!
    Anyone interested in ethical hacking to create a safety device?

    Tuned in & listening…


Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.