Results 1 to 2 of 2

Thread: ObdgpsLogger2 proposal

  1. #1
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    16.40618, 120.61106

    ObdgpsLogger2 proposal

    I've discussed this with Chunky_Ks a lot via IRC, but I think it'd be good to make a more formal post about the ideas that would constitute a new obdgpslogger.

    Current ObdGpsLogger Constraints:

    Currently, you can get obdgpslogger to read obd codes from a compliant vehicle and log stuff. You can also utilize obdsim's plugin architecture to read values from a non-compliant vechicle and route the values into compliance. This gives obdgpslogger a lot of capabilities, but it still doesn't cover reading or writing mfg-specific codes that logger currently knows nothing about. A rewrite would be necessary to give logger this functionality.

    A New OBDd

    What would be nice is a 3 part application. First, libobd, which handles communication with the device. Secondly, a pluggable daemon for which a plugin could be written to read and write 3rd party codes through a nice interface. Third would be an interface library for 3rd party apps. This library would provide convenience methods for apps that want to display data coming from the daemon similarly to how libgps works with gpsd. The daemon would communicate with 3rd party apps via a socket based TCP/UDP communication protocol *at least*. Of course, the latter TCP/UDP communication layer could just be another plugin.

    In this scenerio, logging would also just be another plugin and obdgpslogger would become the de-facto standard way of communicating with the obd port on *nix platforms (similarly to gpsd).

    What do you think?
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

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

    Join Date
    Mar 2009
    Los Angeles
    I like the idea of splitting out obd comms into a separate library, I've been thinking about that for a while. For that matter, it went into the TODO at revision 100; right now, we're on revision 345.

    The fundamental different in architecture between gps and obd is that gps can essentially just be listened to; you listen to the stream and pick out the bits you want; if you're sufficiently determined, you can interpolate to get almost arbitrary data rates. OBD is more challenge-request, and highly rate-limited.

    My initial inclination is to separate the OBD communication into a separate library, and change logger to use that [should be simple, since the API probably won't change much]. As to a pluggable daemon, I don't know how well it'll actually work. But once I've split the obd comms into a separate library, the described daemon would be relatively easy if you can figure out how to *actually* get everything working.

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

Similar Threads

  1. My Double DIN Motorized LCD Enclosure Proposal
    By milkhead in forum LCD/Display
    Replies: 123
    Last Post: 07-31-2006, 07:06 PM
  2. Reverse engineering cam file...Proposal for $$
    By RoyN in forum Software & Software Development
    Replies: 8
    Last Post: 10-20-2005, 02:54 PM
  3. My Proposal
    By lgbr in forum Off Topic
    Replies: 98
    Last Post: 08-17-2005, 01:25 AM
  4. Proposal: Address Book Sync
    By mmendis in forum Software & Software Development
    Replies: 6
    Last Post: 02-05-2004, 07:20 AM
  5. Replies: 1
    Last Post: 10-07-2003, 02:53 PM


Posting Permissions

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