I'm going to use a scan tool and computer graphing program to gather some "golden data" from a near-new, perfectly running vehicle.  This data could then be used for reference sometime in the future for problem diagnosis.

1. Has anybody here ever done this?  

2. What data would be the best to archive?  Since there are many monitored parameters in generic OBD-II and many more in the manufacturer's extended parameter sets, I'd like to compile a set of primary function sensor data (MAP, MAF, VSS, fuel trim, etc.) without drastically slowing down the collection process by collecting and graphing too much.

3. Anybody here play with OBD-II, hobbyist or otherwise?

That's always a good idea SWS, I have a number of databases stored, and when needed I reference them during diagnosis. This is especially useful for driveability problems.


I'm not sure what capability your OBDII scanner has, but grab all the sensors your tool shows and always include fuel trim data. I usually skip generic and go right into OEM(or mfg specific) on most cars. In a somewhat related topic, I also have a database of freee frame data for a complete vehicle history of customers. When I get a new customer in the shop I may scan the OBDII system and put that info in thier customer file for future reference as part of the vehicle history. It's all helpful especially when you have a large customer base, you can't remember everything, well I sure don't.

What I like to do is plug in my scanner when I run cars on the dyno, but you can get good data on the road too, it's just easier on the dyno because I don't need a driver while I view and record the live datastreams from the passenger seat. If you only record at idle you won't get good HO2S readings, the car has to be warmed up and under some load to read them properly.

Besides the dyno, I also have two road course runs that I use to record data. One local and one HWY.


You should look for a stretch of mostly deserted road where there's very little -if any- traffic.

Develope a 'course' where you can repeat the same conditions over and over, such as vehicle speed, load etc. on every car you test. It will take a few runs to set up your own test drive parameters but they should include some stop and go, normal city driving, aggressive city driving etc. Record all the

Then try a highway run at average speed.

The idea of using a test course is to be able to reproduce the same load and speed inputs. This way, when you get the problem car in your shop you will have data to compare based on the same inputs and conditions.

Of course you have to take into account mileage and maintenance of the problem vehicle for small variations of data, but when something is out, but not enough to trip a code you will see it.

We all know that reading an OBDII code doesn't always tell you everything. Most of the time you need more information to make the proper diagnosis, and viewing the live datastream is one of the tools I use to help nail it down. Freeze frame data(if available) to see when a code was tripped, this will tell you what the conditions were at the time.

SWS, good luck with your project, it will certainly be worth it.

Os1k - thanks for the comprehensive response.

Quoted: I also have a database of freee frame data for a complete vehicle history of customers. When I get a new customer in the shop I may scan the OBDII system and put that info in thier customer file for future reference as part of the vehicle history. Excellent idea.  I take it that you're a professional tech? We all know that reading an OBDII code doesn't always tell you everything. Most of the time you need more information to make the proper diagnosis, and viewing the live datastream is one of the tools I use to help nail it down. Freeze frame data(if available) to see when a code was tripped, this will tell you what the conditions were at the time. +1.  I'll assume that a failure that's "hard enough" to trip the SES light (emission problem) will be reasonably straight forward to trace and troubleshoot.  Based on previous experiences though, I'm really gathering the data to help locate subtle driveability problems sometime in the (hopefully) distant future.

I'm currently using the AutoTap® reader gizmo, AutoTap® software and my laptop computer.  My old OTC Monitor Elite® is a good device but it looks like OTC will not be supporting this product with new software for any vehicle past about 2002.  It will do generic OBD-II on any vehicle in a basic format, but nothing extended.  The AutoTap was a bit cheaper than a new OTC Nemisys® and does vitually everything except airbag and ABS.

Here's a screenshot of my first road test with the AutoTap.  I'll be adding more parameters when I learn the ins and outs of the tool a little better:

That's very nice I haven't seen that one but I almost bought the software from EASE Diagnostics to run OBDII on my laptop but the laptop was too damn problematic back then so I went with a scantool.

How many parameters can you bring up at one time?  Can you change them into a numeric only format as well as guages to give you more lines of data? Thanks.


Amongst a few others at the shop I have the OTC Genesys which can save data right on the tool, but I think it has limited space so I always record the data on my laptop then after I get a bunch saved I delete them from the tool just in case I run out of room.

I'm still not happy with the Genesys, over $5k and it's slow as a snail. They supposedly have an updated Compact Flash card for it that speeds it up but that's another $500-$600 with the software update.

I'm thinking about a windows based program for the laptop, let me know how you like it.

AutoTap is a great system since you can store data with it. Won't bankrupt you either

Quoted: How many parameters can you bring up at one time?  Can you change them into a numeric only format as well as guages to give you more lines of data? Thanks. I'm thinking about a windows based program for the laptop, let me know how you like it.

You can display and log an "infinite" number of parameters, but the AutoTap people warn that it will slow down the response time of the software's logging, and they suggest that the OBD-II bus may also be a bottleneck to detailed logging.

The computer screen display can be set to dials, gauges, reading vs. time (x-y) graphs, and lists.  All data can be exported to a delimited ASCII file, regardless of screen display type.  The size, color and font of the display is completely customizable.  The dials, gauges and graphs can be internally color coded to denote "normal" and "abnormal" operating ranges.

I'll play with this thing some more and maybe post a few more screenshots using different data collection methods.

AutoTap Website

Quoted: AutoTap is a great system since you can store data with it. Won't bankrupt you either

+1.

I looked at the OTC Nemisys, but for the money I couldn't tell how good the data logging feature was.  My OTC Monitor Elite had a barely adequate software suite.

Since I'm not making any money at this, The OTC Genisys and the comparable Snap-on stuff was way out of my price range.  Plus, I don't need bi-directional features since I won't be flashing the PCM or BCM memory any time soon.

I like the Car Code system.  The software doesn't take too much computing power to run and it's very thorough.

www.obd-2.com

It can run in "flight data recorder" mode for long periods of time.  I have done what others have referenced here, taken baseline runs and done before-and-after runs when doing things like combustion chamber cleaner.

jim

Added a graph to show the relationship between O2 sensor #1 (pre-catalyst) and O2 sensor #2 (post-catalyst)

Also added Engine Run Time, Odometer, Crankshaft Sensor Output Counts, and Throttle Position Sensor details on three gauges.