heinzboehmer's 2002 Topaz 6MT Coupe

[karter16]

Wait what.

I believe you, but how does the DME know what the position of the valve is?

I don't think it really needs to - the current duty cycle gives a relative position of sorts, but really the idle controller is a fancy rpm-based feedback loop.

If RPM below target, increase duty cycle proportionally, evaluate response, continue to adjust, etc.

That's a simplified example, target air mass calculations and all that are in there too, but all inferred from the duty cycle as far as I can tell.

[heinzboehmer]

It's definitely fine-grained. It's controlled via a 100hz inverse duty cycle.

Wait what.

I believe you, but how does the DME know what the position of the valve is?

[karter16]

Thanks for sacrificing this to show us how it's built - super interesting and good to understand how it works.

Kinda crazy to think that this thing is an on/off switch. I always thought there was more fine grained control involved in the idle air circuit, but I guess not. Again, TIS helps confirm this with the descriptions in the DME pinout:

It's definitely fine-grained. It's controlled via a 100hz inverse duty cycle.

[heinzboehmer]

Also, I couldn't help myself. This is what an ICV looks like on the inside:







I had to cheat a bit at this point. There's a needle roller bearing at the very end of the casting that supports the top of the shaft that runs through the center of the rotor. But there's also another, bigger ball bearing that's held captive with this retainer:




The correct way to take this apart would be to insert a sleeve-like tool in between the casting and the rotor to push this retainer out of the way, then pull the rotor out. I don't have this tool and I was unable to get a good grip on the rotor with pliers, so I went the caveman route and cut the top off of the casting. With the shaft exposed, it was pretty easy to tap out.





Worth going into a bit of detail about the electronics as well. In retrospect, what I learned is obvious, but I was a bit blinded by an assumption I made a long time ago. The first time I saw the three pin connector, I immediately assumed that this was a brushless motor and I guess that idea never left my mind. But if you look closely at the stator, you'll see that there's actually only one continuous winding, with a tap in the middle:




Looks like this is designed this way so that you don't need to flip the polarity of the voltage going to the actuator to reverse its direction. Instead, you have a common tap in the middle of the winding that you can hold at a static voltage and then actuate the rotor by pulling up/down the other two pins. There's a bit of SW overhead involved with this approach to ensure you don't try to rotate it both directions at once, but it's nothing compared to the HW overhead that would be needed to reverse the polarity of the current going through the stator. I like it.

Quick look at TIS confirms this. Pin 2 goes straight to fuse 2 in the engine bay. Pins 1 and 3 go to the DME and get pulled down to ground when it wants to spin it one direction or the other.

If you look closely at the bottom of the casting, you'll see a "track" that a pin in the rotor rides in. This limits the rotor's range of motion, so that all the DME needs to do is energize it one way or another. Kinda crazy to think that this thing is an on/off switch. I always thought there was more fine grained control involved in the idle air circuit, but I guess not. Again, TIS helps confirm this with the descriptions in the DME pinout:



I guess, technically, the DME could hold the valve in some middle state between open and closed by quickly alternating what pin it's driving, but there's no position feedback anywhere on this thing, so that sounds highly unlikely. It would either need to guess the current position or rely on feedback from the MAF/MAP, which would nowhere near fast enough for this to work reliably.

I also measured the resistance of each section of the winding and got 11.0 Ω for one and 12.3 Ω for the other. For completeness, I hit the stator with a torch and measured again. Resistance went up as expected, but unfortunately, I found no faults in the wiring related to heat. Nothing really stands out to me here.

Honestly, at this point, it's looking like this thing is working exactly as expected. It's designed pretty robustly, so not surprised these don't ever go bad (like George Hill was saying).


There were two things that caught my eye though.

The first one I noticed before even taking it apart:



Those streaks make me wonder if some sand or similar got in there and messed up the bore. Could also be causing the valve to sporadically stick.

The second thing I noticed was a bit more confusing:

If I turn the rotor all the way to it's fully closed position, it WAY overshoots and lets a bunch of air through. This is what it looks like when it's held against its "fully closed" limit:



Note that the valve is turning more than it should and not less. If the face of it were longer, it would still be closed. I probably should have taken a video of this, since it's almost impossible to show in a static image, but just trust me on this one.

I don't know exactly how this valve is blended with the throttle bodies, but I can see why the DME would freak out if it's expecting the valve to be fully closed, but it's actually 1/3 open. I'll have to check if the new part does this same thing or not.

In a previous picture, you can see small dents at both ends of the feature in the casing that limits the valve's rotation, but I'm not convinced that those account for this in its entirety. Looks to me like the valve overshoots by more than the size of those dents, but it's hard to tell. Surprisingly, I saw absolutely no signs of wear on the pin that slams against these limits.

