Announcement

Collapse
No announcement yet.

Any open source OBDII apps out there?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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!
    1998 Honda Civic LX
    In VERY early planning stages now
    ---------------------------------
    Awesome avatar from [email protected]

  • #2
    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.
    GE Cache Builder | [email protected] |Coolstuff :autospeed.com | bit-tech.net | Nitemax Ultra Pinouts

    Comment


    • #3
      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 [email protected]

      Comment


      • #4
        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.
        GE Cache Builder | [email protected] |Coolstuff :autospeed.com | bit-tech.net | Nitemax Ultra Pinouts

        Comment


        • #5
          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).

          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 [email protected]

          Comment


          • #6
            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 )
            GE Cache Builder | [email protected] |Coolstuff :autospeed.com | bit-tech.net | Nitemax Ultra Pinouts

            Comment


            • #7
              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 [email protected]

              Comment


              • #8
                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.
                GE Cache Builder | [email protected] |Coolstuff :autospeed.com | bit-tech.net | Nitemax Ultra Pinouts

                Comment


                • #9
                  A couple of other members have worked on this in various fashions check out these threads:
                  http://www.mp3car.com/vbulletin/showthread.php?t=32692
                  http://www.mp3car.com/vbulletin/showthread.php?t=42802
                  Avengerki
                  PC Install: 85%
                  Car PC: Revo-Sys X300 Double Din: 1.3GHz Pentium
                  Software install and setup: 35%
                  Entertainment Package: 85%

                  Comment


                  • #10
                    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

                    Comment

                    Working...
                    X