How to begin OBD development?

Mork0075 · 06-29-2008, 07:06 AM

Hello there,
i'am planing to play a little bit with the OBD capabilities of modern cars. Before digging a bit deaper into the topic, in nead some guidance. So i it would be very nice, if someone could answer these questions

(1) Were to find structured information about getting data from OBD-Interface? Plugin in the Interface, connecting a computer via USB/Seriel and then - how to get the first data?

(2) Is there a car emulator for Windows PCs? So a program which acts like a car and sends the information to the usb or serial interface as a real car would do?

This would be a very helpful set of beginner instructions, to grab the first signal with a self developed OBD software.

Thank you so much for any guidance
Bye

PC_Cruiser · 06-29-2008, 08:08 PM

Quote:

(1) Were to find structured information about getting data from OBD-Interface? Plugin in the Interface, connecting a computer via USB/Seriel and then - how to get the first data?

I recently started a project to make a digital gauge cluster useing the OBD-II interface. The cable I bought (on ebay) connects via USB. However, it is nothing more than an emulated Serial port (COM port). So, to request and receive information from the car, I needed to communicate through the COM port. I'm not sure what language you plan on programming in, so your route may be a bit different than mine.

These are the very basics:

(1.) to start communications, send "ATZ" to the port. It will respond by echoing back "ATZ" and the version of the chip you are using (in my case ELM v1.2)

(2.) to turn off echoing of your commands send "AT0" <--Thats A-T-Zero. It should reply with "OK" or something similar

(3.) To get information for a specific item, you send it's PID. You can get a list of PIDs from here: http://en.wikipedia.org/wiki/Table_of_OBD-II_Codes

(4.) After you send the PID it will respond with the requested information in the form of HEX values. You need to convert the Hex values to decimal values and then use the information from the "Formula" column in the PID table to calclulate your ending value.

(5.) Request the next piece of information to continue the program.

Those are the basic steps. If you need some source code in VB.net 2005, let me know. Its not complete, but it should give you an idea of how to get the information.

Quote:

(2) Is there a car emulator for Windows PCs? So a program which acts like a car and sends the information to the usb or serial interface as a real car would do?

There used to be one called (I believe) Jelmulator. I haven't been able to find any working links to it though. If you find one, please let me know! It would be much easier than running out to my car to program!

Good luck with your project!

-Ray

PC_Cruiser · 07-03-2008, 12:31 AM

My last post is lost on some moderator's desk, so I'll try again:

Once you have an OBD-II USB adapter and install it on your machine, you can use your favorite programming language to talk to it. In my case, I use Visual Basic .Net 2005. The adapter talks to the computer via an emulated serial port (or COM) port. You will need to connect to the COM port and send first an initialization command (ATZ) then the PID for the data you want to recieve. You can get a list of PIDs from wikipedia. If you search for "ODB-II PIDs" in google, you will find the page. The table they supply also gives the formulas you will need to calculate the data once you recieve it back from the COM port (the data is send and recieved as HEX codes that need to be converted to decimal).

Hope that helps. If you need help, let me know and I'll do my best. I'm developing a digital gauge cluster based on the information from my OBD-II port. So far it seems to be working well.

Good Luck,

Ray

meddler · 07-03-2008, 12:33 AM

Quote: Originally Posted by PC_Cruiser

My last post is lost on some moderator's desk, so I'll try again:

It happens.

Mork0075 · 07-03-2008, 01:34 AM

Thank you, i would be very interested in some sample code.

But i think without a PC based testing environment, it's very hard to start. The first point is, that i have to develop in the car, the second that i can damage it

How develop the pros? There must be a testing environment?

NSFW · 07-03-2008, 03:35 AM

Write yourself a car emulator.

Start by choosing (or defining) an API that your software will use to send and receive bytes. Forget about the OBD2 interface for a moment - just think in terms of bytes sent and received.

At the same time you write your code to send and receive simple packets, also write code that acts like a car, receiving the same packets, parsing them, and responding with the appropriate packets. Test your code by running it against your fake car. When that works, then go test it in a real car. If you've done it right, it'll just work. Realistically though it probably wont work the first time, but if you have your software log all of the bytes that it sends and receives (I suggest writing to a text file, in hexadecimal), then you can study the logs to see what you're doing wrong. If the response from the car isn't what you expected, then revise your car emulator so that it behaves just like the car itself.

Once your test harness emulates the car correctly, you can make a lot of progress in the comfort of your home. Then you can just periodically test in the car to verify that things still work there too.

Do some research and see if your car speaks only OBD2, or if the manufacturer has a proprietary extension to OBD2 that gives better performance. Subaru uses SSM, Mitsubishi uses MUT, and so on. Then look for documentation on those protocols. Basically it's just a matter of creating the right series of bytes to send to the car, and parsing out the bytes that you receive in response. If you can find a document that describes those byte sequences, then you can write code to send and receive them.

