experimental cheap and relatively easy scantool - Page 3 - GM Forum - Buick, Cadillac, Chev, Olds, GMC & Pontiac chat


1992-1999 Series I L27 (1992-1994 SE,SLE, SSE) & Series II L36 (1995-1999 SE, SSE, SLE) and common problems for the Series I and II L67 (all supercharged models 92-99) Including Olds 88's, Olds LSS's and Buick Lesabres Please use General Chat for non-mechanical issues, and Performance and Brainstorming for improvements.

Reply
 
 
 
Thread Tools Search this Thread
Old 03-25-2004, 10:58 PM   #21
Senior Member
Posts like a Supercharger
Thread Starter
 
Join Date: Mar 2004
Location: Columbia, MO
Posts: 175
Thanks: 0
Thanked 0 Times in 0 Posts
enmityst is on a distinguished road
Default

Quote:
Originally Posted by Custom88
are there any cables/programs that work with the OBDII systems? Are there computer-based scanners that we can use like what you are? I'd be interested in this if I can buy a cable for relatively cheap, and use that free program.
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
enmityst is offline   Reply With Quote
Old 03-26-2004, 12:41 AM   #22
Senior Member
Posts like a Supercharger
Thread Starter
 
Join Date: Mar 2004
Location: Columbia, MO
Posts: 175
Thanks: 0
Thanked 0 Times in 0 Posts
enmityst is on a distinguished road
Default

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
enmityst is offline   Reply With Quote
Old 03-26-2004, 01:46 AM   #23
Senior Member
True Car Nut
 
Join Date: Jun 2003
Location: Purgatory
Posts: 6,313
Thanks: 0
Thanked 0 Times in 0 Posts
PontiacDad is on a distinguished road
Default

Quote:
Originally Posted by enmityst
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
PontiacDad is offline   Reply With Quote
Old 03-26-2004, 10:25 AM   #24
Senior Member
Posts like a 4 Banger
 
Join Date: Feb 2004
Location: Morris Mn.
Posts: 143
Thanks: 0
Thanked 0 Times in 0 Posts
Sigma is on a distinguished road
Default

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

As for being easy, maby for people that have big brains
Sigma is offline   Reply With Quote
Old 03-26-2004, 01:45 PM   #25
Senior Member
Posts like a Supercharger
Thread Starter
 
Join Date: Mar 2004
Location: Columbia, MO
Posts: 175
Thanks: 0
Thanked 0 Times in 0 Posts
enmityst is on a distinguished road
Default

Quote:
Originally Posted by Sigma
Where the heck did you guys learn how to do all of this???
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
enmityst is offline   Reply With Quote
Old 03-26-2004, 02:34 PM   #26
Senior Member
Posts like a 4 Banger
 
Join Date: Feb 2004
Location: Morris Mn.
Posts: 143
Thanks: 0
Thanked 0 Times in 0 Posts
Sigma is on a distinguished road
Default

Oh, that explains alot and thank you for offering help to me but as of right now that is too tecnical
Sigma is offline   Reply With Quote
Old 03-26-2004, 02:36 PM   #27
Member
Posts like a V-Tak
 
Join Date: Oct 2003
Location: Dallas
Posts: 32
Thanks: 0
Thanked 0 Times in 0 Posts
rnbraud is on a distinguished road
Default

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.
rnbraud is offline   Reply With Quote
Old 03-26-2004, 03:02 PM   #28
Senior Member
Posts like a Supercharger
Thread Starter
 
Join Date: Mar 2004
Location: Columbia, MO
Posts: 175
Thanks: 0
Thanked 0 Times in 0 Posts
enmityst is on a distinguished road
Default

Quote:
Originally Posted by rnbraud
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 is offline   Reply With Quote
Old 03-29-2004, 12:30 PM   #29
Member
Posts like a V-Tak
 
Join Date: Oct 2003
Location: Dallas
Posts: 32
Thanks: 0
Thanked 0 Times in 0 Posts
rnbraud is on a distinguished road
Default

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.
rnbraud is offline   Reply With Quote
Old 03-29-2004, 02:18 PM   #30
Senior Member
Posts like a Supercharger
Thread Starter
 
Join Date: Mar 2004
Location: Columbia, MO
Posts: 175
Thanks: 0
Thanked 0 Times in 0 Posts
enmityst is on a distinguished road
Default

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.

Quote:
Originally Posted by rnbraud
enmityst thanks for the file. I studied the file this weekend and it looks almost the same.
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.

Quote:
Originally Posted by rnbraud
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.
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.

Quote:
Originally Posted by rnbraud
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.
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.

Quote:
Originally Posted by rnbraud
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.
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.

Quote:
Originally Posted by rnbraud
I will probably build another circuit, based on the MAX232, since I already have some of these chips.
Let us know how it works!

Quote:
Originally Posted by rnbraud
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.
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
enmityst is offline   Reply With Quote
 
 
Reply

Related Topics
Thread Thread Starter Forum Replies Last Post
Cheap and easy knock reduction SPEEEEEED Performance, Brainstorming & Tuning 11 11-19-2007 07:47 PM
Cheap and easy Intermediate shaft solution? dhaag 2000-2005 20 01-25-2007 09:25 AM
expensive and relatively easy scantool Spiral 1992-1999 4 04-09-2004 11:55 AM
Scantool Ownership Update--Reply only if you have a Scantool 95BonnevilleSESC Lounge 14 01-29-2004 09:18 AM
Relatively new member Edmund944 Your Ride: GM Pictures & Videos 3 03-15-2003 04:11 AM


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off



All times are GMT -4. The time now is 10:12 PM.


We are a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for us to earn fees by linking to Amazon.com and affiliated sites.