Shortly after the birth of the Internet, a few enterprising technicians saw an opportunity to network and learn from one another, going beyond the limitations of their geographical locations. Today, there are numerous forums where techs can share their knowledge and grow their skills. One such forum that has been around a long time is the International Automotive Technicians Network (www.iatn.org). Every three months, the staff at iATN picks exceptional postings and shares them in a newsletter, and that is where I found the following gems. Thanks to iATN and, of course, to the technicians who made these posts for allowing me to share them with all of you.
Finding a parasitic draw without a meter
(Shared with permission of the author Roger Suranyi. Roger works for Namao Automotive Repair located in Namao, Alberta, Canada.)
I read a while back about thermal cameras and ended up buying a FLIR e5 thermal camera a year or so ago. We have used it mostly for bearings on drive lines and engines. I remembered reading that someone was using it for battery draws, and I actually used it twice in the last couple weeks for draws.
I usually make sure the vehicle has sat overnight so it’s cold and then give it a quick look with the camera. The alternator stuck right out. I had a 2008 Dodge 5500 that has a dump deck and is highly modified for the oil field. I measured a 90 ma (milliamp) to 100 ma draw. I decided to get the camera the out and within about five minutes, I had my draw [auto shut down for engine over rev limiter]. Figure 1 shows an area of heat located just under the dash on the driver’s side of the truck. The heat is caused by the current flow through the rev limiter. I’m not suggesting you go out and buy one because it’s going to be the “go to” tool; I must admit we have only used it a handful of times. But this is the one time I could say it definitely helped.
Solving GM communications concerns
(The next two tips are shared with the permission of author James Avery. James is a technician with Stingray Chevrolet in Plant City, Fla.)
Case study: Corvette Class 2 communications failure
A 2011 Corvette came in yesterday with the complaint that the key fob was damaged by closing it in the door, and it wouldn't work at times. The customer had only one fob and wanted it replaced with a new one. I pulled a new fob from
parts and tried to program it to replace the No. 1 fob that was damaged. If you don't program a new fob on a Corvette to replace either the existing No. 1 or No. 2 fob, it will program into position No. 3. It will still function normally, but personalization functions will not be enabled.
The new fob would not program, as the module would not respond. Doing a quick scan check, I saw all the Class 2 modules were unable to communicate, although all the GMLAN modules communicated normally. The high-speed modules all had multiple U codes set as current and history.
My first diagnostic step was to check the Class 2 bus resistance. I didn't see a problem inhibiting communication there. How about the bus voltage (see Figure 2)?
OK. Here's our problem: excessive voltage on the bus, but from where? Usually a module leaking voltage onto the bus causes this, but which one? Pondering that question while sitting in the driver’s seat, scan tool in hand, I looked slightly to the right and got my clue.
An aftermarket Pioneer Nav radio has been installed. We have many problems with aftermarket components either causing communication problems or key-off draws. Since the JX 208 bus connector is easily accessible under the right front access panel, I pulled the comb, opening half the bus that the radio was on. That restored communications with all the Class 2 modules on the JX205 bus connector. Assuming a radio fault, I backed out terminal C, leading to the radio, from the JX208 connector and reinstalled the comb. Bus voltage instantly returned to normal. All communications were restored except for the radio, and I was able to program the new key fob without a problem.
Case study: An unusual problem on a 2014 Silverado
Today, a 2014 Silverado was towed in. The customer had several concerns including; SES light on, power steering inoperative at times, ABS light on, all problems come and go. When I got in the truck, the Service Power Steering message was on, the steering had no assist, the SES and ABS and Brake lights were on. As soon as I moved the truck, the steering worked normally and I drove it inside. From the multiple complaints, it seemed to be a major communication failure. I checked for codes first and saw this laundry list (see Figure 3).
Quite a few codes, huh? After checking the module status on the bus, I wanted to take a look at the bus activity (shown in Figure 4).
Well, we've got some obvious problems. The HMI is only on the high-speed bus, but the EBCM is also a gateway module for the HS Expansion Bus. Is this bus active? Rather than a pattern I would normally expect, all I saw was a flat line and you know what flat lines mean, right?
UGH....nobody home.
Checking the module list on this bus, I found no EBCM here either. I was looking for EBCM communication on GDS2 and could not communicate with the module. I turned the key off and communication was established with both the missing EBCM
and the HMI module for about one minute then they went silent again. I turned the key back on and still no communication. Let's try something. I turned off the key and communications were established again for about one minute. Interesting! I wonder what happens to the HSGMLAN when the key is rotated off (see Figure 5).
Well, isn't that cute. Normal conditions with the key cycled off. When the modules power down, all communication is lost as expected. What's the next step? Well, there are some clues to look at:
Clue 1 — On the high speed module list, 2 modules are
missing but the heading says "Control Module Not Awake."
Clue 2 — There is no communication on the expansion bus as
the EBCM is down. Since it acts as the gateway module, the
bus cannot communicate without the EBCM.
Clue 3 — The PSCM has set U0299-00 High Speed Communication
Enable Circuit as current.
Clue 4 — When the key is cycled off, communication is restored and the High Speed Bus waveform returns to normal as all modules are now communicating.
OK, time to use our most important tool, the one between our ears, and analyze the failure. Two modules are not communicating and the data tool tells us that they are not awake. The ECM says that a problem exists in the data communication enable
circuit. GM low-speed modules need only a 12-volt spike on the data line to awaken them, but high speed modules are different. They need a dedicated 12-volt enable line from the BCM to awaken. This should be a constant 12-volt feed with the key on, but our modules only awaken with the key cycled off. Why?
How do we find out why this is happening? I went to the data enable circuit for the EBCM and the HMI module at the BCM X4 connector, pin 23. Back-probing the pin, with the key turned on, there is a very short 12-volt spike, then no voltage. When the key is turned off, there is a steady 12-volt feed until the BCM powers down as seen on the HSLAN waveform. Pin 22 is the communication-enable circuit for the TCCM, ECM and ATC. Checking this pin, when the key is cycled on, a steady 12-volt output is seen, as expected.
Maybe the signal is being pulled down — unlikely but I can prove it easily. I swapped pin 23 and 22 in the X4 connector. Now, with key on, I have normal communication with the EBCM, but no communication with the ECM until the key is turned off. This must therefore be an internal BCM failure. A new BCM solved the problem and everything is fine now.
This shows why, with network communication issues, it's very important not to jump in too quickly. Look for the clues first and analyze the failure before replacing components.
Do you have a story like these you want to share with? That’s one of the goals of this column! Email your ideas to me at [email protected]. See you next month!