Mork0075 · 07-03-2008, 04:41 AM

Thanks a lot for your reply

My concern is, that i'am doing something wrong, sending wrong bytes through the channel, which causes a damage. I've done some socket programming in Java, which is really close to what you've described (sending some bytes, waiting for the answer, adjusting the program). But writing your own test environement makes a lot of assumptions, which are perhaps wrong. So a pre build car emulator would give me the confidence, to not damage my car.

joeberni · 07-03-2008, 07:00 AM

Quote: Originally Posted by PC_Cruiser

.....

(5.) Request the next piece of information to continue the program.

Those are the basic steps. If you need some source code in VB.net 2005, let me know. Its not complete, but it should give you an idea of how to get the information.

Hi Ray - I'm just about to begin this part of my project as well and would love to see any vb.net code that you are willing to share.

Thank you so much!!!!!

JoeBerni

Sonicxtacy02 · 07-03-2008, 07:45 AM

Quote: Originally Posted by PC_Cruiser

I recently started a project to make a digital gauge cluster useing the OBD-II interface. The cable I bought (on ebay) connects via USB. However, it is nothing more than an emulated Serial port (COM port). So, to request and receive information from the car, I needed to communicate through the COM port. I'm not sure what language you plan on programming in, so your route may be a bit different than mine.

These are the very basics:

(1.) to start communications, send "ATZ" to the port. It will respond by echoing back "ATZ" and the version of the chip you are using (in my case ELM v1.2)

(2.) to turn off echoing of your commands send "AT0" <--Thats A-T-Zero. It should reply with "OK" or something similar

(3.) To get information for a specific item, you send it's PID. You can get a list of PIDs from here: http://en.wikipedia.org/wiki/Table_of_OBD-II_Codes

(4.) After you send the PID it will respond with the requested information in the form of HEX values. You need to convert the Hex values to decimal values and then use the information from the "Formula" column in the PID table to calclulate your ending value.

(5.) Request the next piece of information to continue the program.

Those are the basic steps. If you need some source code in VB.net 2005, let me know. Its not complete, but it should give you an idea of how to get the information.

There used to be one called (I believe) Jelmulator. I haven't been able to find any working links to it though. If you find one, please let me know! It would be much easier than running out to my car to program!

Good luck with your project!

-Ray

I've been looking into creating an rr extension plugin for OBD-II. If you could provide your sample code that would definitely help me get started.

NeonDev · 07-03-2008, 10:03 AM

Quote:

But i think without a PC based testing environment, it's very hard to start. The first point is, that i have to develop in the car, the second that i can damage it

So I am new to this as well... and I would like to know how it is possible to damage your car through OBD-II

Mork0075 · 07-03-2008, 10:21 AM

Quote:

So I am new to this as well... and I would like to know how it is possible to damage your car through OBD-II

Is this a sarcastic question?

In my unterstanding it is possible to send bytes to the controller which cause him to do a little bit more (perhaps reseting the service counter is one of the harmless actions), then sending back some simple status information. Isnt it this way?

NeonDev · 07-03-2008, 11:18 AM

I don't know thats why i'm asking... I just wouldn't think you could jack up your car with a diagnostic tool, but maybe you have a looser definition of harming your car...

What is the worst thing that you can do to your car over OBD-II? I'm not really worried about resetting flags or anything...

colin · 07-03-2008, 11:56 PM

Last time I checked, through standard OBD-II, the worst you can do is reset your MIL indicator -- which has it's side effects.

NSFW · 07-04-2008, 12:52 AM

Quote: Originally Posted by Mork0075

Thanks a lot for your reply

My concern is, that i'am doing something wrong, sending wrong bytes through the channel, which causes a damage. I've done some socket programming in Java, which is really close to what you've described (sending some bytes, waiting for the answer, adjusting the program). But writing your own test environement makes a lot of assumptions, which are perhaps wrong. So a pre build car emulator would give me the confidence, to not damage my car.

I wouldn't worry about damaging the car. If you send the wrong series of bytes, the car is most likely to just ignore the data. Especially if you stick to just the read side of the protocol - where you send packets that mean "what is the value in register X?" with a response from car like "register X contains value Y." If you just implement that stuff you're very unlikely to cause any trouble. When you're confident that you have that stuff working, and working well, then ask yourself if you're ready to tackle writes. If you are, you are. If you aren't, then find some more cool stuff to do with reads. There's plenty of opportunity there.

Frankly I wouldn't bother even trying to do writes. Mostly the software I use just reads data to display it or log it, and that's enough for me. I do use one piece of software to write (for tuning), and it makes me nervous every time I run it.

Mork0075 · 07-04-2008, 01:16 AM

Can please someone provide us with sample code?

Quote:

then ask yourself if you're ready to tackle writes.

How does a write look like? Reading from a register means also writing some bytes to the bus.