Diagnose with Data
Here’s a great example of how combining technology with experience and judgment makes for a solid diagnosis and repair.
Rex Wheeler of Bud’s Transmission in Marysville, Wash., and a member of Transmission Rebuilders Network International Inc., demonstrated his skill in this regard and has allowed us to share his findings with you. Rex’s problem was a 2000 Olds Bravada with 60,000 miles and a customer complaint of a “double downshift” while increasing speed from a steady cruise or applying more throttle while going up a hill. Although Rex has seen excessive slip and 1870 codes in 4L60-E units, he observed that this unit felt like it would actually start to unlock, then start to lock up, then release. Tip of the hat No. 1 to Rex at this point. He paid attention to the customer’s specifics and test-drove the vehicle with an open mind, ready to observe what happened and gather more information. Our tip of the hat No. 2: Rex not only has the capability to do data recordings, but took the time to do them and then analyze the information before proceeding.
Some folks have not had an opportunity to use data recordings as a diagnostic tool. When you first start looking at recordings, there appears to be so much data that it’s hard to find the answers. There are a few techniques we have found very useful in getting the information we need. The graphs below show the readings used to verify the complaint and diagnose the problem.
 |
When dealing with recordings and a customer complaint, you should always start with a look at RPM. If you can see
something significant enough to match what the customer would actually feel, keep going. There may be many input and
output signals jumping around all over the page but what you want to look at is when the customer “felt” the problem and RPM change will often help you find the time to narrow in on.
Draw a timeline or use an onscreen moveable timeline. On this graph, just your eye could tell you the customer felt the
double bump (RPM), and that TCC slip appears to be the cause. We added a timeline to both the left- and right-hand
columns of the graph to show a common point in time, indexed by the start of the slip rate change. Using the line, we can see that what the customer felt was caused by TCC slip rate double spike initially triggered by a TCC duty cycle change. Using the line as a starting point, we can look at what caused what, and when. In this case, we do not see anything commanding the double bump. Duty cycle reduction is a slow, even ramp down but the slip rate response was bumpy. The timeline also points out that this problem was not part of actually unlocking the converter. That clearly occurred later (TCC Enable goes to off). This EC3 unit was trying to add some controlled slip when the problem occurred.
With all that information on his side, Rex knew the TCC isolator/regulator valve would be responding to the duty cycle change and should have duplicated the gradual reduction of apply pressure and increasing slip rate the signal commanded.
 |
The graphs above show that his diagnosis and repair were on the money. After installing the Sonnax TCC regulator valve kit 77754-04K, a smoothly ramping down reduction of the TCC duty cycle creates a smooth increase in slip. Full unlock of the converter occurs shortly after, with TPS voltage at that point clearly showing why.
One more tip on graphs and timelines. Don’t worry about minor irregularities that may appear as either a slight delay in a response or even a response appearing to occur just ahead of a command. Computers are fast, but they still read only one signal at a time, reading each one in turn, very quickly, limited in speed more by the data links they use between controllers. Then, when you take a recording, the information is often transmitted through slower communications and links, and gets converted into a graph display by a computer program. Depending on the time duration spread of your graph, irregularities will appear. Don’t worry about an exact line-up of time. In reality, no two readings on the graph represent signal readings at exactly the same instant, but are lined up closely enough for you to trace a chain of events and come up with a solution.
One final suggestion for making graphs more useful is to consider what things to record, or at least what things to display. Once again, Rex made great choices. We left two of his displays out, for space reasons. His original graph showed what you see, plus Break Switch and Trans Temp signal. He wisely included things that could have triggered what was potentially a lockup-related issue.
One suggestion is to remove TPS percentage. TPS voltage should always be a part of the graph but the percentage display is just the computer doing a calculation of the same voltage reading to display it as a percentage. Rather than duplicating this information, we would substitute VSS signal for the TPS percentage. That helps monitor the conditions around the reported error better and makes duplicating the problem again on a road test easier.
The key idea here is to set up your test to get the information that define the conditions for you and also provide data on
changes in commands and monitoring of the responses to those commands. A common mistake on recordings is to include and display too many signals. The answer you are looking for is still there, but may be harder to find. You can easily make it a needle in the haystack by adding too much data to the mix.
Related Units
While Sonnax makes every effort to ensure the accuracy of technical articles at time of publication, we assume no liability for inaccuracies or for information which may become outdated or obsolete over time.