No announcement yet.

New Release 0.5

  • Filter
  • Time
  • Show
Clear All
new posts

  • New Release 0.5

    Hola all,

    I've been meaning to do a release for a while now, but kept wanting to add little sniglets to the system. In an attempt to make me get myself organised, here's a 0.5 release. The following is ripped directly from the changelog:

    Version 0.5 (released 2009-05-22)
    Move common obdinfo into its own library
    add to obdinfo so programs can know units, max, min, etc
    obdgpslogger: Convert values returned from obd to actual numbers
    obdgpslogger: option to list supported PIDs in current OBD device
    obd2kml: add graph of vss/rpm [roughly "gear ratio"]
    obdgpslogger,obdgui: Take out start/stop trip buttons
    obdgui: Set dial ranges based on real value ranges
    obdgpslogger: Do not disable the gps database functions
    obdgpslogger: Portability improvements in signal handling
    cmake: Create a configure.h file so string #defs will work with xcode
    obdgui: Add a gpsd launch wizard
    cmake: Use cpack to build packages.
    cmake: Create app bundle, including gpsd on osx
    obdgui: Make some semi-educated guesses about device names

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

  • #2
    On the general topic of the software, I am now fairly familiar with the code and the coding style. You have a nice and straightforward way of structuring your code, I find it easy to follow.

    I will be posting my KML files on a personal road trip website. I have been considering some enhancements to the output options for obd2kml. What do you think of these?

    I would like to tell that utility to generate graphs only for trips within certain dates. That will allow me to be building up a big overall trip graph, while also being able to provide snippets of my trip from my last blog post. I suggest something like

    obd2kml --from 2009-06-01 --to 2009-06-04
    Similarly, I would like to tell that utility which layers to generate. I plan on writing some new layers to explore and experiment with what kinds of graphs are possible. I propose that the layers get named by a letter, and that we pass those letters on the command line, something like

    obdgpslogger -L abceghm
    The second suggestion is something I can achieve by commenting some code and recompiling, so it is a lower priority. I plan on working on that first suggestion myself, and I only mention it here because last time you jumped on my suggestions eagerly and had them done before I could even think about them. Depending on the amount of time you spend developing obdgpslogger, I have plenty of suggestions.


    • #3
      Huh, interesting ideas. I'll address them in separate posts.

      Given that trips are started and stopped by starting and stopping the engine, and the database is kinda keyed from the point of view of trips, it seems like it would be more useful to allow someone to dump specific trips to kml [rather than selecting datums based purely on date]. If you're envisaging selecting trips based on those two date parameters, then feel free to ignore what I'm about to say.

      I can think of a couple things that might work:
      1) Give a trip list and then let people choose them:
      $ obd2kml --list-trips
      TripID       Start                       End
      1          2009-05-06 21:03     2009-05-09 06:12
      2          2009-06-01 09:33     2009-06-01 10:45
      $ obd2kml --trips=1-2
      By just doing ranges, you make it easy to sscanf, and the sql WHERE clause is easier to build. [go me, lazy as hell as ever]

      The other benefits of this is that you don't have to deal with time conversions [except once, for printing to stdout - which is a lot easier than trying to parse stuff and convert to epoch seconds], and that you don't have to worry about timezones.

      2) Another option might be to do what you describe, but use the dates to select the trips. You could modify the trip select sql [around line 157 in obdgpskml.c] to be something like:
      char select_trip_sql[4096];
      snprintf(select_trip_sql, sizeof(select_trip_sql),
         "SELECT tripid,start,end FROM trip
               WHERE (trip.end<%f AND trip.end>%f)
               OR (trip.start<%f AND trip.start>%f)
               ORDER BY tripid", endtime, starttime, endtime, starttime)
      And you'd get all trips that touch the timeframe you've described.

      Again, you'd have to parse the dates as input to convert them to epoch seconds. Which sucks to do portably IME, which is why you'll notice my code never attempts to do such a thing.

      I'm not sure which of these would be "better" - this is probably one of those times where we can either talk about it, or you can just post a patch and I'll probably accept it. Or you could wait a couple days while my brain percolates the issue and I figure out how I think it would be best done, and I get round to implementing it.

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


      • #4
        The second idea, for selecting layers from the command-line ... I have to ask, why bother?

        It might save some space in the long term, but in my worldview, for as long as something still fits on a floppy disk [for want of something that's empirically "so small it doesn't even register in my consciousness"], who cares! I'd have to try it, but I'll bet that even a whole cross-country road trip in kml would fit on a floppy if you gzip it.

        If you posted code that draws another ten layers, I'd probably just throw it in there without a second thought.

        Assuming you really do want to do it, I think there's a couple things worth thinking about.

        1) Single letters suck. It doesn't take long to run out of them in total, and it sure as hell doesn't take long for them to completely devolve from what they actually stand for. What do you do for ten graphs plotting speed vs something else? The letter "s" only gets to be used once. Letter pairs doesn't get you a lot further.

        2) Perhaps there's a magical "correct" solution lurking here:
        Change the code so that rather than being a bunch of hand-coded layers plotted, have them fully configurable.
        /// What type of layer to draw
        enum obdlayertype {
          LAYERTYPE_HEIGHT_AND_COLOR, //< Graph of height and color
          LAYERTYPE_SINGLE_HEIGHT, //< Graph of just height
          LAYERTYPE_WIDE_LINE //< Graph of a line following the road, changing width [not yet implemented]
        /// This is a linked list containing all the layers we're going to plot
        struct layer_list {
           obdlayertype layertype; //< The type of layer this represents
           const char *firstaxis; //< The first axis that will be plotted
           const char *secondaxis; //< The second axis that will be plotted [not relevant for all graphs]
           const char *kmlname; //< The "name" as it will appear in google earth
           const char *kmldesc; //< The "description" as it will appear in google earth
           int normalisedheight; //< The height to normalise this graph to
           struct layer_list *next; //< Woo, linked lists.
        This is obviously a first start just off the top of my head, and I can already see it's not great.

        But the path I'm working towards here is having a default set of graphs that obd2kml would draw, but if someone explicitly requests some graphs we can draw those instead. eg:

        obd2kml --layer="obd.vss" \
        Would draw two graphs, one of speed and one of mpg. If no --layer options were passed, then it would populate the linked list itself from a sensible set of defaults.

        To make this work well, it's already spiralled outside of simplicity, but it gives an idea for real future expansion; properly let people configure what graphs they want.

        I think this whole thing probably warrants a lot more thought than I have time to put into it today. Feel free to implement something like you described, but I get the feeling that it won't be good for a long-term solution.

        Gary (-;

        PS I still get the "why bother" vibe overall. I suspect that until you've actually *shown* any kind of real problem with dumping the whole lot, it's probably not worth caring about.
        OBDGPSLogger, for logging OBDII and/or GPS data
        OBDSim, an OBDII/ELM327 software simulator
        mp3car forums: obdgpslogger, obdsim


        • #5
          Oh, and in case it isn't obvious, I like to spend a lot of time thinking about how code will work before actually writing it :-)

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