OBD - on-board diagnostics.
OBD II - second-generation OBD, as specified by SAE J1979.
EOBD - Euro-specification OBD;
slightly different from SAE-spec.
JOBD - Japanese-specification OBD;
slightly different from SAE-spec.
DTC - diagnostic trouble code; P-codes refer to powertrain manage-ment faults; U-codes flag communi-cation network errors; B-codes relate to faults in body system manage-ment; C-codes are chassis system based.
PDTC - Permanent DTC; one that cannot be cleared directly via scan tool command; such codes will self-clear after the affected monitors have successfully run to completion with no further faults. PDTCs are written into a section of nonvolatile memory, so they persist even if the
battery is disconnected and all capac-itors are discharged.
PID - parameter identification; a val-ue found in current or freeze frame data; may indicate a sensor reading, calculated value or command status.
In a nongeneric (enhanced) interface, may indicate a substituted value.
$- or -$ - prefix or suffix indicating that an alphanumeric string is hexa-decimal (presented in base 16.) The J1979 specifications which establish the OBD II protocol are written using hexadecimal notation throughout.
Datastream - a set of PID values, DTCs, test results and/or PDTCs; the display of such data on or via a scan tool.
Freeze frame - a set of PID values in-dicating then-current data written into the PCM’s memory when a DTC
sets, similar to an aircraft flight recorder. Note:Freeze frame data is erased when codes are cleared; be sure to read and record before clear-ing DTCs.
CAN - controller area network; also, communication via the same.
Monitor - one or more self-tests exe-cuted by the OBD system to deter-mine whether a specific subsystem is functioning within normal limits.
Monitor status changes to incom-plete or “not done” when DTCs are cleared, and returns to complete or
“done” once all relevant self-tests have been run. A monitor status showing completion is not a guaran-tee of a successful repair unless there are no codes and no pending codes, and unless the vehicle has been oper-ated under conditions similar to those under which a previous fault had occurred (see freeze frame).
Glossary
cars, check the ETOH_PCT PID to help your analyzer figure out the cor-rect stoichiometric ratio. Once you’ve made the proper selection, you can work from lambda without bothering to know or remember the exact stoichio-metric ratio involved.
I was certainly glad to see the
appear-ance of purge data in the generic list, as knowing the commanded purge status can assist in diagnosing several types of driveability faults above and beyond evap leaks and malfunctions. Remem-ber, however, that this PID reflects only the current commanded state, not nec-essarily what’s actually happening.
The PIDs for EGR Command and EGR Error are likewise helpful. De-pending on the interface you use, how-ever, EGR_Error may be reported
“backwards,” with 100% indicating that command and position are in complete agreement and 0% indicating that one shows wide-open while the other shows shut. (I’ve seen this on numer-ous Hondas, where a 99.5% “error” ac-tually meant that the valve was closed as commanded.) As usual, a few min-utes checking known-good vehicles can help avoid many wasted hours hunting problems that aren’t really there.
Other new PIDs inform us of the mileage since the last time the codes were cleared as well as the distance driven since the MIL first illuminated for any current codes. Both of these pieces of information can be useful, es-pecially if yours is not the first shop to look at a particular problem. In the case of intermittent faults, they can also help give you a better idea of just how fre-quently the issue does arise.
Beyond PIDS
Potentially both more helpful and more problematic are the new Permanent DTCs found in mode $0A. These can-not be cleared directly via a scan tool, but will be self-erased once the corre-sponding monitors have successfully run to completion. Attempts to circum-vent plug & play emissions tests by sim-ply clearing codes without fixing the underlying causes led to the develop-ment of these Permanent DTCs. While there are times when I would rather just “kill the MIL,” the PDTCs make me take the extra time to more fully ed-ucate my customers and to verify the efficacy of my repairs, often by resort-ing to Mode $06 data analysis.
The key thing to remember when working with Mode $06 data is that it’s entirely up to the OEM to define all TID$, CID$, MID$, etc. These defini-tions can vary by year, engine, model and/or equipment even within the same OEM division, so be sure to veri-fy the accuracy of any information you’re using to interpret this data be-fore you get yourself in trouble. Also remember that many manufacturers
DOING IT ALL WITH GENERIC DATASTREAM
Circle #16
populate their Mode $06 datastream with “placeholder” values after codes are cleared and until affected monitors have run to completion. This is a strong argument for waiting as long as possible before clearing codes.
Probably 90% of the MIL-on com-plaints we see in my shop are resolved using “just” a generic scanner, coupled, of course, with a few decades of experi-ence! Nevertheless, since a generic scan interface can take you only so far, there are certainly other times when we break out one of our more sophisti-cated scan tools with bidirectional func-tionality, access to additional PIDs, guided diagnostics, etc.
Especially in an older vehicle, the generic communications data rate (baud speed) may also seem slow by to-day’s standards. After an initial scan, this limitation can often be overcome by se-lecting a relatively small number of PIDs relevant to the problem at hand.
All vehicles since 2008 support CAN communications even in the generic in-terface. The effective data transfer rates
here are plenty quick enough for almost any practical purpose.
Since OBD II generic standards do not apply beyond P-codes (and some U-codes), any full-service shop needs one or more scanners to deal with B-, C-and most U-code issues. Remember, though, that many OEMs illuminate TRAC, VSC and/or ABS lights in re-sponse to any P-code. This is nearly uni-versally true in the case of drive-by-wire (electronic throttle body) applications, but may be found in many other in-stances as well. In all such cases, you must resolve the P-code issue first, be-fore worrying about any of these side-effects codes. If you have an appropri-ate interface, once you’ve killed the MIL, clear those extra codes as well, so the next tech doesn’t find them still in memory if and when a legitimate B- or C-code ever does set.
The bottom line is that there are sev-eral potentially important advantages to using a generic scan interface for initial code retrieval and data analysis, so don’t be afraid to get your feet wet! Since the
generic datastream focuses on the most important inputs and commands, where the bulk of problems occur, and since all PID values reflect their associated sensor states without substitution, you’re less likely to be capsized by a flood of irrelevant data.
As always, checking known-good ve-hicles will help keep you on an even keel and familiarize you with what
“good” looks like. While you may occa-sionally wind up switching over to an enhanced interface, you’ll likely find that routinely starting in generic using a fast and inexpensive basic scanner re-sults in much greater efficiency.
Whether your shop is large or small, this practice also lets you avoid exces-sive wear and tear on the more expen-sive and advanced scanners and keeps them free for those longer-term diag-nostic challenges where their enhanced features are actually needed.
29 July 2014
This article can be found online at www.motormagazine.com.
Circle #17
10 February 2015
T
he commanded equivalence(EQ) ratio parameter (PID) is required in the generic data-stream on all passenger vehi-cles since 2008 (see the EQ to air/fuel ratio [AFR] matrix on the next page and the SAE definition in the box on page 13). An EQ of 1 equals 14.7:1 AFR. This PID should reflect the com-manded air/fuel ratio. That being said, there are no Bank1 and Bank2 EQ ratio PIDs, and can’t the EQ or AFR be differ-ent for each bank? Are the two averaged?
Yipes! How is this going to work on a vehicle?
This test was performed on a 2010 Toyota Tacoma with a 4.0L engine. It’s important to note that this may not be representative of other vehicles; this is one test. Also, this test is not intended to be critical of any im-plementation of the EQ PID. I think the problem is in the original definition of this
PID—there is no differentiation for Bank1 and Bank2.
Now let’s get into the layout of the screen capture below, from the 2010 Tacoma:
In the top chart, rpm is in red (the scale on the left-hand side) and vehicle speed is in green (the scale on the right-hand side).
In the second chart, air/fuel ratio sensors Bank1 and Bank2 are in milliamps, and both are scaled on the left-hand side.
In the third chart, the air/fuel ratio sen-sors Bank1 and Bank2 are in volts, and both are scaled on the left-hand side.
In the fourth chart. postcatalyst O2 Sen-sors Bank1 and Bank2 are in volts, and both are scaled on the left-hand side.
In the last chart, the commanded EQ ra-tio is scaled on the left-hand side.
All data to the left of the dotted line in the screen capture is a baseline test drive ending with a long idle period prior to intro-ducing a skew in B1S1 AFR sensor (the