Ok, I'm an idiot. When I was reviewing the .ald file and looking over the CarBytes software I was wondering how the program was instructed to do something. Duh, you have to tell it.

Previously I was just hitting the ALDL button and waiting for something to happen. After I read your last post I relized I had to send a command, and voila, I recevied valid data. So your elegant circuit worked great. Now I don't have to build another one!

My only problem was that when I issued the command I only received one update from the ECM. I next tried the fields below/next to it for repeating a command. I put in 100 repeats. I did receive multiple responses, however the updates weren't very smooth and my laptop became verrrryyyy slooowwww. Maybe it is becuase it is an old laptop.

Anyway, now that I know how the CarBytes software works, now I can start playing around.

If anyone has any insight as to how to get the ecm to report back the data repeately I would appreciate it.

Great work enmityst. This is going to be fun.

Your .ald file worked perfectly by the way. The only bad info was a QDFM5 fault which I plan to investigate.

I am going to work on a .ald file for retrieving//displaying stored fault codes. I need to trouble shoot some traction control and "ride" problems.

Thanks again. I will post my results soon.

I'm still looking for some sort of OBD 1 cable.... Anyone care to make one for me? :?:

Great! Glad to hear it. The results you were getting previously must have been due to ALDL chatter, which would require a whole different set of definitions to decipher.

Hmm, that could be -- the computer I'm using is a 2.4GHz powerhouse, so I rarely experience (or even consider) speed limitations You might try setting the wait time back up to something higher (say, 200ms -- 5 requests per second isn't too shabby) and tweaking the other timing settings until you get valid data again.

Hmm.. it shouldn't have, at least not for everything For example:

Byte 13
'95 SE: cylinder air
'95 SSEi: engine load variable

Byte 30
'95 SE: unused
'95 SSEi: boost control duty cycle

Byte 34:
'95 SE: engine speed (RPM)
'95 SSEi: misc. status bits (see A221.DS for breakdown)

Byte 37:
'95 SE: Quad driver module status bits
'95 SSEi: Quad driver module status bits
However, the bits represented in byte 37 differ from my car to your car -- for example, the reason you're getting a QDM5 failure (bit 37.2 = 0) is because that bit is unused on your car, and will always be zero

Bit 38.6:
'95 SE: engine braking
'95 SSEi: unused

... etc.

So before you go looking for failures indicated while you're using my definitions file, you might want to go through the definitions one by one to make absolutely sure that they're correct for your car. Otherwise you'll probably end up wasting a lot of time hunting ghosts.

The stored fault codes are returned in the mode 1 message 1 response. The same issues I discussed earlier apply to that response too -- the M1M1 definitions file I sent you will most probably lead you on wild goose chases unless you correct it for the '95 SSEi.

-b

You don't really need a cable, per se -- You're only interested in 3 pins (+12V, ground, and data), and they're not next to each other, so it shouldn't be to difficult to make a custom connector out of whatever Radio Shack has around

I've been considering making one out of PCB pin headers. For those that aren't familiar, they look like this:



I was thinking about finding two that are long enough to span across the ALDL connector and have pins that are thick enough to hold firmly when pressed into the connector. Then I'd just pull out the pins I don't need, bolt or glue the two headers together or something, and solder the wires onto the pins. Maybe wrap it with heatshrink tubing or electrical tape or something.

I don't have much experience making custom connectors, though. I've done it before in a pinch, and it'* always worked alright, but it certainly doesn't look very cool.

I checked my catalog for Allied Electronics (one of the largest electronics distributors in my area) and they don't seem to carry any automotive connector bodies. The only place I could find them was on Delphi'* website -- though you might be able to pretend to be a retailer and request a sample connector body or even a cable from them for no charge.

As soon as I actually attempt to make a sturdy connector, I'll post details. The pin header thing is probably not the best way to go about it.

-b

Don't know why I didn't think of this earlier...

Instead of wasting a bunch of money on an OBD-I or OBD-II diagnostic connector body, or trying to hack together a connector that will stay put in the car'* connector, why not just do a little disassembly to get to the wires that lead into the car'* diagnostic assembly, splice into them, and run the three necessary wires to a readily available connector? Maybe a serial DB9 connector, a modular telephone socket, or whatever, *something* similarly cheap and easy.

I think this may be the way I'll go when I get some time to myself for a change. If or when that happens, I'll relay my progress.

-b

