Anyone ever consider this? There are tons of programs out there that allow you to plug into your car via serial connection to your notebook or PDA. Then you can get feedback from the car.

That would be sweet. What kind of cars support this? Any links?

I think every car supports it... the connections are different for some of the manufactures and some cars give you more info than others..... but here is a link:http://www.obd-2.com/ The "Virtual Dashboard" could maybe work as a visual? These things are sweet. You can find out what the Check Engine light is on for (or at least what the trouble code is) and even reset it.

This link if for Windows, but it runs on Windows 3.1, so I assume the empeg wont have any trouble with a Linux version.

Another link: http://www.i-club.com/forums/showthread.php?s=&threadid=119661

This link if for Windows, but it runs on Windows 3.1, so I assume the empeg wont have any trouble with a Linux version.

With *what* Linux version? I don't see the source to the Windows version so I'm guessing a Linux version would have to be written from scratch? Are the specs open?

This sounds like a neat feature (and very wel-suited to the Empeg since it's in the car) but writing something from scratch sounds like a massive project...

I'm sorry, I meant a "theoretical" Linux version. The protocol for the car is open and may require some more digging.... let me see what I can find.

This would be very cool.

No, I was pretty sure you meant "theoretical" but I thought you might know of an open source project that could do it... The ideal project wouldn't have any graphics or user interface at all, just the calculations and data reading portions.. Something written in C or C++... Java would be bad. On a quick net search I saw a Java OBDII Sourceforge project but it had barely started and I don't know anyone who's going to want to port a Java program to C code that's efficient enough to run in the Empeg's tight memory and CPU requirements.

If we had to start from scratch I'd certainly think about contributing, but I'd need to see some very detailed specs.

Looks like the hardest part is to get a cheap ODB2-RS232 converter.

But this seems to be the solution:
http://www.elmelectronics.com/Products/Connect/Connect.htm
I'll order one and let you know how far I get.
(BTW: I drive a ford, so I'll use the PWM version.)

By looking at their sample app (see pdf) this shouldn't be to hard at all...

Cool link.

Just ordered two chips myself. (For GM that is, no Ford here )

TommyE

I'll be anxious to know how those things work out, especially the ones that interface with GM.

I'm a Ford guy as well so keep us posted.

Alex Peper sells one for cheap. Search for him on the internet.

Calvin

There is a Linux based OBD2 diagnostic command line project in the works.

http://sourceforge.net/projects/freediag/

Calvin

Doesn't look very active...

I have the freediag code, but haven't had time to get it going yet. The interface that it uses is available from: http://www.andywhittaker.com/
Another good interface is: http://www.multiplex-engineering.com/
I started writing the code for the empeg, and got as far as writing the screen routines to output the various available engine params, as text and bar graphs.
I have just received a new 60Gb empeg, which is going to stay in the house (and on the LAN) so I may get a chance to carry on with the project.

Philb.

Am I a complete dope? I can't find the freediag software anywhere on that Sourceforge project, nor anywhere on the web. That andywhittaker site just links to the Sourceforge project which doesn't seem to have anything on it.

I'm very interested in this stuff, and also glad to see another Empeg hacker showing up on the BBS. Don't be a stranger...

Honestly I can't figure out how to download the freediag code.

The ideal setup is to plug the empeg in the car, the serial port to an adapter to the OBD2 port. Then in the ethernet jack an 802.11b wireless adapter of some kind, and a laptop with another 802.11b wireless card. Then you can datalog using a larger amount of real estate to do real real!

Calvin

Have a look at past articles on ODB-2 in the Circuit Cellar website.

I've actually done some work (with a buddy) decoding ODB-1 data (from my '95 Camaro) in Linux and sending the data via serial to another VFD. I had hoped to port something to the Empeg early on, but never got around to it. see http://hud.cz28.com for a little more detail and some links.
There's a whole bunch of interesting things that could be done with the diagnostic data sent in the ODB-I stream. I'm not familiar with specifics on ODB-II, except to know that it's hard to find a freely available source on protocol.
I'll be happy to share what I have, if that helps the group.
Dan

are these for OBDII ? I only see references to OBD does it matter would they work for either ?

I don't think Richard has released the code yet. I got a very early version, but didn't get very far with it, due to lack of time.
Hopefully I'll get a chance to have a look at it again in a weeks time, when I get back from a holiday.

Phil.

ODB-II Project is underway man,

I'm on the case, currently with windows based software to perfect, but soon with some empeg stuff!

The windows platform is easier for me because I'm familiar with it, but the empeg stuff is just pure interest and challange to do what I haven't done before!

Expect a posting here, err, within, err, say a month!

Cheers,

M.

Eagerly awaiting! go go go go go!

Interfaces for non-N.American cars seem easy - this site claims it is just standard serial data but not at RS232 voltage levels.

http://www.andywhittaker.com/ecu/obdii_software.htm

It's a sad day,

I've been trying for ages to get some OBD-II software to work, with little success, seem to be talking OK but not anything meaningfull!

I downloaded some other sample software from the net and now it looks like the problem might be my motor might not be fully compliant!

If it doesn't support the standard codes then I have no way of testing the software! so I can't continue with the project!

And I was really getting into it as well!

Anyone waiting for a result, sorry guys,

Someone lend him your car!

Thanks for the thought!

I've been chatting to a guy that makes diags tools and he's gonna give me some tests/pointers to see if it's compatable or not....

.... so all may not yet be lost !!

I hope not, this we be the unlttimate feature to have in my mind.

I'd be willing to help out. My car (1998 Pontiac Grand Prix) is fully OBD-II compliant. Many gearheads at www.clubgp.com/forum interface the obd-ii with a program called Autotap on a laptop, or with some hardware called Scanmaster. I only know of one other empeg guy with a grand prix that might be more into this than me since I'm not much of a gearhead.

In reply to:

---

... and now it looks like the problem might be my motor might not be fully compliant!

---

Did you check the maker's web site and see if they had an update for it? Or is their idea of update "buy next year's model"?

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