The manufacturer doesn't state compliance or not but several groups and websites claim that 1995 onwards models are compatable.

Mine is a 1999 model so it should be ok, mitsubishi do make references to the OBD-II diagnostics but maybe there is a slight difference with timing or somthing!

Will have to keep the faith and do some more homework!!!

Is there anyone here that works for Dodge? (The Dodge Stealth is the sister car to the 3000GT).... I have sources at Ford and GM, but not Dodge...

If your car is 1996 and onward it has to be 100% compliant. What this means varies slightly from manufacturer to manufacturer. But for the most part, you can plug in any OBD2 hardware box into the port and it would be fine. What I find non-compliant and buggy is often the free OBD2 implementations on the web. Shoot, even the ones that you PAY for suck ass.

Calvin

It's 1999 model, but still having problems with the software at the moment, nevermind, as the saying goes .... if at first you don't succeed ..... try try again ;-)

thats the spirt, and if ur car isnt 100% compatable, you should make it 100% compatable.

I'm not directly involved with scan tools but I do attend yearly trade group meeting with the Detroit automakers for preview service info on next year's models. The scan tool guys usually have a stack of paper 5" thick for each manufacturer documenting this and that trouble code, flag, etcetera. It's an immense amount of specification that changes yearly. I'll ask around this June to see if I can find anyone interested in lending a hand to you guys.

-Zeke

I have been stealth following your project and maybe starting with something slightly easier than the full OBD route would help to get things rolling. I have expressed this as a wishlist item before but I have no programming skills to be able to do it myself.


