There are, but all the ones I've seen are commercial -- CarBytes is strictly OBD-I. The same guy that originally wrote CarBytes now produces EFILive v4 (OBD-I) and v6 (OBD-II). Both are pretty pricey, even for a "DIY" license. But again, my research focused on OBD-I stuff, so there may well be a number of free programs for OBD-II -- I just haven't seen any.

-b

Just ran across a site dedicated to OBD-II homebrew scanning -- you can find it here:

http://www.scantool.net

Apparently a company called Elm Electronics makes specific chips for converting OBD-II data to serial. The circuitry necessary is a little more involved, though. They sell the finished product (all cables included) for what looks like $85 without an enclosure, $105 with an enclosure. The program featured on that website is free, as are a number of the programs they reference in their links section.

Have fun!

-b

Thats what I just bought and the Digimoto software too, only $89 total on ebay, they said it shipped today

Where the heck did you guys learn how to do all of this???

As for being easy, maby for people that have big brains

I'm an electrical engineer by training, and I grew up around computers and electronics. But honestly it'* no more difficult than working on a car -- you just gotta know how it works before you start taking it apart.

If you're interested in any of this but need help with something, we'd be glad to help.

-b

Oh, that explains alot and thank you for offering help to me but as of right now that is too tecnical

Does anyone have the CarBytes definition file.

I will take one for any car.

My car is a 1995 SSEi with a supercharger. Engine type 1

I have built the connector and will be testing it this weekend.

Thanks.

I emailed mine to you earlier this morning. Just in case you didn't get it, here'* a link to both of my definitions:

http://www.missouri.edu/~bcc5zb/bonneville/95SE.zip

M1M0 is "mode 1, message 0," which includes most parametric running data as well as active malfunction codes. M1M1 is "mode 1, message 1," which is mostly historical malfunction codes, etc.

-b

enmityst thanks for the file. I studied the file this weekend and it looks almost the same. I finished your circuit and connected it to my car. The "probe" software connected and did receive information back from the car. I am not sure what was returned, but, the only thing interesting was a bad checksum message. I fired off the probe app with default settings.

I next ran the CarBytes software with your file. I didn't get any errors, but the data wasn't correct. None of the parameters reported valid data. In fact only three of the first four parameters were changing and one or two further down the list. The parameters that were changing were definitley getting garbage since they were varying from - to + wildly.

Not sure whats going on. I tried your settings suggestiings for wait time for chatter but there was no change. I even varied the comm settings and didn't see any change.

If anyone has experienced this and found a solution I would really appreciate any hints or suggestions.

I will probably build another circuit, based on the MAX232, since I already have some of these chips.

No offense to your circuit, actaully it is pretty elegant from a simplicity standpoint. Yes I am an E.E. I want to use the 232 circuit to troubleshoot the problem.

Thanks and more to come.

I apologize to everyone for the novel that is to follow -- but I wanted to give a good description of what'* going on here for anyone that'* interested but doesn't have a strong background in communications, computers, electronics, etc. So forgive me if I'm repeating anything you already know.

They *are* almost the same -- but there are a few subtle differences. I think I made reference to that fact in the email I sent to you along with my definitions file. You can use the first 12 or so bytes (coolant temperature, MAF, TPS voltage, etc) to check to see if the circuit'* working, but after that the '95 SSEi and the '95 SE protocols start to diverge.

Bad checksum just implies that what you received isn't what the ECM sent. With an asynchronous serial signal using the same line to send and receive, there are a number of problems that could cause receive errors, most notably being noise and collisions. I'm using a 50' twisted pair telephone cable, and I have had *zero* errors since I got all my timing parameters tweaked correctly, so noise really shouldn't be an issue. I'd lean towards collisions. With Probe, you at least need to specify the "-e" option, to inform Probe that it *will* receive your request back as an echo. You might possibly need to tweak the timeout settings as well.

My (CarBytes) settings (and explanations) are as follows:

Wait (ms): 40

This is the time between requests -- too long and you risk collisions, as the ECM will start to chatter again a short time after it sends its response to your request. I think the default wait time was 100 or 200ms, and all I got was garbage.

Echoed: yes

