Any open source OBDII apps out there?

Hi, I just got an OBD2 All-in-one, and have been having fun playing with it. However, I'm not happy with any of the free OBDII programs out there. I'm looking to write my own that does what I want (unless one exists, and I just don't know about it). My wishlist is:

-Support all ELM scanners
-Fully configurable as to which values are polled, and the frequency of polling
-Logs all data
-Create real-time gauges and graphs
-Be cross-platform, at least for Windows and Linux

So what I'm looking for is any open source (i.e. GPL) code out there for either Windows or Linux which can interface with the ELM320 ELM322 ELM323 ELM327 chips via serial ports of course. Also, I'm interested in any formulas / equations for computing miles per gallon (MPG), horsepower, and anything else people are interested in.

I'd like to have (mostly) portable code for the ELM interfacing backend, but of course there'd have to be some specialization for each OS. As for the GUI, I'd use something cross platform like wxWidgets, FLTK, or the like. The nice thing is, these already have chart and gauge widgets built in (or as plug ins).

If there's any other suggestions or info people can give me, I'll gladly take it. Thanks!

That would be nice. What would be great is if we could separate the process into three levels:

1) Hardware level access - code or a wrapper that reads/writes to a COM port in whatever method is appropriate for that specific platform. This code could be cross platform like javax.comm for Java, or it could be platform specific code for Win32/Linux/MacOS/etc. The wrapper would provide a cross-platform interface for the next level.
2) ELM interpreter - this would provide a set of function calls like GetRPMs(), GetSpeed(), etc that would in turn use API from level 1. This should definitely be cross-platform.
3) Front end - could be any number of things, from a simple text dump of DTCs, or a more detailed program that could log, graph, create gauges, show and clear codes, dump mode 6 data, etc. Again, this should be cross-platform. Java would be the easy choice.

Is anyone interested in this? I think it would be great to at least provide the first two levels, so we could have a common base to write whatever front end we want on it.

1998 Honda Civic LX
In VERY early planning stages now
---------------------------------
Awesome avatar from DannyWork@Flickr

That would be nice. What would be great is if we could separate the process into three levels:

1) Hardware level access - code or a wrapper that reads/writes to a COM port in whatever method is appropriate for that specific platform. This code could be cross platform like javax.comm for Java, or it could be platform specific code for Win32/Linux/MacOS/etc. The wrapper would provide a cross-platform interface for the next level.
2) ELM interpreter - this would provide a set of function calls like GetRPMs(), GetSpeed(), etc that would in turn use API from level 1. This should definitely be cross-platform.
3) Front end - could be any number of things, from a simple text dump of DTCs, or a more detailed program that could log, graph, create gauges, show and clear codes, dump mode 6 data, etc. Again, this should be cross-platform. Java would be the easy choice.

Is anyone interested in this? I think it would be great to at least provide the first two levels, so we could have a common base to write whatever front end we want on it.

For me, the comm access is done by Win32::SerialPort (windows) or the call compatible Device::SerialPort (nix) .

Perl is supported on 42 different platforms. Not going to get much more platform agnostic than that. Though Device::SerialPort would limit that a bit, but it works for Linux, Solaris and BSD. That's 99.9% of everybody though.

I think #2 is off though. There is no GetSpeed technically. Just PIDs, some standard, other which vary from car to car. An Elm intepreter library should mostly just be concerned with sending and parsing data and some convienence functions. (Like being smart enough to just send CR if you send the same command twice)
Something like GetSpeed belongs in the app itself.

The way I'm handling the numbers is that each PID has a verbal description associated with it which makes it easy to generate menus or even use a regex to search for PIDs in a CLI interface.

You can load your own data in (as not all cars have the same PIDs as mine).

Something you might be interested in is jElm, a jave ELM simulator for developing. There's another one but I can't recall it at the moment.

For me, the comm access is done by Win32::SerialPort (windows) or the call compatible Device::SerialPort (nix).

Good, plus it seems there's a Device::SerialPort implementation for Mac as well (since it's unix based now).

Originally Posted by shotgunefx

I think #2 is off though. There is no GetSpeed technically. Just PIDs, some standard, other which vary from car to car. An Elm intepreter library should mostly just be concerned with sending and parsing data and some convienence functions.

I agree mostly with this. There should be a general way to ask for a particular PID, like GetValue(mode,PID). However, many common numbers like RPM, speed, temperatures and the like need conversions done. Though they may be simple, why require every new front end programmer to look up which bytes mean what, and what conversion factors are needed. In addition to a general method of polling the system, I think methods like GetSpeed, GetRPM, etc. would be useful.

