Auto-zero TPS (again)

[subwoofer]

I think it was disabled at some point since it produced strange results? At least it does not appear to be functional in my installation.

Normally, I wouldn't be bothered by the odd negative number, but due to my AFR table using TPS for load the EGO goes open loop at idle if the TPS happens to end up negative. There is no way to remove the lower load limit in the EGO dialog and "Active above" load cannot be set below 0.

[AbatelliCristian]

I've also seen the same problem in Alphan ....

[subwoofer]

My AFR target table is Alpha-N, so it is the same problem.

[elaw]

I don't know if it would be considered too much of a "hack" but the problem could be solved with a very easy code change.

Just change (around line 85 in ms3_ego.c):

Code: Select all

    if ((outpc.rpm < ram4.RPMOXLimit) ||
        (outpc.engine & (ENGINE_TPSACC | ENGINE_TPSDEC | ENGINE_MAPACC | ENGINE_MAPDEC) ) ||
        (outpc.clt < ram4.EgoTemp) ||
        (outpc.tps > ram4.TPSOXLimit) ||
        (outpc.afrload > ram4.MAPOXLimit) || (outpc.afrload < ram4.MAPOXMin) ||

To:

Code: Select all

    if ((outpc.rpm < ram4.RPMOXLimit) ||
        (outpc.engine & (ENGINE_TPSACC | ENGINE_TPSDEC | ENGINE_MAPACC | ENGINE_MAPDEC) ) ||
        (outpc.clt < ram4.EgoTemp) ||
        (outpc.tps > ram4.TPSOXLimit) ||
        (outpc.afrload > ram4.MAPOXLimit) || ((ram4.MAPOXMin > 0) && (outpc.afrload < ram4.MAPOXMin)) ||

The added conditional expression on the last line would effectively disable the "lower limit" feature if the limit was set to zero.

[subwoofer]

In terms of user friendlyness, such hybrid settings are not something to do unless absolutely necessary. It takes more documentation, more support than to have a boolean variable do the same thing. Besides, there will probably be someone that is frustrated by such a change since it will break his setup.

[jsmcortina]

I agree on the "magic number" settings - we used to have some of those in MS1 and have moved away from them with MS2/3 for exactly that reason.

It sounds like the problem here could be that the code is treating a signed number as unsigned.
A TPS of -0.1% (signed) would be equivalent to +6553.5% (unsigned)

I'll check out the code when I get a chance. The current code is compiled with options enabled to check for comparisons between signed and unsigned. A number of months ago I fixed a number of lines of code that potentially had problems for this kind of issue.

James

[elaw]

Well, the first argument (user-friendlyness) I agree with. But I'd argue that any setup that's broken by this change was already broken.

Here's why: even though the verbiage in the tuning software says EGO correction is "active above" the setting, the way the code is written ("outpc.afrload < ram4.MAPOXMin") EGO correction will be active *at or above* the setting.

So if you enter the value zero, EGO correction will be active whenever the value is zero or higher - which in relation to the lower limit is effectively all the time, since I can't think of a scenario where a negative number would be valid. MAP certainly cannot (or should not) ever go below zero, and neither should a properly calibrated and functioning TPS.

[jsmcortina]

The code looks fine. I'll change the ini to allow a negative limit to be set for TPS%. This seems like an unusual situation though.

James

[subwoofer]

What happens is that my slightly sticky throttle blade, combined with thermal expansion and possibly a few other effects, team up and cause the TPS value to go to -0.1% occasionally.
I think the correct solution to the problem would be that auto-zero uses the lowest recorded value as 0, rescaling as needed. Now I have to set the zero point a bit higher to make sure it never goes negative. But allowing the threshold to go negative is a quick fix.

[jsmcortina]

The auto-zero seemed like a good idea but caused some problems.

James

[pit_celica]

What about making sure that the conversion from ADC to TPS% never goes into negative number. A simple "if TPS% < 0, then TPS% = 0". The AutoZero would still be functional, but if there are thermal expansion or any other effect while the car run, the TPS% will never be less than 0.

I don't see why someone would want a TPS less than 0 (negative) under any condition.

Sam

[subwoofer]

The auto-zero seemed like a good idea but caused some problems.

Do I remember correctly that the old auto-zero used the ADC value at power on as the 0 point, no matter what? That could easily cause a few problems, if I have to clear a flooded engine the hand on the key and the foot on the pedal move in unison.

The algorithm pit_celica presents should in my opinion be functional, but there could be problems related to it? If the zero point from the TPS calibration is loaded at power up the zero-point would never creep upwards. A noisy TPS pot could do strange things, but that should be easy enough to fix in terms of a simple moving average filter before the comparison.