Making the throttle reliable...and how quickly can you kill a TPS?

[OldRanger]

EML at VIR on 6/15. Same operating condition as Summit. Coming out of the grid - first WOT.

Between Summit and VIR:
- I chose not to change out the Aug 2024 TPS on top. Too stubborn to accept it could simply be another failed TPS. But I did order a new one to have on hand.

- I rebuilt the connector for the top TPS after magnified images confirmed the female pins were likely a bit looser than new. Test drove a heat soaked engine, replicated the operating condition and the car failed that test. EML

- Sent my ITBs off for cleaning; the tech found a badly sticking #3. So I decided that was a most probable cause, and the sensor was actually doin its job

-I swapped out the entire throttle body assembly with a used set in good condition that I meticulously cleaned prior to install.

- the car passed a road test so I still didn’t change the TPS.

Two days ago the car went 5 sessions at VIR. I thought we were good. Then, Ben came back into the pits right after grid with an EML. I dropped in the old TPS, the original one from the original actuator I took out in 2024. Another long session. Probably 15 laps.

No EML.

Is it really possible that these EML codes are simply from failing Genuine BMW TPS (from FCP)?

I should test the wires. Anyone know which pins at the DME connector?

[OldRanger]

No need to test the wire. karter16 DS2 Tool enabled a comparison test of the suspect TPS.


How quickly do I seem to be killing TPS's? In just over one track season, this latest failure after about 22 months, one full track season, and 5,000+ miles before it became marginal enough to trigger EML.

Figuring this out using karter16’s MSS54 DS2 Tool. Huge thanks to him for building and sharing it. The tool let me log MSS54 live values directly to CSV, then I used AI to quickly analyze the logs and compare sensor behavior.

I logged:

• pwg1 / pwg2 — pedal position sensors
• wdk1 / wdk2 — throttle potentiometer positions
• edk_soll — throttle target

I ran an A/B/A test, key-on engine-off, sweeping the pedal from 0–100% and back.

A) Replacement TPS installed:
Throttle pots tracked cleanly.

• Max wdk1 vs wdk2 disagreement: ~1.9%
• Average: ~0.6%
• No samples over 3%

B) TPS that had been installed during the EML events reinstalled for comparison:
Pedal sensors still looked fine, but throttle-pot disagreement got much worse, especially in the mid/high range.

• Max wdk1 vs wdk2 disagreement: ~6.0%
• Average: ~1.3%
• 95th percentile: ~5.0%
• Over 100 samples above 3%

A) Replacement TPS reinstalled again:
Clean pattern returned.

• Max disagreement: ~1.7%
• Average: ~0.5%
• No samples over 3%

So the A/B/A result was pretty convincing:

Replacement TPS = clean
EML-event TPS = large throttle-pot plausibility disagreement
Replacement TPS back in = clean again

Given that the EML faults occurred with that TPS installed, and the disagreement followed that TPS when swapped back in, I’m comfortable calling it the cause of the EML events. It was not totally dead, which made it harder to diagnose, but it was producing a repeatable plausibility error pattern that the DME apparently did not like.

Big thanks to karter16. His DS2 Tool turned this from parts-cannon guessing into a clean data comparison.

[sapote]

Sounds like an interesting thread; this makes me thinking.

[OldRanger]

Sounds like an interesting thread; this makes me thinking.

Right - two years ago I was trying to cobble together a bench test with a multimeter. Now, I can use a bad ass tool Karter16 created, throw the data at AI and get this:

[sapote]

How quickly do I seem to be killing TPS's?

Not necessary a bad sensor, but the DME read the bad value caused by numerous reasons.
1. sensor has bad reference 5v or GND given by DME.
2. bad connections at the 3 pins on DME or at the sensor

You need to measure voltages at the sensor and at the DME 3 pins, not the resistance of the pot, as voltage includes the dependency of the 5v and GND reference given by the DME.

As about contactless sensor, here is one product people can select to fit the angle operating range and mechanical requirement:

https://www.ctscorp.com/Files/DataSheets/Position-Sensors/CTS-Position-Sensors-285N-285S-Series-Datasheet.pdf

[karter16]

Right - two years ago I was trying to cobble together a bench test with a multimeter. Now, I can use a bad ass tool Karter16 created, throw the data at AI and get this:

It would be useful to understand your observed variance between WDK1 and WDK2 as a function of WDK1.

The reason for this is that the %difference that is allowable is a characteristic curve with WDK1 as the input:



Depending on what WDK1 was at the time your 6% measured difference between the two might/might not be enough depending on the conditions. Remember that a pedal position (PWG) of 80% doesn't mean the throttle body is actually going to open by 80%. I suspect based on what you observed that the actual WDK1 value at the time would have been a lot lower.

