The device that service technicians use worldwide to diagnose various vehicle management systems originally began as an in-plant quality control tool. The "assembly line communication link" was used in the late 1970s in assembly lines that built California versions of the Cutlass Supreme. The V-8 engine, with an electronically controlled feedback carburetor and a unique one-row connector, provided the information to the plant employees if the powertrain control module (PCM) circuits were corrupted during assembly. In the time equal to the flash of the light saber, data analysis has exploded. "Look at us now!" Communication between the vehicle control module, body control module, supplemental restraint module, global positioning information, and specification reprogramming for Class 8 trucks just scratches the surface of scan tool capabilities. Reprogramming of late model PCMs are some of the features of today's selected enhanced scan tools.

Let's walk through part of that evolution to reveal some information that may allow service technicians greater insight to one of those "magic boxes" that we rely upon so often. A few terms should be addressed, "baud rate" being one of them. This is the speed at which the PCM reviews data within the central processor itself. Baud rate affects how quickly the scan tool can "sample" information at the "data link connector," a J-1930 term coined as part of the OBD regulations. Early feedback carburetor-equipped GM vehicles' baud rate was below 200 bits a second, and many were at 8,160 or 8,192 bits a second for late model GM fuel injected vehicles. Ford EEC IV PCMs were touted at 4,800 baud rate with a maximum of 9,600 bits of data per second. Chrysler's SMEC, SBEC systems internally make computations at a baud rate of 7,812 bits of data a second. Again, this is rate the PCM reviews data, which will affect the "sample rate." So far, all those items we see on the scan tool have not yet left the CPU.

Sample rate is the amount of complete data displays made available to the diagnostic connector from the PCM. GM sample rates varied from once per 1.2 seconds in the early years to nearly 10 times a second prior to 1996. Ford EEC IV vehicles with data stream update information to the diagnostic connector from four times a second to about once per 1.5 seconds. Chrysler PCMs display information at 22 times a second. Now the scan tool becomes part of the data collection and reads the picture as its interface with the vehicle begins.

"Update rate," also referred to as "refresh rate," is the speed at which each scan tool displays data onto its liquid crystal display (LCD) screen. The display of data is a two-part function. The software and hardware of the scan tool determine the display rate of information on the LCD. Early versions of software combined with an early generation scan tool may talk to pre-OBD I mandated vehicles (pre-1988), but may not communicate with 1988 and later vehicles at all. Put in updated software and, voila, "Can we talk?" You bet, but to a point. Gee, an exception to the rule? Is that new to this industry? I think not, some things just do not change. As OEM manufacturers improved the function of engine control management diagnostic features, scan tool makers had to change the hardware platforms of their tools. This may have required a physical dimension change besides an internal update of the hardware platform. This meant some changes for us in the field. New software may or may not interface with the older hardware. And the new hardware platforms may not support older software (circa 1988-89). In the 1990s, the dust settled and many new improvements in processors resulted in great leaps of storage for software "cartridges" that now include volumes of specifications or data previously found in printed media.

Are the signals on these systems different? How did they improve? Manufacturers will vary the speed from 1.5 Hz to 4 Hz for OBD I vehicles. OBD II LCD refresh rates vary from 0.75 to 1.5 Hz on the scan tool. The OEM specific or "enhanced" data display can be faster at the discretion of OEM manufacturers. Displaying data on OBD II vehicles is further complicated by the Clean Air Act Amendments of 1990 that created "generic" and OEM-specific data displays. We all recall that OBD II generic data is dispensed to the scan tool once every 1.25 seconds. Yes, the screen is faster than the data on those vehicles. OBD II data is processed at a baud rate of 10.4 kilobits of data a second on the K line for domestic data and the ISO circuit for import vehicles. The HS 3000 standards for OBD II vehicles require the scan tool to sample data at eight to ten times a second to the diagnostic connector. Both OBD II displays, "generic" and "enhanced," are affected by the number of items requested to be displayed simultaneously. One data bit is delivered to the connector near 8 Hz, two items near 4 Hz, 3 items near 2 Hz, and 4 or more slows the data delivery further.

What about graphing programs, recordings, movies, snapshots or events? These features were added by the scan tool manufacturers once they knew we were hooked into using this high ticket, err high tech (ha, ha), equipment. These features allow the field technician to capture data during a fault on the road. Of more importance as a capture feature was the elimination of one level of the data interface in the "chain" of tasks needed to display scan tool data. The scan tool captures data at the speed it receives it, eliminating the time lag required by LCD operations. Thus, when playing back data for review, there seems to be more information in less time than looking at the scan tool "live." Yes, that was tongue-in-cheek, as this article's intent is to illustrate that the "live" data stream does not exist.

Recording, movie or snapshot length is wholly dependent upon the scan tool manufacturer design, per vehicle applications. The use of that data is dependent upon the field technician's familiarity of the data -in two words, experience and training. The technician must know or have reference to what the scan data should read, or know typical readings. Programs that plot scan tool data onto graphs are also very useful in diagnosis. These programs allow multiple data bit displays for comparison of information over time. Now if the field technician is to add an action during the recording, such as a throttle opening, and the vehicle replies with a driveability complaint such as a tip in hesitation, the display of data over time can now offer volumes of help in identifying the root cause of the fault. If the root cause is a monitored component with a data bit displayed by a scan tool reading, your chances of capturing that glitch via a movie, snapshot or recording increase five fold over trying to "see" that fault on the scan tool display screen. Using a PC display to watch data changes adds visual enhancement for the field technician with colored line graphs, bar graphs or numerical data that may be color coded red, yellow or green to "flag" failed, marginal or good readings.

