Freeze frame data is recorded when the PCM decides a fault has occurred and has ordered the MIL to come on. This record will typically show the driving conditions required by non-continuous monitors for their testing and may point out where in the testing sequence the system failed. It is even more useful on continuous monitor DTCs, like misfire and fuel trim, in giving you an idea of the driving conditions that were in place when the fault occurred.

Just keep in mind that the data may have set well after the fault, so use this information to test the vehicle in a manner that will simulate the logged conditions and typical conditions that might have occurred just before the log. For example, a misfire freeze frame might show the vehicle at cruise speed, but the misfire could have happened during acceleration to that speed rather than at a steady cruise.

WHAT'S NEXT?

The next step in our procedure is to learn how the PCM operates tests for these codes so we can devise an appropriate test or tests to find the failure. How? By going back to our service information system and looking up the information on the DTCs themselves. We can also research for further information by looking under "System and Component Testing" and the "Theory and Operation" sections.

When you look up the DTC information, you also will find a testing procedure, or "flowchart." I want to challenge you now to rethink how you use the flowchart for your testing. If you don't know or understand why you are performing the tests listed, you may end up with more questions than answers. Instead, think like the PCM and ask yourself "What causes this code to set? What test did the PCM use to determine the fault? How can I test it the same way?"

For these questions, the testing described in the flowchart is a tool to understanding. This is not a complicated example, I know. But the thought process is one you can apply to any system if you do your homework first, and I guarantee a little time invested up front is going to save you more time overall.

A little reading on the DTCs criteria and study of the wiring diagram, tells us that the PCM controls the heater on the ground side. See Figure 5. There is a driver for the heater on each sensor. Power is supplied through a common lead to the heaters themselves. The codes also provide information. These are not rationality or functional tests, but circuit tests.

By studying the conditions for setting the DTCs, we see what the computer is looking for. A reference voltage is sent through the O₂ sensor signal circuit, and if the heater is functioning, the resistance internal to the sensor will increase as it's heated. This increased resistance will cause a voltage drop the PCM can see.

If that drop does not reach a specified point in a specified time, the PCM knows the heater is not doing its job. It also continues to monitor the reference for an additional time to make sure the sensor circuit itself is intact. If the voltage remains high, then it's also possible that the sensor is shorted to power or an additional problem exists.

Now it is time to apply our skills as techs. What would cause both of these codes to set? That is how we decide what tests to make. If the heater isn't working, then the sensor will not heat up enough to create the voltage drop the PCM is looking for in both tests. Because the heater monitor must run first, it would make sense to check the heater circuit first.

So far, we've gathered information and tried to consider the process the PCM is using to test its systems. Now that we have it all assembled we can go under the hood and see what's happening, designing the tests we use based on the observations and information we've taken the time to gather. In this particular case, a bad connector pin in the harness for the sensor was the cause. The connector is repaired and we're done, right?

NOT QUITE