MSgpio.com read only forums (Jan.15,2018)

No problem, just wish I'd seen this earlier as I've just been out in the car (actually used it to go to into town to buy bread and milk! like a normal car).However, due to work, it may take me until saturday to test...

Martin,

Many thanks for being willing to try this; there's no hurry at all. I appreciate that you are so patient with these things!

Lance.

I got to test the new code this morning, didn't fix the problem I'm afraid..

I'll post the log later today.

Did you happen to get a chance to try the TPS for load?

Not yet! I decided to drive the car to work this morning so I quickly uploaded the new code and logged the run to work. I may be able to try the TPS on the way home, is there anything else I need to do other than sliding it across? any other settings?

Martin,

Thanks for trying this. You should be able to slide the slider across without other changes, at least for a quick test. In the long run you might want to make changes to the shift tables to better accommodate the TPS if it works better for you.

The reason I think that the TPS may work better for you (and possibly everyone) is that your load jumps when you get to 4th gear and this is causing the shift back to 3rd:
The load jumps because you have essentially the same throttle opening, but a much lower engine speed, so the MAP has to rise.

I think what is happening is that this increase in the load after a 3-4 shift breaks the hysteresis, so the 4-3 shift happens right away. Because it happens right away (in milliseconds or less) the chance of capturing the hysteresis = 0 in a datalog is slim (which is about every 70 milliseconds or so). The load decreases after the unwanted 4-3 shift, so there's a subsequently 4-3 shift which sticks because the load is lower (most likely because the TPS has dropped because of the driver's natural reaction to lift the throttle after the strange shift).

I believe this is caused by comparing the hysteresis value to the pre-shift conditions, and the really ought to be compared to the post-shift conditions (once they have stabilized). In the last code I posted, I avoided grabbing the hysteresis values until after the shift had been completed. I will modify the code to the grab the hysteresis load and speed values after a delay, so that it better reflects the conditions after the shift rather than before the shift.

In any case, however, the TPS is more stable over the entire pre-shift/post-shift period (you can see this in your log), so it's less likely to cause 'shift bouncing'.

Lance.

Martin,

Here is code that introduces a delay (the default is ~250 milliseconds) after shifting before grabbing the hysteresis values for the next shift (no shift can occur during the delay). This lets the load value settle in the new gear before measuring, so hopefully a better hysteresis function will be the result. However, I suspect that more TPS use for load is going to be the real solution.
Lance.

If you're interested here is an edited log from this morning...

Yes, this is definitely of interest! I will look at it closely. Thanks for posting it. Lance.

Martin,

In looking at the log you posted, I can see that the avload (the short-term average load) is slow to respond to changes in the instant load during a shift. It takes almost 2 full seconds. So the delay I introduced in the most recent code likely won't be sufficient to solve the issue you have pinpointed.

What you might try doing is reducing the 'load smoothing factor' under 'General Settings -> Throttle and Load Factors -> LOAD Smoothing Factor'. If it was 3000, you might try 1000 or even less.

I will also put something in new code to make sure this is taken into account (and I will post new code shortly).

Lance.