This is a story of how overlooking a simple setting, cost me time today on a diagnosis. Sometimes saying something out loud to a fellow industry professional is all you need to get you going in the right direction.
This job was a simple, routine job. Customer drove their 2007 Ford Expedition somewhere and wouldn’t restart. No previous starting issues were noted by customer. The key looked original but in good condition, no different keys were introduced at the time of the no start.
It acted like the starter motor was bad. I begin with a starter system diag because that's a quick, simple check. This starter control circuit is a basic 4 pin relay with two power inputs, one control wire and one to power the starter solenoid....I had all but the command from the PCM. At this point it’s looking like I should have taken the other approach that would have started with scan for codes first approach. I had noted that the IC would respond as expected, nothing out of the ordinary. Turn the key on and all bulbs check, turn the key and no immobilizer light now. It was there during the bulb check. There wasn’t enough evidence yet to say go there.
Scan revealed a U2510. This is described as invalid security received stored in the IC. No other codes in other modules. This is the one gambling men would bet on finding.
I used a halo testing ring to look for signal from the Transceiver unit to the coil in the key chip. The light on the halo board flashed. I tested the key chip. I was able to identify the type of chip and it’s ID number using a vvdi xhorse tool. So keys tests out good. The signal from the IC successfully reached the Transceiver unit and it successfully sent out a signal. The transceiver unit isn’t dead. It just failed to send a return message. The lack of return message is interpreted as invalid and the security system won’t allow the PCM to command the relay.
Typical Ford PATS system, key with a chip. The PCM grounds the starter relay after receiving the the go ahead from the IC. In this case, the security is in the IC. The IC checks for the correct message back on the RX wire between the IC and Transceiver after it sends out a data packet to the transceiver unit on the TX wire. Common failed part is the one we need to test and prove. In this case it is the Transceiver unit. So, 4 wires to test under the steering column covers, easy enough to get into, just 3 screws and some clips at the clam shell covers. It's a quick test, one power that should be key on power, a ground, and the TX and RX wires. Test reveals power and ground are there, scope voltage tested between the power and ground pins at 14 volts. Note, I have my battery maintainer on vehicle entire time.
In testing the TX and RX lines using both channels on my Scope meter, the RX has a step in voltage with key cycling to 11 volts and the TX has a change of voltage only it is near battery voltage. I don’t see the data packet but I do see a change of state in voltage. This is not the expected outcome and also where I got tripped up. If I had checked or changed the voltage scale it would have jumped out as the expected pattern for a failed response from the Transceiver unit.
The job was a basic as it gets immobilizer TX /RX scope job. I wasn’t seeing command and receive, only voltage changes, with key movement on the transceiver halo unit.
I decide to reaffirm my understanding of this system by calling on a fellow industry professional that I respect and can rely on to answer his phone when I need him, Keith Perkins. After my conversation I decide to take another look at the detail of my scope pattern. This is the point I realize my settings were off.
The issue was me and my use or misuse of a basic scope function. The scope I grabbed was red and a pro model early Snapon 2 channel Scope meter. It is plenty good at seeing this type of signal. It isn’t as pretty as the Pico stuff but it’s quick. Diag is about speed as well as final product. My mistake was not looking at my time base. I had the scope set at 10 seconds not the 1-2 seconds that would have been able to see the detail for that brief moment when it happened. The same thing would happen even if I was using my Pico. It looked like straight switch of voltage. The voltages changed but not on off, more like a step. I saw change with key movement.
Other things were checked. Starter with a jumper wire across the power to starter pins in the relay. Engine cranks strong and rhythmic. Sounds perfect.
New part from Ford installed. Retested with scope settings correct and there is a clear signal pulse on the TX line with a voltage step. Shortly after the Transceiver unit returns a clear response pulse and vehicle starts.
I’m sure others have different approach to start this one with but the biggest lesson here was to not get stuck on a scope setting issue. This isn’t my go to scope. My go to is the Pico but I felt this was a good one to use the quick scope on. When I’m using my Pico, I have a habit of running through the settings in a methodical pattern almost every time. The Snap-on settings adjustments are clumsy. They were a great way to do it 20 years ago but not so much with today’s technology. A full power Pico tablet would sell huge.
This is also a test most mobile guys are using the new pocket size scope that Aeswave sells. I want one but other holes in the equipment needs are bigger, so not yet. If I didn’t have the ability to scope it would be one of the first I would recommend. I have had my vantage pro for 15 years or so. It covers the easy to interpret stuff well enough. If I were in the position of needing that function filled, like most not "gray in the hair" yet techs, it would be a no brainer.
No matter what scope you use if you fail to use the settings right it’s not going to show you what you need to see. The scan data can point you toward the part that needs to be replaced but in the end the scope needs to be used to properly diagnose what part. In this case I did use scan data to help guide me. I’m sorry I didn’t take perfect notes this time. I can’t give specific pids and their values. If my gut feeling along with experience said come back to it if this part isn’t the problem. Again, I’m sure other approaches are preferred for other guys.
Nice post Justin, thank you! Craig Copeland and I did some experiments on the Transit that he drives when I visited him. It was a lot of fun. I wished we did a better job of documenting our finds but we didn't. It just means that we'll have to get together and do the experiment again. We basically stimulated a few different key fault scenarios while scoping the TX & RX lines. The results
I had the same symptom on an F150 a coupla week ago. I loaded power and ground at the transceiver and saw some activity on both comm lines with my old Vantage on waveform viewer. I found that doing some wiggling of the transceiver restored it's function momentarily. That was enough for me to condemn the device.
Hi Justin, I think we tend to beat ourselves up with the would have, should have, could have. It is easy to make simple mistakes that take us down the rabbit hole. At the end of the day you found the fault. We are so conditioned to think that we have to be perfect. Our customers call us because they either lack the time or the skills to do what we do. Our time is worth paying for. Even if it
While all lessons learned are valuable, I must be missing something about the symptom/diagnostics. The DTC U2510 is related to a mismatch in the PCM and IC hardware ID's and this is corrected by a parameter reset. The repair you are describing would be more related to a B160# dtc. B160# dtc's are related to the reading of the chip (no read, invalid format, unprogrammed key) If the IC did not
I didn’t mention it but a parameter reset was one of the first things I tried. There was only one other code found it was a B code for a door position malfunction in the rear HVAC system. I chose to ignore that in this case.