Results 1 to 10 of 10

Thread: Any open source OBDII apps out there?

  1. #1
    Newbie maeliosa's Avatar
    Join Date
    Aug 2004
    Location
    US
    Posts
    20

    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!

  2. #2
    Raw Wave shotgunefx's Avatar
    Join Date
    Apr 2005
    Location
    Boston, MA
    Posts
    1,800
    Try looking at freediag.

    Myself, I'm working on a Perl ->ELM module. I've put it on hold for a bit while I tend to other things. I do plan on releasing it, and perl is pretty much cross platform.

    I don't know if I'll add a front end as it's for my own which is pretty specific, but it would be easy enough to write one with the module.

  3. #3
    Newbie maeliosa's Avatar
    Join Date
    Aug 2004
    Location
    US
    Posts
    20
    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

  4. #4
    Raw Wave shotgunefx's Avatar
    Join Date
    Apr 2005
    Location
    Boston, MA
    Posts
    1,800
    Quote Originally Posted by maeliosa
    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.

  5. #5
    Newbie maeliosa's Avatar
    Join Date
    Aug 2004
    Location
    US
    Posts
    20
    Quote Originally Posted by shotgunefx
    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).

    Quote 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.

    Quote 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.

    Quote 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

  6. #6
    Raw Wave shotgunefx's Avatar
    Join Date
    Apr 2005
    Location
    Boston, MA
    Posts
    1,800
    Quote Originally Posted by maeliosa
    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

    Here's an example of the %PID structure
    Code:
    '0109' => {
                            cmd => '0109',
                            formula => 'long_term_fuel_trim_formula',
                            desc => '"Long Term Fuel Trim (Bank 2):"',
                            rcv => 2 # bytes to receive
                          },
    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 )

  7. #7
    Newbie maeliosa's Avatar
    Join Date
    Aug 2004
    Location
    US
    Posts
    20
    Quote Originally Posted by shotgunefx
    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

  8. #8
    Raw Wave shotgunefx's Avatar
    Join Date
    Apr 2005
    Location
    Boston, MA
    Posts
    1,800
    Quote Originally Posted by maeliosa
    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?
    Yes. When I talk about releasing it, I'm talking about the source.

    FYI, with Perl, you pretty much can't not release the source. You could make it more difficult, but anyone with a decent knowledge of how it works, can get it.

    As far as liscence, it will be either Artistic, GPL or both.

    Not sure what you're planning on using, but if it's Perl, and you can't wait, might find this interesting.

    Device::VCR::SSP::Serial

    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.

    Regardless, shows you how to setup the port, send and read data, etc.

  9. #9
    Constant Bitrate avengerki's Avatar
    Join Date
    Mar 2006
    Location
    Oregon
    Posts
    160
    A couple of other members have worked on this in various fashions check out these threads:
    OBDII / Elm MPG meter. Almost working but not quite!
    Yet Another OBDII VB6 Class
    Avengerki
    PC Install: 85%
    Car PC: Revo-Sys X300 Double Din: 1.3GHz Pentium
    Software install and setup: 35%
    Entertainment Package: 85%

  10. #10
    SuperMod - OBDII GPS Logger forum
    Auto Apps:loading...

    Join Date
    Mar 2009
    Location
    Los Angeles
    Posts
    924
    Holy thread-back-from-the-dead-three-years-later, batman!

    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
    This is a pretty good match for my new project, OBD GPS Logger

    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

    Configurable polling frequency: yes.

    Logs all data: kinda the point.

    Real-time gauges and graphs: gauges yes, graphs no. But does offline graphs, I guess realtime ones wouldn't be hard to add. Hrm. :adds to TODO list:

    Cross-platform, at least for windows and linux: Linux, yes. OSX, yes. Anything POSIX, yes. Windows, through cygwin [in theory]. Windows "real" version... maybe in future.

    I have a specific sub-forum on mp3car.com for the software, here.

    Gary (-;
    OBDGPSLogger, for logging OBDII and/or GPS data
    OBDSim, an OBDII/ELM327 software simulator
    mp3car forums: obdgpslogger, obdsim

Similar Threads

  1. RB curiousity Front end Open Source?
    By sdashiki in forum MacCar
    Replies: 13
    Last Post: 06-25-2005, 11:31 AM
  2. GPS:MM shutdown RR when switch skin
    By MatrixPC in forum RR Bug Tracker
    Replies: 5
    Last Post: 05-12-2005, 12:07 PM
  3. external apps
    By reda4 in forum MediaCar
    Replies: 6
    Last Post: 11-20-2003, 04:46 AM
  4. still open source?
    By SilverJester in forum ME Archive
    Replies: 3
    Last Post: 03-03-2003, 10:52 PM
  5. Replies: 162
    Last Post: 11-18-2002, 01:15 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •