yeah,
the last page of the pdf sheets give examples of how these interfaces have to be modified.

Both of those look good(and in my price range ), thanks for the info.

mmmmmmmmm, Why can't I learn to read properly. I've already ordered a couple of those chips in the belief that it was for OBD-II.

Well, good think they're not that expensive. Anyone who want one??

TommyE

Your not the only one who can't read.

Hehe, nice to hear

TommyE

Ok. That's good to know. It did seem like these guys were asking for a simple cable that plugs into the OBD2 port and the other end plugs into the serial port on a computer. I dont think they're looking for a project....

Calvin

I too have ordered one hoping to hook it to an OBD-II vehicle.

However, the data sheets opens with:

"Since the 1996 model year, North American automobiles have been required to provide an OBD, or On Board Diagnostics, port for the connection of test equipment."

Now PLEASE correct me if I'm wrong here, but wasn't 1996 the year OBD-II became a requirement, not just OBD?

Does it even matter at the electrical interface layer?

The data sheet sounds like the right thing. Assuming it works it will make talking OBD much easier for our applications.

Cheers,

Rex.

Right. 1996+ is OBD2. You'll find some vehicles from 1995 equipped with OBD2 as well, as typically manufacturers produce the stated year car one year back.

Calvin

Hmm, interesting. Those ELM parts look an awful lot like the Microchip PIC16C505. I imagine that is all they are.. It is nice they do the handshaking for you. Look at www.opendiag.org for a simple level translator for RS232. They have info on the protocol and a Yahoo group too.

Speedy

What about OBD1 can we hook up to the empeg given the right software. By the way OBD1 is better.........its alot easier to work with the 94-95 acura integra GSRs are a bit faster than the 96-01 GSRs because of OBD1

I don't doubt these are PIC based, nothing wrong with that.

That's hardly "all they are" though. One hopes that ELM is putting some software on them!

I agree that it's not hard to handle this protocol directly but this ~US$10 part saves some work. In my case I won't have a hardware UART driving this thing so outputting both 5 and 104xx (?) baud is a headache I don't want. (This will be hooked up to a serial multiplexor -- another PIC -- not the empeg.)

We need a level converter with either design.

I guess you misunderstood what I meant. I meant it's not a special ASIC, and something that could be reproduced with some elbow grease. Not "Gee look a $1 PIC is the same thing as this $10 part, what a RIP!" Couldn't your PIC output pretty much any BPS you want, with the right xtal selection?

Speedy

OBD1 suffered from being non-standard. Every car had a different protocol that suited the make and model. Definitely, OBD1 is better for diagnostic, datalogging and tuning because it included important information specific to the engine of the specific car. For example, in a turbo car it might include knock detection and turbine speed. The drawback is for each make of car you need a different diagnostic box, and as you can imagine, the ordinary mechanic would not have been able to afford all the boxes unless they were specialized or a dealer.

OBD2 suffered from being rushed through design to solve this problem, and impose a strict standard for *all* cars... as a result a lot of specialty data channels like knock, etc, that are not consistent for all cars (NA cars..etc) are dropped. So it effectively is a lowest common denominator standard that works for all but is useless for many. Too bad the protocol committee didn't actually have more time or knowhow to design it correctly. But if there's any chance of a standard way to talk to the engine computer then it would have to be OBD2 as it is the most generic

Calvin

Yes, I misunderstood.

My mux is quite complicated. The hardware UART is off talking to the empeg. In software it has to emulate another two UARTs as well as take accelerometer measurements and some other house keeping, all running at once.

Multi-rate could be done but this code is already very complex. (Not that it's finished yet...) Not even sure I have the CPU power to pull all this off, it'll be tighter than I would like. Might end up with something other than a PIC.

There are other timing/latency issues that this ELM device should resolve in this case.

I have an ELM323 hooked up to my 2001 Mitsubishi Eclipse (OBD-II.) Works like a champ so far!

My other cars are Fords and my bike doesn't even have a computer so I haven't tested it on anything else yet.

There's some good info on the base PIDs on this page:

http://www.abcwc.net/accounts/quanta/obdinfo/pids1-2.html

Anyone know a good source of manufacturer specific PIDs?

Cheers,

Rex.