1FZ Can I trust TPS OBD-II value during re-learn? (1 Viewer)

This site may earn a commission from merchant affiliate
links, including eBay, Amazon, Skimlinks, and others.

acy76

SILVER Star
Joined
May 2, 2007
Threads
32
Messages
237
Location
Twin Cities, MN
Hi all--Chasing a P0125 on my 1996 LX 450. It was intermittent, then the other week it became permanent and the truck started to run very rich (by smell), rough, missing, etc. Checked upstream O2, found signal wire hanging by a corroded thread, replaced the harness side connector.

Started it up, ran worse than before, but no engine light nor any stored codes any longer. Reading the posts here, I disconnected the battery for an hour or so to trigger a re-learn. Still runs like crap after a couple starts, missing, short-term fuel trim at -19% or so, etc.

I checked the data stream coming from the TPS and it is at about 24% at idle, which is obviously out of spec. Should I expect this during a re-learn? Should I adjust now or wait until I (try to) drive it a bit so the ECU can catch up? Throttle does not seem sticky. Did not check for carbon in the throttle body yet, but mainly wondering at the moment if I should be expecting the TPS values to be unreliable during re-learn.

Thanks for any insight.
 
Last edited:
The TPS signal is just a signal, its not something that is learned.

I'd adjust the TPS to spec per the FSM, unplug the battery to reset everything and then go from there.
 
@ZackR Thanks for the info. Makes complete sense.

Full disclosure for the question is I was hoping to take the shortcut and use live data to set the TPS as several here have recommended. If the scan tool is receiving the ECU's interpretation and not (I assume?) the raw signal, that method could be inaccurate if the ECU hasn't configured itself. This whole "learning" procedure is new to me, so I may be making assumptions I should not.

Physical adjustment per the FSM should avoid all this of course.
 
From what I'm seeing in the FSM you can use either a multimeter or the OBD2 scan tool to test the TPS.
 
From what I'm seeing in the FSM you can use either a multimeter or the OBD2 scan tool to test the TPS.
I must have missed the OBD2 part in there--I do see the meter/feeler gauge method however. At this point then it seems like it is worth a try to use the live data, it will either work or it won't.
 
...and doesn't take an hour.
 
You really need to remove the sensor to inspect it. And don't discount the troubleshooting matrix. The first listed probable root cause is the circuit, not the sensor. All three possible root causes should be considered.
1701996023409.png

1701995761980.png

1701995800289.png

1701995892225.png

1701995938022.png
 
Word to the wise, it's best to order two replacement screws before you remove the throttle body and try to remove the TPS. The screws are really small and usually stuck, and have to be removed with a screwdriver. This means there is a high likelihood of stripping at least one of the heads, rendering the screw(s) unusable.
1701996158321.png
 
Thanks all, much appreciated.

You really need to remove the sensor to inspect it. And don't discount the troubleshooting matrix. The first listed probable root cause is the circuit, not the sensor. All three possible root causes should be considered.
Fair points. I freely admit to trying to short-cut this a bit, the weather is not going to hold out much longer here and I do not have a heated shop.

It suffered from a slightly high idle before the O2 code, and I happened to see the TPS value on the scan tool, and then looked at short-term trim pulling a lot of fuel, and thought maybe adjusting the TPS would get me to a better place.

Speaking of troubleshooting procedure, I have no check engine light and no codes any longer, but I probably ought to verify everything with the upstream O2 situation first. I did not replace that sensor yet because I found the wiring issue once I inspected it--plus, it is rusty and I know it will be a frustrating job. Considering replacement as a first step now, though.

Or maybe more re-learn time will bring it back to where it was before, not perfect but tolerable.
 
The ECM can't learn anything. It has no reprogrammable functions. It is capable of storing and clearing error codes and nothing more.

I wasn't trying to browbeat you, just making an observation. I understand quite well how limited your ability to work in the winter without a heated shop can be. It sucks. Good luck with the Easter egg hunt.
 
The ECM can't learn anything. It has no reprogrammable functions. It is capable of storing and clearing error codes and nothing more.

I wasn't trying to browbeat you, just making an observation. I understand quite well how limited your ability to work in the winter without a heated shop can be. It sucks. Good luck with the Easter egg hunt.
I may have been overly terse in my response, this medium ain't perfect. I appreciate your input, and reminders to stay the diagnostic course are good things to hear especially when there is a risk of rushing the job and doing sloppy work. No offense intended nor taken.

I was parroting a term I've seen used on the forum with the "re-learning" reference. Seems that one definition of "learning" in this case would be dynamic logic adjustments, which I also would not expect from this system. More like re-building cached data? Thinking of long-term fuel trim, or other similar values if they exist?

To your point, though, I am realizing what I initially asked is likely academic and I agree that the flowcharts are where I ought to be when solving a concrete problem.
 
Don't worry about it. I There are numerous references here, and elsewere, to learning computers - 80s don't have them. The maps are static. There is a limp function built in to the controller code, but it's static, too. The FSM/EWD describe everything in detail.
 
Don't worry about it. I There are numerous references here, and elsewere, to learning computers - 80s don't have them. The maps are static. There is a limp function built in to the controller code, but it's static, too. The FSM/EWD describe everything in detail.
I have used the term "relearn" many times. While the base maps that the ECU uses are static, after a reset, the ECU has to "relearn" the individual sensor inputs as that information has been cleared from memory along with any stored trouble codes. The ECU makes a comparison to the sensor inputs against its base maps. Anything outside the base map "window" triggers a fault code.
Perhaps the term "relearn" is incorrect, but it works in my twisted, old and crusty mind.
 
I have used the term "relearn" many times. While the base maps that the ECU uses are static, after a reset, the ECU has to "relearn" the individual sensor inputs as that information has been cleared from memory along with any stored trouble codes. The ECU makes a comparison to the sensor inputs against its base maps. Anything outside the base map "window" triggers a fault code.
Perhaps the term "relearn" is incorrect, but it works in my twisted, old and crusty mind.
This is in line with my understanding, and why I was curious initially whether OBD2 data can be trusted while the ECU is doing its calibrations (or whatever).
 

Users who are viewing this thread

Back
Top Bottom