Originally Posted by shotgunefx

The way I'm handling the numbers is that each PID has a verbal description associated with it which makes it easy to generate menus or even use a regex to search for PIDs in a CLI interface.

This is good. I'd like to start a database of these PID and description combos. As you know, there is some info which are standard to all cars, like P0xxx DTC codes and the speed/temp/RPM stuff, though not all cars might support them. Then we could add to that database make/model particular codes, both P1xxx DTC codes and mode 6 data. Much of this information is readily available, it just needs to be put in a standard format.

Originally Posted by shotgunefx

Something you might be interested in is jElm, a jave ELM simulator for developing. There's another one but I can't recall it at the moment.

This should be useful. Thanks.

Would you mind sharing your code with me now? I'd love to get this base level working, from there it should be easy to throw a decent interface together for logging/charting purposes.

1998 Honda Civic LX
In VERY early planning stages now
---------------------------------
Awesome avatar from DannyWork@Flickr

Good, plus it seems there's a Device::SerialPort implementation for Mac as well (since it's unix based now).

I agree mostly with this. There should be a general way to ask for a particular PID, like GetValue(mode,PID). However, many common numbers like RPM, speed, temperatures and the like need conversions done. Though they may be simple, why require every new front end programmer to look up which bytes mean what, and what conversion factors are needed. In addition to a general method of polling the system, I think methods like GetSpeed, GetRPM, etc. would be useful.

This is good. I'd like to start a database of these PID and description combos. As you know, there is some info which are standard to all cars, like P0xxx DTC codes and the speed/temp/RPM stuff, though not all cars might support them. Then we could add to that database make/model particular codes, both P1xxx DTC codes and mode 6 data. Much of this information is readily available, it just needs to be put in a standard format.

This should be useful. Thanks.

Would you mind sharing your code with me now? I'd love to get this base level working, from there it should be easy to throw a decent interface together for logging/charting purposes.

Took OSX as a given (it's FreeBSD based right?)

You're right on the conversion. It does that, you specify the units to use when loading the module, some of the formulas being pulled directly from freediag

Just using a hash for all the PIDs makes it really easy to update. The formula entry is an index to a sub to format the results.

As far as saying GetRPM, it's trivial enough to make another module that wraps that up in English. So Device::OBDII::ELM32X::Easy uses Device::OBDII::ELM32X (The module name BTW)

Code:

sub GetRPM {
my $self = shift;
$self->sendcmd("010C");
}

As far as sharing the code, not at the moment. Got to figure out where I am with it. I haven't touched it in months and I don't remember what the problem I was working on when I last touched it. As soon as I can spend a few good days with it and iron it out a bit and write some documentation, I'll make it available and throw it up on CPAN (For the uninitiated, Comprehensive Perl Archive Network. The central Web repository for Perl modules and extensions)

IIRC, where I left off, there was a problem resetting the modes. Not the PID Modes, but the intepreter modes. It's easy enough to just throw the Elm into packed mode and certain defaults, but I want it to support all modes for completeness which complicates parsing (and handling communication reseting) slightly trickier.

Actually the biggest problem is working on it in my car (or was, it was winter )

As far as sharing the code, not at the moment. Got to figure out where I am with it. I haven't touched it in months and I don't remember what the problem I was working on when I last touched it. As soon as I can spend a few good days with it and iron it out a bit and write some documentation, I'll make it available and throw it up on CPAN (For the uninitiated, Comprehensive Perl Archive Network. The central Web repository for Perl modules and extensions)

Fair enough. I'm impatient though, so I'm going to try and start coding something up now. Do you plan to release the source? GPL/LGPL/BSD?

1998 Honda Civic LX
In VERY early planning stages now
---------------------------------
Awesome avatar from DannyWork@Flickr

What is it? A module I wrote to control my security VCR through the serial port. I actually wrote it for practice (haven't done much serial comm since the early 90s) before starting the ELM module. In many ways it's similar in structure.

I happened to be searching the mp3car forums and found this thread. The original posted requirements were:

-Support all ELM scanners
-Fully configurable as to which values are polled, and the frequency of polling
-Logs all data
-Create real-time gauges and graphs
-Be cross-platform, at least for Windows and Linux

Support all elm scanners: I think so, but I only have devices that claim to be elm327-compatible [ie, not previous elm32X versions]. I'm not doing anything complicated, so in theory there's no reason they shouldn't work.

Configurable values to poll: Currently done by editing a header file, but configurable without recompiles is on my TODO list