Another step in data retrieval involves the personal computer, specialized software and specific cabling to allow the direct data transfer of vehicle information to the PC screen. Obviously this offers a logical advantage, the elimination of another interface with its software package, the scan tool itself. Sounds great, but what about test drive data retrieval? Specialized recording equipment is being made or is available for specific software data programs that will provide that essential intermittent driveability complaint weapon in our diagnostic war with today's vehicles.

"Ghost codes" are another point in the data review. What are they and how are they set? These anomalies are just that, hardware to software errors between the perceived vehicle of the PCM hardware to the PROM information supplied to the PCM. These are characterized as codes for equipment that are not on the vehicle or circuits that are identified as faulty when those circuits do not exist on the vehicle. Scan tools also reveal more and more data per vehicle from the same vehicle as OEM manufacturers reveal more encryption information that allows the scan tool to translate information to its LCD screen. For example, for GM vehicles that did not display injector pulsewidth, such as throttle-body-equipped light trucks, cars and vans, the command was always there, but not available for translation to the LCD. Other examples are the data bits, mass air flow, air flow and LV-8. Mid to late 1980s port-injected GMs displayed MAF and AF data or MAF and LV-8 data items. However, testing the same vehicle using later software with all three items displayed, the data was there, but not translated. Of course we have all seen vehicles with mass air flow sensors in operation and the scan data display either omits the MAF entirely or lists the data bit and fills the reading column with those infamous "XXXX" values. Hmmm, "40" in Roman numerals -is that in liters per minute, grams per second or what?

Default values are data readings that are very close to normal readings, but a diagnostic trouble code is present. Examples include when the Check Engine, Service Engine Soon or Malfunction Indicator lamps are lit, yet the scan tool reading is almost normal. This is simply the result of the data retrieval device relaying what it is being told by the PCM from PROM look-up tables. These are examples of the PCM "thinking" to compensate for the missing or erroneous data input to it. How about scan tool indications that a device is "on" when the field technician knows that it is not? Again, the scan tool is displaying the data command from the PCM's CPU to specific address registers, and performing computations. This code, when reviewed by the PROM filtered by RAM to the PCM output drivers, issues a "command" to energize. An example is the torque converter clutch. This command is received in a digital code to the scan tool. It is processed by the scan tool CPU through its software cartridge as a command to change a data display or illuminate a lamp confirming that "a command to energize" has been verified. OEM manufacturers can modify this chain of events. Thus, the process is changed to initiate a scan tool command data display change from an actual PCM actuator voltage change, pulsewidth modified digital command status change of HZ or duration or actual discrete signal voltage change. This "enhancement" is via the change of the OEM manufacturers PCM change, not the scan tool internal hardware or software mapping.

It may seem to be an ironic situation. Scan tool data has some pitfalls that many field technicians have recognized, perhaps through the school of scan data hard knocks. Engine management data complications have many examples of oopses. But how do we deal with air bag, anti-lock brake, body control, heating/ventilation and air conditioning, traction control and transmission control diagnoses with these same opportunities for error? Those computation faults are rarely a cause of data errors as these sub systems have far fewer signals to monitor and actuators to control.

The high-level added computation required of three-dimensional mapping for fuel, timing and emission control -along with the ever-increasing number of items to monitor with their own parameters of digital or analog information -is the "stumbling block" of engine control computers. OBD II processors have enhanced logic capability for examining the rationality of input data. The functionality of outputs is also examined by using internal self-tests, called monitors, to gauge component and engine management operation. The goal is to keep tailpipe emissions as close to certified levels as possible.

For some, this walk down memory lane put a smile on your face as you were reminded of what we've dealt with in the past. I hope that when you take a look at where we are today, an even broader smile emerges. Each repair facility can learn from the past evolution of scan tools, and look forward to a promising future.

Keith Kraehmer is a senior instructor and research specialist with Target Training Systems. He is also the chief technical writer and senior trainer. He has written numerous technical and update manuals as well as training videos for Target Training Systems. Kraehmer is a master ASE technician with L-1 certification, a Certified Truck Technician, and a MACS and IMACA certified instructor in CFC handling and retrofit procedures. Contact Target Training Systems at (800) 366-8724.

RATE THIS ARTICLE What do you think of this article? Your input will help AutoInc. develop additional articles on this subject. Share your thoughts! Your name Your e-mail address

MOST ACCESSED ARTICLES Fuel Injection Service, Not Just Cleaning The Art of Extraction EGR Systems: Operation and Diagnosis Proactive Target Marketing:_Rethinking Your Business Strategy Engine Performance: HO2S Diagnostics MOST E-MAILED ARTICLES Developing Employee Potential How Critical Thinking Can Help Your Business How to Diagnose the Ford Glow Plug What to Look for When Shopping for the Right Shop Management Software Putting a Price Tag on Complaints

AutoInc. Web Site | ASA Web Site | U.S. Appeals Court Rejects Clean Air Regulations | Scan Tool Information: Data or Dogma? | How Accurate is That Computerized Estimate? | Clearing the Hurdles of Estimating Systems Training | Organizing the Office | AutoInc.'s Ninth Annual Management Software Guide | Employee Stock Ownership Plans (ESOPs) | Guest Editorial | Tech to Tech | Tech Tips | Shop Profile | Net Worth | Stat Corner | Chairman's Message