Interpreting various OBD-II protocols

Projects General Guidance
1

Hi everyone! So I'm just now learning a little about learning just a very little bit about OBD-II interpretation. I think I'm going to order an OBD-II simulator and pair it up with my OBD-II Arduino shield, and see what I can start learning. I want to be able to interpret sensor data and diagnostic trouble codes across a few different OBD-II ISO protocols that I have between several of my cars (GM, Ford, Chrysler).

My concern is that there are different pin-outs of the OBD-II connection on these different manufacturers. I see that the power and ground pins are consistent, but the pins used for the actual data vary between manufacturers. I would like to use the same Arduino device across all 3 protocols.

Does anyone know how difficult it will be to write an Arduino sketch that will automatically recognize the protocol when I plug the device into different cars (or when I simulate different protocols during my testing)?

If I had a list of PIDs (engine sensor values, specifically) such as manifold pressure, fuel pressure, RPM, throttle position, etc. that I want to automatically see the values for in my serial monitor when I plug the Arduino shield into multiple cars....... how difficult would that be?

Lastly, if I want to be able to read DTCs (diagnostic trouble codes) on any of these vehicles without having to adjust my program as I switch between vehicles, how difficult would that be?

It seems like I'm trying to accomplish much of what an aftermarket OBD-II wired scanner, or Bluetooth dongle and smartphone app can accomplish..... I'm just not sure of the logistics behind easily using it across multiple vehicles in regard to the programming-side of things, and there's out there on the Internet to learn about this.

If anyone is willing to share a little of their knowledge here I'd absolutely appreciate it greatly! Thanks so much!

-Andrew

2

Andrew, it does seem that you are trying to reproduce something that can be bought for a few pounds or dollars rather than setting your imagination free to design a new or improved device.

There are several tutorials out there on using an Arduino or other microcontroller based device to read OBD, and many extend to reading much more useful stuff like the CANbus, whereas OBD is constrained to engine and emissions data only. I suggest having a trawl through some of those, then develop a spec for what you want your machine to (reasonably) achieve. Armed with that you can start to set your mind to organising the programming before writing a bit of simple code and debugging it.

To ask 'is this possible/easy/simple?' could elicit all sorts of answers from the knowledgeable and skilled on here. Plenty will offer their help and guidance, but only after you've taken a few steps of your own.

I hope this helps.....GM

3

If you want a solution that will work for all cars with OBD II, your best bet is to use either CAN directly or use an ELM327 OBD scanner. Both approaches will work for all cars post 2008.

For using CAN: OBD2.h

For using an ELM327: ELMduino.h

4

Hi gentleman, thank you both so much for your responses..... and terribly sorry I'm just now getting back to this thread. Has been a very busy last couple of weeks!

Glorymill: Yeah some of what I'm looking to do can be down with an existing smartphone app, but there are quite a bit of other custom features I'm looking to create (going to pay someone to do this... I'm not skilled enough lol. But for instance, one of the good handful of things I'm looking to do is start data logging at the touch of a physical push-button, and simultaneously flash some LEDs using PWM to confirm that the device is actively data logging. Several of the other features will rely on me having to have my own custom PCB connected to the OBD-II port to pull the data at the fastest speed possible (versus doing it via Bluetooth). I will definitely follow your suggestion here in the coming days, and scour thru some various threads in here. I did try doing that before making this post, but may not have used some of the right keywords :slight_smile: Thank you for your input!!!!!!

Power_Broker: Thanks for your help as well!!! So I absolutely want to be able to do what I want on post-2008 cars, but I do also want to do the same for earlier OBD-II cars. I do want to have my own wired hardware, as several of the features I'm looking to incorporate will require my own hardware. I'll also have the functionality to do certain things via the smartphone, but unfortunately I won't be able to rely on on utilizing an existing Bluetooth OBD-II scanner for everything. Would you be able to tell me a little about what might be required for me to be able to read PID's and and DTC's on pre-2009 OBD-II cars (mainly Ford, GM, Chrysler), as well as 2009+ cars? Would the same piece of hardware be able to interpret the data on all years?

Thanks again gentlemen!

5

AGrayson84:
So I absolutely want to be able to do what I want on post-2008 cars, but I do also want to do the same for earlier OBD-II cars.

OBD-II started in 2008, so I'm not sure I understand what you mean by communicating over OBD-II on pre-2008 cars...

AGrayson84:
I'll also have the functionality to do certain things via the smartphone, but unfortunately I won't be able to rely on on utilizing an existing Bluetooth OBD-II scanner for everything.

I don't know what other hardware you would need, but if the scanner works well for the OBD-II portion of the project, you can still incorporate it into your own custom hardware like I did for my project here (custom PCB and mount). I'm not saying an OBD-II scanner is the best approach (it is in some cases), but don't discount it because you want to use other custom electronics/boards.

AGrayson84:
Would you be able to tell me a little about what might be required for me to be able to read PID's and and DTC's on pre-2009 OBD-II cars (mainly Ford, GM, Chrysler), as well as 2009+ cars? Would the same piece of hardware be able to interpret the data on all years?

I'm not well versed on pre-OBD-II PIDs, but OBD-II has a standard set of PIDs that are identical across all makes/models 2008 and later. Custom PIDs are generally available, but are specific to a make/model. Basically, if your car is 2008 or later, you can use the same hardware and software for any other 2008 or later car (as long as you aren't using custom PIDs).

6

Thanks for the help once again Power_Broker!!!

