Announcement

Collapse
No announcement yet.

OSDash Web Interface Definition

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

  • OSDash Web Interface Definition

    What is the OSDash web interface?

    OSDash is made up of three main components plus a data exchange standard.
    1. OSDash client - runs on the local pc and interfaces with the web services
    2. OSDash server - the server that exposes the web services to OSDash clients
    3. OSDash data standard - standardized data exchange packets for the web services
    4. OSDash web interface.

    The OSDash web interface is an online web page(s) that allows the users to control the settings for various web services that he/she is interested in using. The web page will allow the user to see available OSDash web services and activate them for use with their car pc or mobile device.

    The web interface will provide user id and password for both security and to allow the user to store custom settings for the services.

    Mp3car.com has agreed to write the web interface for the OSDash project and to provide the server space with user id and password services.
    Originally posted by ghettocruzer
    I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
    Want to:
    -Find out about the new iBug iPad install?
    -Find out about carPC's in just 5 minutes? View the Car PC 101 video

  • #2
    This web interface will need to be severely user friendly. I would take hints from the Apple Mobile Me web interface
    - Project: Unified Car Control
    - Original OpenMobile Interface Designer

    Comment


    • #3
      I haven't used the Apple Mobile Me service but yes, the idea is to be very user friendly and make it as simple as possible.

      Otherwise, we just won't be able to attract users for the services.
      Originally posted by ghettocruzer
      I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
      Want to:
      -Find out about the new iBug iPad install?
      -Find out about carPC's in just 5 minutes? View the Car PC 101 video

      Comment


      • #4
        Intuitive is our goal.

        Comment


        • #5
          Here's an example of a situation where the web interface could be used under a services based approach to OBDII.

          Essentially, that project is a bluetooth OBDII reader for the Motorola Droid. He mentions the idea of disconnecting the user interface from the communications code that runs on the Droid. A web service for the user interface could be built that would allow multiple interfaces (simple example - one red, one blue to match the interior lights on your car) to be selected through the web interface.

          When you log in, the web interface would display the available web services, you would select the OBDII service and one of the options to configure it would be which interface (that is, which skin) you want displayed on the phone.
          Originally posted by ghettocruzer
          I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
          Want to:
          -Find out about the new iBug iPad install?
          -Find out about carPC's in just 5 minutes? View the Car PC 101 video

          Comment


          • #6
            good catch on the Voyager project. It is a very smart example of the way things should be handled.
            - Project: Unified Car Control
            - Original OpenMobile Interface Designer

            Comment


            • #7
              User Friendly

              Good call making it as intuitive as possible.

              As far as graphable datasets does anyone have the expertise to make -->this type of graph<-- work on a webpage?

              I'm not much of a web programmer so this might be crazy but what if we had a OSDash component that
              * Provided a gateway for Carputers to upload data such as OBDii stats, and whatever else
              * Provided an OSDash web interface to that data with the ability to build composite graphs against the data using Chronoscope (see link above).

              In addition to graphs, other reporting could be performed. Like summary data that is digestable.

              Comment


              • #8
                jQuery has some awesome graph plugins that make creating datasets very user friendly

                Comment


                • #9
                  rock on, that's totally bada55. Imagine driving to work, then logging in to OSDash online and analyzing your vehicle's performance with killer graphs.

                  Voyager could upload the data in XML table format and the web component could just take that XML and stuff it right into the DB. Then the jQuery graphing component would present the data.

                  Voyager stores metrics by "trip" including trip start and end date/time. The web component would just query it
                  SELECT requestID, data from obdScanData where tripID = 1234;

                  Voyager also logs GPS data to a gpsTracks table, so we could have a map overlay.

                  Present a graph, along with some summary text:
                  "Intake Air flow rate is suboptimal, recommend primary air filter replacement"
                  "Trip length X minutes, distance Y Miles, stop time Z seconds"
                  "New DTC trouble code found. Recommend tighten gas cap"
                  "Performance trending downward on cylinder 1, recommend tune-up"

                  I'd be interested in championing or teaming up for this particular web piece. In about a month or two I'll have Voyager stabilized to the point where I'll be ready for a new project.

                  Comment


                  • #10
                    I don't mean to shoot down some of your ideas but the standardized OBDII PIDs really don't give a lot of useful data and certainly not enough to gather performance info. The data your looking at would need to be compared to a baseline with exactly the same barometric pressure, air quality, temperature and fuel which certainly won't happen in the real world.
                    openMobile - An open source C# Front End (why choose openMobile?)
                    - Always Recruiting Developers -
                    Like what you see? Donations are always welcome

                    Comment


                    • #11
                      Yeah, the real world gets quite messy, doesn't it?

                      Of course, part of the web site that accesses this data could still do comparisons and trend analysis. The temperatures and pressure can be gotten from localized measurements like nat weather service in the US.

                      That's not optimal, but what is? Comparing engine performance data over time and looking for trends will still yield useful information. Not to mention a set of baselines over time.
                      Originally posted by ghettocruzer
                      I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
                      Want to:
                      -Find out about the new iBug iPad install?
                      -Find out about carPC's in just 5 minutes? View the Car PC 101 video

                      Comment


                      • #12
                        We might not be able to perform end-to-end diagnosis based on the 50 or so mode 1 pids available to us, but we can certainly collect data and analyze that data in search for anomalies based on past performance.

                        With enough eyes on this, we could certainly come up with one or two maybe a dozen things that can be spotted from the data.

                        Barometric pressure and temperature can be obtained from accuweather Not to mention barometric pressure can be easily calculated based on a prior datapoint for the same location, especially if altitude is known (from GPS).

                        If we can present the information to the average user, we're bound to have new ideas for ways to analyze what we have and draw insightful conclusions.

                        Comment


                        • #13
                          Eh...don't take this the wrong way but i think you need to do some googling. Even with the full set of standardized PIDs there is just not enough data to give any performance info. Its like trying to tell the temperature without a thermometer, you know if its hot or cold but not much more then that. And in the case that something is really off your car will throw a trouble code before the O2 sensors even start to show it.

                          As far as the atmospheric thing, temperature, pressure and air quality can vary every few inches. I'm not stopping you from making a historical graph of the accelerator pedal position but is that really useful to anyone?
                          openMobile - An open source C# Front End (why choose openMobile?)
                          - Always Recruiting Developers -
                          Like what you see? Donations are always welcome

                          Comment


                          • #14
                            JC I think your point is that we can't perform an end-to-end diagnostic with the data presented by
                            OBD. Nobody's disagreeing with you.

                            It is also true that if something goes wrong in the car that negatively affects emissions, a code will be thrown. But if something fails which is not emissions related you might not get a code.

                            I could give many examples of how historical data could prove useful. If we dwell on what "can't be done" then we're not being innovative. Worked on projects like this before. The worst thing to do at this stage in the game is to focus on what you think can't be done without any proof.

                            Comment


                            • #15
                              Originally posted by regulatre View Post
                              JC I think your point is that we can't perform an end-to-end diagnostic with the data presented by
                              OBD. Nobody's disagreeing with you.

                              It is also true that if something goes wrong in the car that negatively affects emissions, a code will be thrown. But if something fails which is not emissions related you might not get a code.

                              I could give many examples of how historical data could prove useful. If we dwell on what "can't be done" then we're not being innovative. Worked on projects like this before. The worst thing to do at this stage in the game is to focus on what you think can't be done without any proof.
                              There's lots of useful statistics that can be generated with obdII data. Look at what Chunky_Ks has produced with obdgpslogger.

                              Anyway, OBD stuff is not really related to this thread's topic so .
                              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.

                              Comment

                              Working...
                              X