[sapote]

As about contactless sensor, here is one product people can select to fit the angle operating range and mechanical requirement:
https://www.ctscorp.com/Files/DataSh...-Datasheet.pdf

Looking at the product ordering option, the 200* is the best option as our car has less than 90* rotation. So the voltage output will be 90/200 * 5v = [0v to 2.25v] range at best, and this means the output needs to be conditioned with an Opamp circuit to set the offset at 0.5v and a gain A about 2. The prototype will be 2 pots resistors to adjust the offset and the gain to match the factory [0.5v to 4.5v] total range. I can help with the Opamp circuit if someone want to play with this.

I assume the throttle rotate CCW vu from front.

[sapote]

As about why the front TPS seems to break down more often than the rear and the pedal sensor, it's a mystery. They are 4K pots so I assume they are made of carbon resistive tracks. I don't think the sensors linked to the throttle going bad quicker is due to heat and other environment factor, but they worn faster due to the position close-loop control on the throttle actuator. The sensor on the pedal last almost forever as it's an open loop and moved by your leg, set at command A, but the throttle controller to keep the throttle angle at A, it constantly doing the adjustment to fight the counter force from the moving air and the return spring, and the nature of a close-loop control always moving the shaft to zero out the position error between the command A and the feedback from the throttle sensor. For this the non-contact sensors on the engine should last much longer.

[OldRanger]

karter16...I'm a bit confused by channel labels in the DS2 Tool.

The DS2 Tool showed* wdk2 as the anomalous channel throughout my testing, but the suspect TPS was on the throttle shaft (upper operating rod). Per BMW, the throttle shaft sensor should be K_WDK1 — normal polarity, 0.5V closed to 4.5V open. That would mean the DS2 Tool's wdk2 label corresponds to the DME's internal K_WDK1, not K_WDK2.

Can you confirm how the DS2 Tool assigns wdk1 and wdk2 — throttle shaft or actuator motor?

*Edit: this is not a valid conclusion. At the time, I didn't fully understand the data.

[karter16]

karter16...I'm a bit confused by channel labels in the DS2 Tool.

The DS2 Tool showed wdk2 as the anomalous channel throughout my testing, but the suspect TPS was on the throttle shaft (upper operating rod). Per BMW, the throttle shaft sensor should be K_WDK1 — normal polarity, 0.5V closed to 4.5V open. That would mean the DS2 Tool's wdk2 label corresponds to the DME's internal K_WDK1, not K_WDK2.

Can you confirm how the DS2 Tool assigns wdk1 and wdk2 — throttle shaft or actuator motor?

DS2 tool takes the values from the relevant DS2 data frame as below:



And to show it aligns here's how that data frame is served by the DME:



Any variable that has a full-caps name originates from the 1801 A2L file which can be considered an authoritative source. So from a naming convention perspective I'm confident it's correct.

Curious how you're able to tell from the readings you got from DS2 Tool that wdk2 was the one at fault? is that based on AI's assessment that it looked non-linear? As I mentioned you can't assume that the relationship between PWG and WDK is linear, because it isn't :-) PWG from the pedal sensor is used to derive pwg_soll (target position) which is then in turn used to drive the throttle body.

[OldRanger]

Curious how you're able to tell from the readings you got from DS2 Tool that wdk2 was the one at fault? is that based on AI's assessment that it looked non-linear? As I mentioned you can't assume that the relationship between PWG and WDK is linear, because it isn't :-) PWG from the pedal sensor is used to derive pwg_soll (target position) which is then in turn used to drive the throttle body.

Fair question, and no — my conclusion that the TPS on the throttle operating rod was at fault had nothing to do with the curve looking non-linear. You’re right that PWG→WDK isn’t linear, but that was never the basis.

It comes down to a straight ‘good/suspect/good’ (A/B/A) comparison on the throttle operating rod sensor — the one I swapped out and back in.

Installed the known-good sensor, ran the test: clean. Pulled it, installed the suspect, re-ran: signal pulled away from the normal pattern at one specific part of the throttle range — high through the 76–96% zone, about a 6% split, enough to set 0xE6 / P1637. Then put the known-good sensor back and ran it a third time to rule out a data fluke — clean again, consistent.

That’s the tell. Only one thing changed across those three runs, and the 6% deviation showed up on exactly the run with the suspect TPS installed.

I can share some better charts, but the dark red bars in the chart from Claude are from the data that’s indicative of a problem.

[karter16]

Fair question, and no — my conclusion that the TPS on the throttle operation rod was at fault had nothing to do with the curve looking non-linear. You’re right that PWG→WDK isn’t linear, but that was never the basis.