So regarding OBD-II, it actually started in 1996, but in 2008+ the CAN protocol was mandated to be included with OBD-II. I've noticed over the years that certain features of aftermarket products that are related to OBD-II are only available on 2008+ cars (perhaps due to the higher data-speed that CAN offers???), so I thought that's the difference you were referencing. So I guess I could use CAN for any vehicle I have that is 2008 or newer, but then begs the question as to what are the hardware and software differences for being able to interpret CAN as wells as the various, older OBD-II protocols. I may have to do a bit of digging to figure that out of course. I'm not at all familiar with this sort of thing, but I'm beginning to thing that the hardware won't really change between all of the options. My own PCB just needs to have wiring to each pin on my OBD-II pig-tail, and then based on which pin on the pigtail/custom PCB receives a signal when plugged into each car, the specific OBD-II protocol, or the CAN protocol, can be determined automatically by some basic programming.

Considering that something like a the ScanTool OBDLink MX and MX+ (protocol information can be found here: OBDLink MX+ Bluetooth OBD-II Scan Tool for iOS, Android, & Windows) can work on all '96+ OBD-II vehicles, in such a small form factor..... maybe things really are that simple. The OBDLink MX and MX+ only seem to specify CAN protocol support for Ford and GM though, which is weird, because my immediate understanding is that CAN is 100% universal, as opposed to their being 5 protocols for OBD-II. Anyhow, I know my OBDLink MX works on a '98 Ford Contour SVT that I have, and also works on a '16 Taurus SHO that I have (those are my oldest and newest model years that I own), so maybe for basic stuff like PID and DTC data it just relies on the OBD-II traffic versus CAN traffic? Seems like I'm going to have to probably venture off to some other online resources to find out those specific types of information.

I like your HUD project, pretty cool. I only skimmed thru the thread so far... I'll have to read thru it in full in the coming days. Seems like you used the CAN protocol (not OBD-II) for that? What do you think would need to be done to make it work if you plugged it into, say, and 2006 GM or something pre-CAN (so the HUD could work automatically between vehicles, with no user input)?

You certainly have valid points about just using something with the likes of an ELM-327 and maybe even Bluetooth ability. I just prefer to go all-out if I'm going to do this, and over-complicate things by re-inventing the wheel a little haha. Having 100% my own package would be so much more satisfying to me, even though I won't really be the one building it. Just a personal preference sort of thing.

Really appreciate your help so much!!

7

Interesting, I'll be honest, I'm not as familiar with the history of OBD. Learned something new today :slight_smile:

Note that the ELM327 can handle communication over multiple protocols, not just CAN:

  • Protocol - Description
  • 0 - Automatic
  • 1 - SAE J1850 PWM (41.6 kbaud)
  • 2 - SAE J1850 PWM (10.4 kbaud)
  • 4 - ISO 9141-2 (5 baud init)
  • 5 - ISO 14230-4 KWP (5 baud init)
  • 6 - ISO 14230-4 KWP (fast init)
  • 7 - ISO 15765-4 CAN (11 bit ID, 500 kbaud)
  • 8 - ISO 15765-4 CAN (29 bit ID, 500 kbaud)
  • 9 - ISO 15765-4 CAN (11 bit ID, 250 kbaud)
  • A - ISO 15765-4 CAN (29 bit ID, 250 kbaud)
  • B - User1 CAN (11* bit ID, 125* kbaud)
  • C - User2 CAN (11* bit ID, 50* kbaud)

AGrayson84:
I like your HUD project, pretty cool. I only skimmed thru the thread so far... I'll have to read thru it in full in the coming days. Seems like you used the CAN protocol (not OBD-II) for that?

Thanks! Initially I wanted to use CAN and did some testing with it, but after accidentally resetting my diagnostics computer a couple of times I decided it would be safer for my car to use an off-the-shelf device (ELM327).

AGrayson84:
What do you think would need to be done to make it work if you plugged it into, say, and 2006 GM or something pre-CAN (so the HUD could work automatically between vehicles, with no user input)?

It should work without modification for all OBD-II cars regardless of make and model.

AGrayson84:
Having 100% my own package would be so much more satisfying to me, even though I won't really be the one building it. Just a personal preference sort of thing.

I totally understand :slight_smile:

8

Power_Broker:
Note that the ELM327 can handle communication over multiple protocols, not just CAN:

Something even more interesting I just found about the ELM327, is that it is specified that it can automatically interpret the protocol. I guess that's where you were saying below that your HUD should work on any other OBD-II vehicle. I suppose that I assumed you wired an MCU to the specific pinout of your Chrysler's OBD-II port.

I had looked at the ELM327 before, but it seemed like the STN2120 was going to be a nice option, though I'll have to contact OBDSol to see if they can tell me if it automatically interprets the protocols.

Power_Broker:
Thanks! Initially I wanted to use CAN and did some testing with it, but after accidentally resetting my diagnostics computer a couple of times I decided it would be safer for my car to use an off-the-shelf device (ELM327).

It should work without modification for all OBD-II cars regardless of make and model.

Hahaha that sounds scary. When you say that you reset the diagnostics computer, due to mean you reset your ECM completely???

9

AGrayson84:
I had looked at the ELM327 before, but it seemed like the STN2120 was going to be a nice option, though I'll have to contact OBDSol to see if they can tell me if it automatically interprets the protocols.

That module looks really nice - I can't imagine it doesn't automatically interpret the protocols, but it's good to ask/research

AGrayson84:
Hahaha that sounds scary. When you say that you reset the diagnostics computer, due to mean you reset your ECM completely???

Something like that - yeah, it was scary. Especially when it's a Charger R/T...