Code set parameters are a critical component of accurate diagnostics

Code set parameters include information such as, but not limited to:      

• Conditions required for the code to set
  • Minimum or maximum engine temperature 
  • Engine load conditions
  • Fuel tank level 

• Interaction with other codes/tests
  • Codes that may trigger with it and which is the “primary” 
  • Tests that are disabled when the code is set 
  • Codes that can’t be present for this code to set

• Data ranges that will cause the code to set
  • What is acceptable/normal 
  • What will exceed that limit and trigger the code 

• Monitor Strategies
  • Frequency of test being run
    • Continuous monitor 
    • Once per trip 
  • Frequency of failure required to trigger the MIL/Code 
  • One-trip code (sets immediately upon failure) 
  • Two-trip code (sets after two failures within a given time frame) 
  • Required sensors/components

Building your diagnostic process 

So how can this data be helpful in a diagnostic process? To start with, honestly ask yourself if you have a diagnostic process that you are using. The basic definition I’ve used in the past for a diagnostic process is simply a series of steps used to locate the source of a problem. That’s a broad definition and realistically, the method used by each technician is likely to be somewhat different. If you haven’t thought about your diagnostic process, I’d recommend taking a few minutes to write it out step by step. Does it include some of the following steps? These are the steps that I’ve taught over the years that I feel are a good starting point to build a diagnostic foundation. 

1. Gather information from the owner and/or driver of the vehicle. (This is typically gathered by a good service advisor, but technicians need to keep them accountable to get the data.) 

1. When did the problem start? 
2. Did they notice any performance changes? 
3. Has any other work been done recently to the vehicle? 

2. Scan check the vehicle. (This should include documenting any codes, current or pending, and related freeze-frame data, if available.) 

1. May turn up codes beyond the initial complaint (related or unrelated) that could prove important 
2. Freeze-frame data may help you determine how to duplicate the problem. 
3. Documents the condition of the vehicle BEFORE you start working on it to help prevent the “ever since you” discussions after you return the customer’s vehicle 
4. Verify the monitors have all run to be sure your repairs don’t allow the vehicle to start running a test that hasn’t been run for a long time, which may turn the check engine light back on shortly after it leaves your shop. 

3. Research information related to the concern. 

1. Check for relevant TSBs, open campaigns and/or recalls. 
2. Check the service information related to any codes, including the code set conditions (parameters) 

4. Attempt to duplicate the problem. 

1. Requires the vehicle to be operated under the right conditions 
2. If you can’t duplicate the problem, do you continue? 
3. If you can’t duplicate it, can you accurately validate your repair?

5. Don’t get tunnel vision. 

1. Pay attention to the entire vehicle while test driving.
   1. The customer concern may be caused by something related that they haven’t even noticed (for instance, a check engine light caused by a leaking exhaust.) 

6. Define when/how the problem occurs. 

1. Provided you can duplicate the problem, make notes related to:
   1. Load 
   2. Speed (engine and/or vehicle) 
   3. Temperature 

7. Perform a visual inspection looking for things like: 

1. Signs of previous work 
2. Accident damage 
3. Loose/broken parts 
4. Leaks 

8. Narrow the problem down as needed. 

1. If multiple codes are present which one should you diagnose first? 
2. Attempt to eliminate potential causes of the problem one at a time.
   1. Changing more than one thing at a time can cause confusion 
   2. Typically start with the easiest item to eliminate as a potential cause, then work toward the ones that are more difficult to rule out.
      1. Note – if you have access to third-party information sources that help determine frequency of various failures, you may want to start by testing the most common failure first, even if it’s not the easiest one to test. 
3. Continue testing until you’re relatively confident you’ve found the root cause. 

9. Verify your diagnosis.
   1. If possible, bypass what you think is the root cause to see if everything works properly. 
   2. Replace the suspected failed part with a “known good.” (I’m not a fan of this one!)
      1. Be careful; if the part you substitute with a known-good one wasn’t the root cause, you could potentially damage it as well 

10. Perform the repair.  

11. Validate your repair. 
    1. Be sure to operate the vehicle under the conditions that allowed you to duplicate it previously 
    2. Don’t rely on the check engine light to verify your repair.
       1. Utilize your scan tool and the information you already know related to what conditions must be met for the codes to set.

I know that seems like a long list of things to do, but realistically most of the steps don’t take that much time to complete. It is critical that you have access to good diagnostic tools and good service information. If you can’t trust one or both of those that you have access to, you are starting out behind in the diagnostic game and are likely to end up losing too often. There are a lot of good resources and tools out there including those available directly from the OEM. If you are using aftermarket diagnostic tools, I recommend having more than one, and they should be from different manufacturers. With two different scan tools at your disposal, if you have something displaying on your scan tool that doesn’t make sense, you have a way to double check it.   

Putting it to work 

Let’s look at a real-life example of a hybrid vehicle to see how important code set parameters are in this process, even when the information isn’t necessarily as complete as we may like it to be. The vehicle in this example is a 2005 Toyota Prius. The customer complaint was that the check engine light recently came on, the fuel mileage had dropped noticeably over the last several months, and the internal combustion engine appears to be running more frequently than it used to. Upon scanning the vehicle, a code P0A80 was present with the scan tool showing a code description of “Replace Hybrid Battery Pack.” Not much to go on from that description alone, and it would be an expensive repair to make without being confident it will solve the problem (current OEM list as I’m writing this is slightly over $2,500 plus a core charge of just over $1,300).   