Most modern cars will have a electronic speedo sense that goes into the ECU which will give 4 or 8 pulses per wheel revolution. Link this into the empeg serial port (shouldn't take much) and you can then measure distance using the empeg by simply counting pulses.

The empeg has a RTC so you then have the ability to measure acceleration (0-60 times), speed (current,avg,top), deceleration, write journey logs etc,etc.

The hardware/compatibility part of this should present a much smaller hurdle than OBD and the resultant functionality could be quite useful to a much wider audience.

Whay think ye?

OBD route will be much better once the basics are in place because it's just a matter of processing collected data!

I've got the RS-232 to ISO interface adaptor, so it's not even a hard ware issue involved, it's just software!

I'd need completely new hardware to interface direct to components like the speedo, and this hardware would be different for each car, the OBD standard should be more generic!

The latest trials were last night, but it looks like it's a problem understanding the car system more than anything else at this stage!



Thanks for your comments though!

This was my whole point, you seem to be having problem which you say are related to software but instead seem to be car/interface dependant.

If you connect the 12V pulses from the ECU to the DTR line on the empeg's serial port, the hardware is finished. Then you just count pulses on DTR. I agree that OBD would be more flexible but I disagree that it could possibly be any easier.

The only car specific part would be finding the correct lead into the ECU. PIN A1 (Green/Yellow) on a WRX by the way.

For my WRX, I'm looking at the Delta Dash product....

I hope you mean CTS or DCD (I think those are the 2 connected signals)... DTR is an OUTPUT from the empeg!

Hugo

Hmmm.. Thanks

ISTR that the in car DB9 is not fully wired in the sled, do we have DCD or CTS?

It's fairly wired, but the wires are shared; ISTR it's DCD and CTS, but DCD is used for mobile phone mute on the harness and CTS is used for lights-on detect.

...so you only get a line if you're not already using it for something else.

Hugo

Ahh, So If I use both the mobile mute and the lights sense (and I do) then I am stuffed as far as another input is concerned?

Sorry, but you are... the inputs are shared mostly because of a lack of pins on the docking connector - we couldn't find anything half-decent with more than 24 ways...

Hugo

Fair enough. Thanks for the info. I think that my next step is to get some kind of counter IC which can output its total via RS232.

So does this mean that I can wire up a phone mute on the serialport on the MKI as well??

TommyE

Things might be moving again, I've been speaking to a few guys who know about this stuff and we are well on the way to a standard API!

Version 1 will be windows active-x component, with front end software!

Before you shout that it isn't compatable with empeg - that comes in version two when the software is proven reliable, stable, and above all else actually usefull!

As usual, don't expect quick results, could be a few months before you see empeg code postings here ..... but they are on the way!

Cool! Way to go!

Hi.

Mind you, but backporting any source from an ActiveX component to a portable library is a pain-in-the-ass thing to do. A more useful approach would be to have three classes:

• a class providing serial port access
• a class providing the actual OBD-II interface
• a wrapper class around these that provides the ActiveX component
  

That way, you will not have to actually transform an ActiveX component into something portable, but rather wrap something portable into an ActiveX component. If you want to port it, simply dump the wrapper class, port the serial port class and write a new wrapper for the new target architecture.

If you want to go a pretty portable way (though not for the empeg), you might want to use the Qt library (www.trolltech.com).
If you would like someone to check your code for portability to Unix/Linux, I can lend a hand. But don't expect me to invest much time before end of July. I have to finish my diploma thesis by July, 21st and also am still working on two empeg projects: extended upgrade image (boot from /dev/hda2) for the empeg and porting the GD library. The latter turned out to be far more complex than I thought.

cu,
sven

A standard API would be a nice idea. Someone else (I don't have the time right now though) could start work on displays, alarms, historical graphs, statistics and 2-D plots.

Some sort of core code that just logs all data to disk and has a plugin architechture for events would be a sweet design. Then other people can write visual and audio output formats.... then just a few scripts or config files and you could customize what you want your empeg to do for any given OBD event.

I haven't done much programming for the empeg, but I'm envisioning writing a config like this:

event oil.low {
player:pause();
display:show(lowoil.raw);
player:playfile(lowoil.mp3);
player:resume();
}

event user.menu1 {
# Triggered by hiject menu item
# Call the grapher plugin to show a graph for 5s.
graph:show(rpm, 5);
}

Am I dreaming or is something like that within the realm of possibility?

Attention OBD-II car people, the November edition of Elektor electronics magazine has an OBD-II to serial convertor. But it appears to do much more than just level shift. Apparently you can run through a terminal emulator and it interprets all the data and provides it as simple ASCII stuff. Shouldn't be too difficult to run on the empeg then. This is, until someone finds a good way of stopping the player hogging the serial port. That's really hindering a lot of data logging projects IMHO (GPS addons anyone?)

Hmmm, doesn't the "-s-" flag to the player app stop it from grabbing the serial port? Requires a modified init though.

/Michael

Automakers to give diagnostic codes to repair shops

http://www.cnn.com/2002/TECH/ptech/09/27/diagnosing.car.repairs.ap/index.html
"WASHINGTON (AP) -- Automakers agreed Thursday to give independent repair shops their closely guarded codes used to diagnose troubles with today's high-tech vehicles so the shops can make the same repairs as franchise dealerships. "

"Under the agreement signed by the Automotive Service Association, the Alliance of Automobile Manufacturers and the Association of International Automobile Manufacturers, the automakers agree to make the service information available on the Internet by Aug. 31 at a "reasonable price." It will be available to all professional mechanics as well as amateurs working out of their garage at home, said Charlie Territo, spokesman for the Alliance of Automobile Manufacturers."

A few source documents further that article courtesy of a trade group my company belongs to.

-Zeke

The second of them.

-Zeke

Ran across this site, didn't know if it would be of interest to anyone.

http://pages.infinit.net/jsenk/obd_Perl.htm

Anything new on this thread? I got an obd2-RS232 converter and would just need the software for the empeg...

I wouldn't even want to log anything, just visualize some data whenever I want/need to.

Also, check out this newer thread:
http://empeg.comms.net/php/showflat.php?Cat=&Board=hackers_prog&Number=163729&page=&view=&sb=&o=&fpart=all&vc=1