Results 1 to 5 of 5

Thread: New Release 0.5

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

    Join Date
    Mar 2009
    Location
    Los Angeles
    Posts
    929

    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. #2
    Newbie
    Join Date
    May 2009
    Posts
    31
    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

    Code:
    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

    Code:
    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. #3
    SuperMod - OBDII GPS Logger forum
    Auto Apps:loading...

    Join Date
    Mar 2009
    Location
    Los Angeles
    Posts
    929
    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:
    Code:
    $ 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:
    Code:
    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. #4
    SuperMod - OBDII GPS Logger forum
    Auto Apps:loading...

    Join Date
    Mar 2009
    Location
    Los Angeles
    Posts
    929
    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.
    Code:
    /// 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:

    Code:
    obd2kml --layer="obd.vss" \
         --layer="(710.7*obd.vss/obd.maf)"
    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. #5
    SuperMod - OBDII GPS Logger forum
    Auto Apps:loading...

    Join Date
    Mar 2009
    Location
    Los Angeles
    Posts
    929
    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

Similar Threads

  1. Replies: 116
    Last Post: 08-07-2008, 10:23 AM
  2. Replies: 65
    Last Post: 07-23-2008, 02:03 AM
  3. Radio control with iBus ???
    By jeep642 in forum Car Audio
    Replies: 4
    Last Post: 10-02-2007, 11:51 AM
  4. [SKIN]FPs "Bright Life" (input needed to complete)
    By yunusyu in forum FrodoPlayer
    Replies: 76
    Last Post: 06-25-2005, 02:59 PM
  5. RELEASE FreeDrive 0.5 beta
    By CdRsKuLL in forum FreeDrive
    Replies: 34
    Last Post: 04-14-2005, 07:01 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
  •