Go Down

Topic: Arduino Car Diagnostic (Read 12124 times) previous topic - next topic


I was thinking the other day, it would be cool to develop an interface library for automotive diagnostics. I am talking about ISO9141, OBD II kind of thing.

I wanted to try this a while ago, but it seems that you have to purchase the spec to get access to the protocol etc etc.

If such a library was developed could it be done open source since the spec is not public. Or could it be done by distrubuting the library in binary form.

A shield might need to be developed as well to allow for connecting to to the OBD plug.

What do you guys think of this?


Would be awesome!

Not sure of the entire data that can be read from ODBII, but I know a cheap reader for it here is about $80.  That one just returns a code.

For about $180, the fancy one with a screen readout and access to reset codes and play with settings comes into play.  I'm sure its not a terrbile leap in hardware but most likely licensing fees.

That's a total guess, but I assume it's why the MPGuino people go straight to the injector instead of reading from the ODBII

Coding Badly

Jul 24, 2009, 09:27 am Last Edit: Jul 24, 2009, 09:27 am by bcook Reason: 1
it seems that you have to purchase the spec to get access to the protocol

74 Swiss Francs...


But, in my experience, ISO likes to break the information necessary to perform a task into a few specifications.  There's a chance that you'll need other documents.

If such a library was developed could it be done open source

I can't imagine why not but you'd certainly want to talk to a lawyer!

A shield might need to be developed as well to allow for connecting to to the OBD plug

Probably not.  Years ago my coworker bought a device that would connect to ODB on one side to RS-232 on the other side for about $250.  I expect such things are still available and are now considerably less expensive.

What do you guys think of this?

It brings back unhappy memories of ISO.  It cost me $200 for a 42 page document to get access to the three pages I actually needed.

There have been a few folks on the forum who could probably use an ODBdiunotm.

Did you have something specific in mind?


ODBdiunotm  :) cool name Coding Badly.

I've seen a few of those RS232 to OBD convertors and seen some schematics published to allow you to build your own. Its basically some level changing and optoisolation etc. Maybe using a shield to house this circuitry as well as a port to plug in a cable, or else a cable with the isolation and level shifting built in could be made for a reasonable price.

The biggest difficulty is going to be getting the spec. Anyone out there have the ISO9141-2 and related specs and willing to contribute, we could make this a community effort.

I saw a PIC based OBD chip in either EPE or Elektor way back, mayb putting that on a shield could work as well, but that kind of defeats the purpose though.


I would love to see this project come to fruition -- I've always been curious about tinkering in OBDII stuff, but not curious enough to spend $180.   ;)


It would be great, but we first have to find out what legal requirements need to be met since the protocols aren't open source and we would also need to have someone who has acces to the ISO spec documents...

Coding Badly

ODBdiuno cool name Coding Badly

Glad you like it.  Get an Arduino reading data from an ODB connector and the name is yours.  (The tm was a joke)

There may be a hitch in our git-along.  According to Wikipedia...


...the various U.S. car vendors have their own (dramatically different) method of using the ODB connector.  But also according to Wikipedia...

By 2008, all vehicles sold in the US will be required to implement CAN, thus eliminating the ambiguity of the existing five signalling protocols.

So, the hardware question is, should all potential vehicles be supported or only one's that support the CAN interface?

I have the ISO 15765 standard.  I believe it defines the "Network Layer" (I'll check later today).  Basically, it defines how to break long strings of data into multiple frames and vice-versa.  The standard includes pacing and flow-control.  There's also some stuff in there about addressing but I haven't look at it.


This company preprograms a micro of some nature (most likely PIC) that is used for OBD-II and on for $32.50


It requires level shifting logic.


If I ever do get something like this going I will use that name and be sure to give you cred for coming up with it.

I tossed the idea here into the community with the hope that maybe someone else with the time and resources can start a project like this up. Maybe one of the people who have actually implemented something like the PIC based controllers you can buy out there would be willing to port their efforts to the Arduino.

Coding Badly

If I ever do get something like this going I will use that name and be sure to give you cred for coming up with it

Excellent!  Thanks!

But shouldn't the name be OBDuino?  Looks like BRuTuS got us started with "ODB".  (Dang it, BRuTuS.  Proof reed befur ya send.)

It isn't much but I can help with CANBUS and the ISO 15765 standard.



Sounded right when I typed it...


Glad to see ya'll are interested in this. There has been a long ongoing project over at the ecomodder forums (same place that brought you mpguino) and it just so happens to be called obduino (sorry to bust your tm bubble) check it out here: http://code.google.com/p/opengauge/wiki/OBDuino and here:http://ecomodder.com/forum/showthread.php/obd-mpguino-gauge-2702.html Its made a lot of progress but as far as ive seen, its still alpha at best. Magister has posted on this forum before about it


Also check this out! :)


Cool glad to see that OBDuino exists  :) It would be nice if they could put up some documentation on the ISO spec ;)


If your looking for info on VPW obd2 check out this guys site!!


I have loaded his code in an atmega8 and 16's and it runs just fine.. I rewrote it for 16Mhz and also for the internal 8Mhz..

Both worked great tied serially to a computer and I was lazy and simply added another atmega8 next to it and shared the crystal.. tied the serial lines together and wrote some simple code to drive an LCD.. Worked great..

Also tied it to a modifed fonera router's serial port and I could access vehicle data form inside the house.. Great for checking GUI code.. I did find out the internal 8Mhz clock could glitch a few characters over the wireless fonera connection but not the 16Mhz??

Still working on my project when I have time but if the sun is shining, I am outside instead of hibernating inside.. lol  Plus one of the vehicles I wanted to communiate with uses CAN communication.. Whole different protocol..

Would love it if someone could look at his code and see about making it arduino compatible.. Code is small enough that  I don't need two atmega chips side by side but I need arduino for my basic coding abilities..

Go Up