So, I've learned how this thing works, but I'm still unsure if it's actually broken. I mean, it's broken now, but maybe it wasn't broken before I started poking at it

[karter16]

sweet - all good. I've had a pretty good go through the code, there's a significant number of LLS (idle sync controller) errors that will trigger an EGAS emergency mode, but not all. confirmed as well that this logic is significantly different on the CSL specifically as it doesn't have the HFM (MAF sensor) to fall back on.

[heinzboehmer]

Do you have the details of the code? I'm keen to see if there's any differences in the details of the code between the time it triggered limp mode and the time it didn't.

Ah, good call. I didn't clear the latest code, so don't have it saved in your tool's history at the moment. I'll need to read it later since the car is taken apart and I don't want to trigger false codes just from having things unplugged.

[karter16]

To make this more confusing, I managed to trigger just the ICV code on the last test drive and got no limp mode

Do you have the details of the code? I'm keen to see if there's any differences in the details of the code between the time it triggered limp mode and the time it didn't.

[heinzboehmer]

It's going to take a while to go through cause its heckin complex but just had a look at the EGAS safety module stuff and the CSL version is different to standard M3 in that it takes (what I've named) rf_diag_st and rf_diag_sk_st as inputs. These are derived from a complicated lookup table against a bunch of error variables (including the idle speed controller ones) to work out what the failure mode is.

I'll trace it later when I have time, but my guess would be it's the ICV code that triggered limp home mode.

To make this more confusing, I managed to trigger just the ICV code on the last test drive and got no limp mode

[karter16]

Maybe a question for karter16 I know there are faults that have to set twice before the CEL illuminates, are there situations were the DME needs a 2x occurrence before storing the fault? Could that be why the fault has a frequency of 0?

FWIW it's not always a 2x occurrence. The thresholds for triggering and aging out, as well as the increment values each time the error is reported is configured in the DTC table in the tune file:

e.g.



In this example (ICV code) fv_max is the count that has to be reached in order to be considered "present". In this case that is 0x14 (decimal 20). fv_inc defines the amount to increment the counter by each time the error is reported by the software. (in this case 5). So this error would have to be reported 4 times before triggering an actual code.

[karter16]

It's going to take a while to go through cause its heckin complex but just had a look at the EGAS safety module stuff and the CSL version is different to standard M3 in that it takes (what I've named) rf_diag_st and rf_diag_sk_st as inputs. These are derived from a complicated lookup table against a bunch of error variables (including the idle speed controller ones) to work out what the failure mode is.

I'll trace it later when I have time, but my guess would be it's the ICV code that triggered limp home mode.

[karter16]

Maybe a question for karter16 I know there are faults that have to set twice before the CEL illuminates, are there situations were the DME needs a 2x occurrence before storing the fault? Could that be why the fault has a frequency of 0?

Yeah exactly that is why I said the shadow code isn't a problem, I thought that it had to trip the threshold before triggering the CEL and limp home mode, but possibly there are some failure modes that invoke limp home mode immediately?

[George Hill]

Maybe a question for karter16 I know there are faults that have to set twice before the CEL illuminates, are there situations were the DME needs a 2x occurrence before storing the fault? Could that be why the fault has a frequency of 0?

[karter16]

Hmm, but then why did the car go into limp mode? I don't think any of the active codes would have caused it...

Ummmm okay fair point. I'm going to do some digging.

[heinzboehmer]

Never seen a bad ICV myself, I have seen a bad aftermarket one though, fixed with a used genuine one.

Keep us posted if it was the ICV.

Will do! Agreed that it's a weird failure mode. Maybe it's a wiring or DME issue? Guess I'll find out soon.

The shadow codes are probably there from when you replaced the TPS and connected the MAP sensor. Note that the "description" provided is a general one for the code in question, it's the other fields like "Error Type Interpretation" that give specifics of the error.

Oh duh, I should have used the interpretation field instead. Good to know.

If the frequency is zero and it hasn't emerged as an actual code you can ignore it :-)

Hmm, but then why did the car go into limp mode? I don't think any of the active codes would have caused it...

Last time the TPSs or MAP were disconnected (on purpose) was before the last time I cleared error codes. I'm pretty sure of that since I was just recently messing with your SW tool

[karter16]

The shadow codes are tripping me out though. Frequencies are 0, yet they're still reported and triggered limp mode? TPSs are also all pretty new (maybe 10k mi old?).

The shadow codes are probably there from when you replaced the TPS and connected the MAP sensor. Note that the "description" provided is a general one for the code in question, it's the other fields like "Error Type Interpretation" that give specifics of the error. If the frequency is zero and it hasn't emerged as an actual code you can ignore it :-)