So, what can you learn from the code set parameters that might help confirm the vehicle does in fact need a battery pack? In this instance, there are two primary pieces of information that could be helpful. First, the “DTC Detection Condition,” as Toyota refers to it, will tell you this code for this vehicle uses two-trip detection logic. Second, it tells you that the code is triggered when there is too large of a difference in the voltages of the V-blocks within the battery. V-blocks in this case are simply two hybrid battery modules that are monitored in pairs. This pack consists of 28 modules that are monitored as 14 v-block pairs. Given that information, I know for a fact that when I clear the code, it won’t immediately set again even if the failure is still present. I also now know which data PIDs I want to focus on to determine if the failure is likely to reset (V-blocks 1-14). Lastly, I know that if the failure is currently present, to get the code to set again I would need to complete at least two drive cycles. 

Of course, that doesn’t mean the code set parameters always provide all the information I would like. For instance, Toyota doesn’t provide information on how much of a difference in voltage between the V-blocks is too much. In this case, Toyota lists the battery voltage difference under a section called “Typical Malfunction Thresholds.” Rather than providing an actual value though, they simply say that the threshold is when it exceeds the standard level. Then under the component operating range that standard level is listed as “Toyota’s intellectual property.” They also don’t define what exactly is required to meet a “drive cycle” for this monitor to run, nor do they provide details on the enabling conditions. 

The monitor information provided can sometimes help with what constitutes a drive cycle, though. For instance, with this code it’s listed as a continuous monitor. That means the test is always running whenever the vehicle is operating. Given the nature of the potential malfunction (battery voltage variance), and that this is a continuous monitor, you could likely assume this wouldn’t require a warm-up cycle to satisfy the drive cycle criteria (unlike a thermostat test, for instance). That means it’s likely that simply performing two ignition cycles with the vehicle running between them would suffice (key off to engine running = first trip; key off to engine running again = second trip). Of course, to set the code that would mean during each of those trips the code set thresholds (which aren’t defined) would need to be met. Since those aren’t provided, you need use your existing knowledge and/or other information available to determine how to best potentially duplicate the conditions to set the code. If you have freeze-frame data available, review it to see what conditions the vehicle was under when the code set. If you don’t have freeze frame data, use your own existing knowledge. In this case, it’s battery voltage we are concerned about. We should all know that to test how well a 12V battery maintains terminal voltage, you can load it down with a carbon pile tester (assuming you haven’t only been taught how to test batteries using a conductance tester, that is). These hybrid battery V-blocks can be load tested too, but you can’t exactly hook a carbon pile tester up to them. Hybrid batteries are used to help launch a vehicle by supplying current to the hybrid drive system’s electric machine(s). That means you can load them by simply doing a hard acceleration (or multiple in a row if you really want to load them down). You also likely know from experience that if a battery isn’t accepting a charge well, it will have a relatively rapid increase in the terminal voltage compared to a battery that is accepting a charge well.   

Now that we have enough information to attempt to duplicate the problem, we are almost ready to try and get the code to set again. There’s one last thing that I’d highly recommend you get in the habit of if you aren’t already doing, and that’s flight recording your test drive. Depending on your scan tool’s capabilities, you may want to reduce your data PID list for recording down to the minimum needed as this will increase the sampling rate of those PIDs. Just be sure you don’t forget a PID you might want to look at if you use a custom list. In this case, we’d only need to record the V-block data PIDs (1-14).                 

To attempt duplicating this code based on what we know, we would need to do the following: 

1. Clear the codes 

2. Start the car 

3. Start data recording 

4. Perform multiple hard accelerations, each followed by an aggressive braking event that comes to a complete stop before starting the next acceleration (I’d recommend 4-5 acceleration/braking events) 

5. Stop the vehicle 

6. Save the data recording 

7. Shut the vehicle all the way down 

8. Repeat steps 2-6 a second time (remember this is a 2-trip code) 

9. Check for codes 

If the variance in the V-block voltages was high enough, it should have reset the P0A80. If the code did not set again, all hope is not lost. Even though we don’t know the exact code set threshold, we can use the data captured to look for a trend that would indicate the code is likely to set again if operated under the right conditions (unfortunately you couldn’t be 100 percent certain). For one or more V-blocks to set this code, they would likely drop more than others during the accelerations, and then spike up higher during the braking events. You’d want to review your data recordings to look for that type of trend on one or more V-blocks. 

I used the example of a hybrid vehicle because I wanted to point out that even these advanced drive systems really aren’t any different to diagnose than any other problem, but this information is just as relevant on other systems. In fact, typically in other systems you are likely to get better-defined parameters than in this example! Things like fuel trim related codes, misfire codes, etc., can be attacked using the same type of information and concepts. As vehicles continue to get more complex, ensuring you have access to high quality service information becomes even more critical. Get familiar with where to access this data in your service information system of choice and be sure to use it as part of your routine diagnostic process and repair validation!    

Answers to the questions in the first image:

1. No, the code set parameters were not met (combined fuel correction never exceeded 35%). 

2. No, the vehicle is showing signs of excessive fuel correction - but not enough during this test drive to trigger the code. 

3. The data most likely indicates an air measurement/calculation error caused by something such as a dirty mass air flow sensor.
   1. Only correcting at low load would have indicated a potential vacuum leak 
   2. Only correcting at high load (or increased correction at high load) would indicate a potential fuel supply limitation such as a pump, restricted filter, etc. 
   3. Correction across all ranges indicates a measurement/calculation issue 

4.   Attempt to clean the mass air flow sensor and then re-test to see if it made a difference.