Imagine a scenario in which you had to make a decision using limited or unreliable data. Would you cross the street to get the mail if you were incapable of seeing vehicles approaching? If you made the decision to replace a component on a customer vehicle would you do it without ever having confirmed the complaint? If a shop manager was your role, would you hire someone without having interviewed them? For the sake of your health, the customers at your shop, or even the family or friend whose vehicle you have worked on you hopefully answered no to all of these. Why, then, is there so much variability in scan-tool data sitting in front of our technicians?

As an automotive instructor, limited information is a game myself and my students play every day in lab. Often, with inexperienced or new technicians, this is a similar case. Incorrect or unexpected data during lab experiences for my students can throw a wrench in their process of understanding that they are navigating. It is not very different for technicians. In the case of technicians however, we often do not have the luxury of additional time, customers who understand our mistakes, or the ability to have more experienced members of the shop guide those that are struggling.

So what happens when we encounter incorrect data from our scan tools? Scan tools have become a vital part of the modern automotive diagnostic process. When teaching students, who often end up working for manufacturers or first-and second-tier suppliers, I encourage and coach them into consistently and constantly holding a critical perspective of scan tools and the data they can provide. The holy grail of diagnosis is not the scan tool on the technician’s lap; it should be the tool between their ears that is most valuable.

Critical thinking and critical perspectives

Many technicians are good technicians because of critical thinking skills. We have all been “burned” by that one vehicle failure that seemed to defy logic in symptoms, test results and fixes. Largely, whether they realize it or not, the truthfully good technicians are technicians who make use of their critical perspective. Critical perspective is the idea or way of viewing a topic or idea based on previous knowledge and is an outcome of thinking critically. This is true regardless of the level of technology present on a vehicle. Shops that work on Gen I and II Prius know that HV battery failures in higher-mileage vehicles are frequently a result of only a few modules being significantly degraded in relation to the others rather than an entire HV battery. Many GM aficionados recall a time when any 3.1 or 3.4L 60-degree V6 from 1990-2003 with a significant coolant leak in the top end likely needed lower intake gaskets. These critical perspectives, formed out of the data collected by repeated and similar failures on similar vehicles help good technicians become more efficient in identifying, root causing, and alleviating customer concerns.

So what happens when we introduce unreliable or variable data? When a technician sees a problem they have not encountered before, how are they supposed to think critically to solve it if data is not what they would expect based on previous experience?

The PID that wasn’t

To understand why scenarios like this happen frequently, we must understand how scan tools talk to the vehicle we are working on. This begins with one of the positions my graduates often fill for manufacturers. In the global automotive manufacturing market, there is a significant lack of skill crossover. This lack of crossover translates to a significant misunderstanding between the dealer and independent shop technicians and the skill sets employed at the manufacturers in engineering and design. For the most part, manufacturers now represent a global conglomerate of engineers, designers and software engineers designing and programming vehicles, many of whom may not have any idea how their particular role in the vehicle design process is serviced, diagnosed or even operates (Also see: Location of Northstar cranking motors). Where is the responsibility for checking to ensure that the data given to technicians working on those vehicles is data that is valuable, reliable and functional? Arguably, this should be someone with a healthy experience and perspective of what could go wrong in the field (read as field experience) and how and what technicians need to fix it, but also a healthy understanding of the business, technical, and computer skills necessary to recommend a fix when a problem is identified.

All manufacturer scan tools go through this process of rigorous testing in all areas of functionality. Essentially, if we know it is 70 degrees in the shop, we know the scan tool should not be telling us that the intake air temperature is 34 degrees. Even worse, I have seen some aftermarket tools, data PIDs that are wrong entirely in their description, range or location or worse yet, scan tools sending invalid requests, which set multiple codes globally across the vehicle. So how does this happen? Frequently this is a problem with the software of the scan tool. We all might remember the “telephone” game we played as children. In many ways, the scan tool is playing a similar game. The vehicle communicates based on requests from the scan tool for information. Thanks to OBD-II a lot of this powertrain and emissions information should be readily available and named or given through compliant standards like J1850 or CAN serial bus communication. Where we as technicians might run into problems, is when the scan tool translates back to us the information the vehicle sends back. There are multiple steps to this, but the basic idea is shown in Figure 2.