It comes down to a straight ‘good/suspect/good’ (A/B/A) comparison on the throttle operating rod sensor — the one I swapped out and back in.

Installed the known-good sensor, ran the test: clean. Pulled it, installed the suspect, re-ran: signal pulled away from the normal pattern at one specific part of the throttle range — high through the 76–96% zone, about a 6% split, enough to set 0xE6 / P1637. Then put the known-good sensor back and ran it a third time to rule out a data fluke — clean again, consistent.

That’s the tell. Only one thing changed across those three runs, and the 6% deviation showed up on exactly the run with the suspect TPS installed.

I can share some better charts, but the dark red bars in the chart from Claude are from the data that’s indicative of a problem.

Yep for sure I understand the A-B-A, which proves that it's the throttle operating rod sensor that's the issue - definitely agree with you there on the solution. I also agree with you that based on BMW's documentation it seems they're suggesting that WDK1 is the sensor on the throttle operating rod.

I guess I more meant what makes you think that the DS2 Tool is suggesting that WDK2 is the problem? As far as I can see all you'd be able to tell from logging the live values is that WDK1 and WDK2 didn't agree when the bad sensor was installed, not which one was at fault?

[OldRanger]

I guess I more meant what makes you think that the DS2 Tool is suggesting that WDK2 is the problem? As far as I can see all you'd be able to tell from logging the live values is that WDK1 and WDK2 didn't agree when the bad sensor was installed, not which one was at fault?

Thinking more carefully, getting caught up with your point: the DS2 Tool as is, is not capable of suggesting a specific sensor (e.g., WDK2 is the problem). This isn't news to you, or sapote , and I appreciate the grace/patience while I get better informed.

My first observation that pointed to a bad TPS surfaced while I watched the Live Values. I could see that the two Throttle potentiometers (wdk1 and wdk2) did NOT agree. I also noticed wdk2 was the outlier when comparing live values with wdk1 and edk_soll.

I misunderstood 'edk_soll' in the process of looking optimistically at the data in logs as a diagnostic tool. My first pass at the data with AI, I didn't first inform it on the definition of edk_soll (electronic throttle target), so I jumped to a false conclusion.

I understand now, and will go back to github and optimistically/ignoratly request a new feature in Electronic Throttle Control Diagnostics. Something like: provide numeric live values for wdk1 and wdk2 on the raw EGAS actuation screen, updating as the request slider moves. That alone lets someone step through a suspect band and read both sensors at each position by hand. Nice-to-have if it's easy: raw voltage in addition to scaled %, since a worn track or wiper dropout is a fine feature the filtered % can smooth over — and the ability to log those values during raw actuation, which would let the tool identify a faulty channel from data on its own rather than relying on a physical sensor swap.

[karter16]

and I appreciate the grace/patience while I get better informed.

We're all learning as we go and one of the truly excellent things about this forum is how willing everyone is to share what they've learned and help others respectfully :-)

I understand now, and will go back to github and optimistically/ignoratly request a new feature in Electronic Throttle Control Diagnostics. Something like: provide numeric live values for wdk1 and wdk2 on the raw EGAS actuation screen, updating as the request slider moves. That alone lets someone step through a suspect band and read both sensors at each position by hand. Nice-to-have if it's easy: raw voltage in addition to scaled %, since a worn track or wiper dropout is a fine feature the filtered % can smooth over — and the ability to log those values during raw actuation, which would let the tool identify a faulty channel from data on its own rather than relying on a physical sensor swap.

This is an excellent idea - and should definitely be possible to do - I'll get onto it.

I agree that the observed behaviour and BMW's definition of WDK1 as the throttle operating rod sensor don't seem to line up, so am curious to see what's going on here. I wonder if the documentation and reality don't line up. (actually, which documentation have you been referring to that identifies which is which (wdk1 and wdk2)?

[OldRanger]

I wonder if the documentation and reality don't line up. (actually, which documentation have you been referring to that identifies which is which (wdk1 and wdk2)?

No single document spells it out directly, but the mapping is well supported by three sources:

1. S54 air-management training — identifies the throttle-shaft pot as the rising sensor (closed ~0.5 V to full open ~4.5 V) and the actuator-shaft feedback pot as the falling sensor (closed ~4.5 V to full open ~0.5 V). BMW states the two operate inversely with throttle actuation.
2. PDR module — S54-specific WDK2 handling, with the channels adapted separately.
3. Calibration (2701/hw0401) — a WDK2-only inverse flag, no WDK1 equivalent. Since the firmware only needs to flag the channel that's physically inverted, that flag sitting on WDK2 alone is what pins it.

So the clean mapping is: WDK1 = front/throttle-shaft/operating-rod TPS, and WDK2 = rear/actuator-side TPS.