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.
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.
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?
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.
Originally Posted by regulatre
Anyway, OBD stuff is not really related to this thread's topic so :focus: .
Sooo...what will the requirements for the web front end be?
How will new web services be discovered?
Will each service require a hand coded web page to access its controls and settings?
Are there architecture concerns we need to address before building the interface?
Do developers have to supply some type of file like xml to specify the inputs required for the service to function?
How will average users be able to configure the services?
Are there certain functions like 'save" or "test" that are required for the web interface?
I'd like to try and answer some of these questions by specifying use cases that will help to answer them. Before I do that, what do others envision for the web interface? Is it mostly front end stuff or does it include backend stuff as well?
Any ideas are welcome.
Well if you couldn't tell i've done quite a few projects in this area before. While i might not have cited all my sources after the openOBD project, including the DTC database, Manufacturer specific PIDs and about half a dozen other projects that will soon be coming to light it certainly wasn't coming from nowhere. If you have some more specific ideas of what is possible I would be happy to help with them but years of project experience has taught me one of the most important things is realistic goals.
Originally Posted by regulatre
I'm familiar with it...but all I see is mpg data which generated purely from the obd data tends to only be semi-accurate on modern cars. On earlier cars its not accurate at all since engine efficiency needs to be known.
Originally Posted by kev000
but yea this is way off topic....bugbyte can you split this off into a separate thread?
Maybe there would 2 main sections for every user. Dashboard and Settings. Dashboard is the main screen where they interface with their client, and settings are all the backend preferences for their OS Dash account.
And maybe we should take a hint from the popular vBulletin, when you make a new Product, all the settings data are in a standardized XML file, that vBulletin understands. So maybe an OSDash standard XML declaration that all Plugins abide by?
I'm also a huge fan of having a dedicated Update URL. So the XML Files should be hosted, and when a dev wants to an issue an update they just update their XML file on the cloud and OSDash will let the user know an update is ready. No checking for new downloads, no checking version compatibility, you just hit ok and it updates.
I like the idea of test/save. In the XML config of a plugin it should have BETA turned on or off. If its in BETA there are warnings in the plugin to let clients know, but maybe there would be built in bug tracking for all plugins if BETA is on. So OSDash would be very attractive to devs because they will get to deploy their plugin to the community, knowing its beta, and get standardized feedback to work with.
Good ideas, especially the xml settings. How does that work?
Also, maybe a tab in your Vbulletin user control panel that says "myDash" or whatever and when you go to it, you have your OSDash settings that are stored under your user ID and also a way to get to work with the client interface, test your settings and so forth.
Well since its XML basically we just have to define in the OSDash API what we will expect to have.
<title>os dash product</title>
or something like that. Basically we just have expectations.