This is important too -- the simplicity of this circuit comes from the fact that the send and receive lines are tied together through a transistor, and the computer'* UART *will* buffer and receive the data you send to the ECM. Check this box to make sure that echo is discarded and not viewed as part of the ECM'* response.

Make sure your baud rate is set at 8192, data bits 8, parity none (N), stop bits 1. All these are default parameters, I believe.

My input and output buffer sizes are 256 bytes each; again, these are default parameters. You shouldn't be getting buffer overruns, since the ECM replies are usually around 64 bytes.

Maximum time between bytes: 20ms

If the ECM hasn't sent a byte for 20ms, chances are Something Bad happened to the data train.

Total time elapsed multiplier: 0ms

Zero basically means "who cares?" So long as the ECM is talking, we don't particularly care how long it takes.

Total time elapsed: 100ms

To send about 70 bytes at 8192 bps, it should only take around 70ms -- so if after 100ms it'* not done, chances are something'* jacked up.

Chatter idle after: 50ms

I don't remember if this was a default setting or not. But if this setting is too long, CarBytes will never send a request; if it'* too short, you risk collisions.

You can't expect the data to be correct when the data train is FUBAR'd. Work on sending and receiving the data correctly before you worry about the data readouts. Here'* an example of what your serial dump should look like:



This is a replay, so it'* not quite the same, but take a quick look at all the trains received. Notice that they all start with $F4 $99 $01 -- this is a good indication that you're receiving the data correctly. (For anyone who doesn't know, the dollar sign in front represents a hexadecimal number -- just like 0x does in most programming languages). In addition, CarBytes displays an error count in the upper right hand corner of the data screen -- if you get even *one* error for every thousand requests, your settings are a little off. The first time I tried it, I think I may have gotten 9 errors out of 10 requests with the default settings. I set the wait time to 50ms, tweaked some other parameters, and got about 1 error for every 100 requests. Wait time down again to 40ms, and I haven't had an error since.

The first byte received from the ECM is the "from" byte -- $F4 is the ECM identifier, so that'* correct. The next byte is the train length byte -- this will always be $56 + the hex representation of how many data bytes there are. So in my case, the ECM is sending $99 - $56 = (decimal) 67 bytes. The '95 SEs send 67 bytes for their mode 1 responses, so that'* correct. The next byte is the mode response; since you're requesting a mode 1 response, the $01 informs you that yes, this is the data you're looking for. Everything that follows this third byte is the actual parametric data, except for the last byte, which is the message checksum. This will vary as the parameters in the data train vary, but if every byte is sent correctly, CarBytes won't give you a checksum error (obviously.) The checksum is simply the least significant 8 bits of the sum of the entire data train. The ECM calculates it, CarBytes calculates it, and if they match, the data train was probably received okay.

The definitions file I provided *only* serves to map this data to "friendly" names and quantities. If there'* a communications error, the definitions won't help.

Make sure that everything is as I described above. I had the same problems until I started tweaking the timeout settings. It might also help to send a mode 8 "stop chatter" request before you attempt to log data; to do so, just put

$F4, $00, $08

in the "command" box, and send it 1 time to the ECM. If the ECM receives this correctly, it should echo back with

$F4, $56, $08, $(checksum)

Then try and send your thousands of mode 1 message 0 requests:

$F4, $00, $01, $00

(Personally, I've never had to do this, as apparently my timeout settings happen to time requests perfectly on their own. But your mileage may vary.)

There'* another command that may work better than the mode 8 request; mode 0 is apparently the "ALDL request" command, and is simply

$F4, $00, $00

From what I understand, this informs the ECM that you wish to communicate with it, and I assume it'* supposed to quiet it down unless you ask it a question. I've never tried it though. The ECM should reply back with

$F4, $56, $00, $(checksum)

and then you should be free to try the mode 1 requests again.

Let us know how it works!

No offense taken -- I didn't design the circuit, I'm just a proponent of its use. If you've got MAX232s laying around, by all means go for it, you won't hurt my feelings. I just prefer simplicity and elegance when at all possible, and if I can get away with three identical resistors and two generic transistors instead of a dedicated integrated circuit, a handful of charge pump capacitors, and a soldering headache, I'll do so every time.

Anyone confused? Probably. Anyone who wants a further explanation of what the hell'* going on here, let me know!

-b