(see fig. 2) 

“As you can see, there are really only three steps here, but in the software, these steps represent exceptionally vital translation processes when serial data is interpreted and displayed on a user interface. The quality of an aftermarket tool then becomes a question of the quality of translation from manufacturer information obtained by the scan tool software engineers; not technicians who know what the numbers actually should mean.”

The question becomes: What do these situations actually look like, what can we do to protect ourselves and how can we prevent misleading information from reaching our techs?

Case Study 1: Snap-on’s Verus, Driving Me to the Edge.

One of the more offensive software “bugs” that I have encountered was present on a popular-brand scan tool we own at our facility. This tool, being a high-end aftermarket device, does have similar capabilities to some manufacturer tools. The devil is in the details. When diagnosing a rough running engine one day, one of my students happened to notice something weird about the MAP sensor reading they were getting. I grabbed a photo of the scan tool connected to a 2008 Chevy HHR to demonstrate this.

(see fig. 3) 

“What do you notice about this MAP sensor? The flat portions of this pattern are when the engine is not running (atmospheric pressure). Since when do we display in/HG in absolute measurements and not gauge measurements? It used to be 26-28in/HG gauge pressure was good strong vacuum – in this case apparently, the company decided to reverse the scale and use 30in/HG as atmospheric pressure! This is an absolute value measurement, as opposed to the typical measurement we would use for vacuum; which is compensated for atmospheric pressure.

As you can see, this situation can represent substantial confusion for technicians who may not be prepared for it. Why would the company display this value like this? Arguably, most manufacturer tools have opted for a measurement in kilopascals – Absolute or kPA. This eliminates confusion, by putting absolute vacuum at 0kPA and atmospheric pressure (sea level) at 100kPA. This also makes it less confusing when entering into the boosted range (whether by supercharger or turbocharger) of the manifold pressure spectrum as the kPA scale can extend well beyond 300kPA for applications requiring more than 3 barometric units above atmospheric pressure in the manifold.

Case study 2: one company’s uncommon sense

In another case of lost in translation, and yet after 10 years in the industry, persistently something that makes me scratch my head. This type of jargon is what I look for when we are spending our precious budgetary amounts (of which there are few) on new scan tools as it indicates the level of confidence I can have in the quality of the tool. I took this on a 2007 Jeep Grand Cherokee with our yet another popular brand of scan tool.

(see fig. 4) 

“Since when does a percentage have anything less than a 0-100 range associated with it? This might be something that corrects itself when looking at the live data. Nevertheless it certainly does not inspire confidence in the quality of the tool and some of the background information that was exchanged and translated before it was displayed.”

In my quick 10 minutes with this scan tool I found a few other odd occurrences. One of them was a common occurrence in GM vehicles with narrow-band O2 sensors. As we can see in this photo the O2 sensors are all at 1.27V with the vehicle off, key on. GM used to display 450mV in this scenario on its tools. This value on GM scan tools was not actually sensor feedback (as the value is seen with the engine off as well) but a bias voltage GM used for circuit integrity checks before the vehicle went into closed loop. In this case I have no idea why all of them are pegged at 1.27V as the vehicle is not running and none of the O2s should be reading anywhere close to 1V, let alone over it. Same goes here for the range, is it 0-5 or 0-1V? Again, who knows?

(see fig. 5) 

“Back and forth the O2 goes – where it stops, nobody knows! Even the standard values seem to jive with what I would expect an O2 range to be, and yet the current reading seems to suggest otherwise.”


All scan tools are not bad; there are some great examples of good aftermarket tools as well as bad ones. It is still a good idea to approach them and evaluate them with a healthy dose of suspicion. Many lower-quality tools are on the market today with many of them becoming cheaper without external regulation or regard for the industry standards that have become common since the advent of OBD-II. Even some higher quality tools directly from the manufacturer frequently have minor bugs such as the ones discussed here if you look hard enough. Watching out for these bugs can help alleviate confusion, lost time, lost profit, or a lost mind when “that vehicle” enters your shop.