Okay, I have built the circuit but i didn't have a breadbasket so i just did it permanent soldered on a board. I think I may have run into a problem with the transistors now. They are NPN transistors from Radio Shack P/N 276-1617. It has the diagrams of transistors on the back but I think I may have hooked them up in reverse. The box came with 15 transistors and here is the problem: Some have offset bases but only the wire itself is bent - the top is straight across the transistor. The box shows 2 different configurations. One with the pins straight across the transistor (one side flat) and the other with the pins offset (again one side flat) Could they make them any more confusing? The emiiters and the collectors are opposite on each one!!!! How can I tell which ones are the emmiters and which ones are the collectors. I have checked them with a DVOM by putting the red wire on the base and then the black wire on the emitter to get .6 volts and the same for the collector. I didn't get any smoke from anything but I am not getting any communications, it sends but receives nothing. help...

The Radio Shack part number is useless, really -- they package a bunch of other manufacturer'* transistors. Look closely at the transistors themselves -- most of them will have a silkscreened part number on them somewhere, like 2N2222, ECG289A, 2N3904, etc. Once you've found that number, find the manufacturer'* datasheet for it -- usually you can just Google "2N2222 datasheet" or the like and it'll pop up. On that datasheet will be a diagram like the ones on the back of the Radio Shack package, but it will be specific to that transistor, and you'll know it'* correct. Repeat this process for the other transistor you plan on using in the circuit, or dig through the package to find another of the same part number.

Again, ignore the Radio Shack diagram completely. If you can't find the datasheets, let me know, I've got a reference manual around here somewhere with standard part datasheets in it.

So at least you know which pin is the base. In general with these style of transistors, if the base is in the middle and you're looking at the transistor'* flat side with the pins down, the pins are usually E B C. If the base is on the right, the pins are usually E C B. But check the datasheets just to be sure.

-b

ugh, i have built a complete new circuit here. Would you believe that Radio Shack does not carry resistors? I had to reuse the old ones (checked them first though). They sell all sorts of stuff except resistors or bread boxes. Maybe it is a good thing to be bought by circuit city.

Okay, built again and transistors are okay, everything is ok. I have a question about the diode here though. The diode that I have installed is a 1N914 Type Diode. It is small and glass or plastic.

The other question is the other ground. Is this necessary or is the one through the ALDL sufficient?

I hooked it up allright and ran the car to get data. I have the Serial to USB adapter and it is installed alright and set up on COM5 (no errors).

I set up the the comms on COM5, which it accepted. I then set all the parameters to the way you had them and ran the command $f4,$00,$01,$00 and started the ALDL.

The adapter had power, RX and TX leds and the TX flashed a few times and then the RX began flashing so it was receiving data. The problem is that I am not recieving the data into CarBytes receive: (nothing) but a whole lot of Checksum Errors (about every 5 or so).

I was wondering if it was the car but I tried the 94 Cavalier and the same thing. I am definitely sending data and receiving data (by the LEDs).

What is it I am looking for when I hit the ALDL with that command? What other parameters did you adjust and do I have to do anything with the Laptop Com port?

I have spent too much time to give up now...help.

Weird -- I've never been to a Radio Shack that didn't sell resistors. And I bought my breadboards there too. Damn Canadian Radio Shacks.

That should be fine. There isn't (or shouldn't be) a lot of current through that diode. Just make sure it'* installed with the correct polarity

You don't need to ground the circuit at the chassis at any point, if that'* what you're asking. You do need to make sure that the RS232 ground is connected to the ALDL ground though.

Can you take a screenshot of what CarBytes displays in the data window when you try this and post it or email it to me? Checksum errors imply that CarBytes *is* receiving data -- so now all we should have to do is troubleshoot the software.

Yeah, it sounds like you're sending and receiving data alright, at least as far as the hardware is concerned. When you send the $F4,$00,$01,$00 command to the ALDL, you're asking for the mode 1 message 0 response, which on my car is a 3-byte header, 67 bytes of running data, and a 1-byte checksum. In the ALDL window, it would look something like this (again, on my car):

Request: $F4 $57 $01 $00 $[checksum]
Reply: $F4 $99 $01 ... [67 bytes of data] ... $[checksum]

... and then it would repeat like this for every request you send. If the reply'* checksum byte and the calculated checksum don't match up, CarBytes will tell you there'* a checksum error, which usually means Something Bad happened to the data.

I described just about every CarBytes setting in a previous post, and aside from those, you shouldn't need to mess with anything else. Just make sure the comm settings are set to the correct serial port, 8192 bps, data bits 8, parity none (N), stop bits 1.

Nah, we'll get it -- no worries

-b

Okay, I set it up and ran it again for a screen shot. I put it at the spot that it actually received a single packet albiet a bad checksum.



If you need more or better screen shots I cans end them directly to you.

Thanks man! No worries