a few issues with shifting

[Bernard Fife]

3rd at 35 and 4th at 40. with a 5 mph hysteresis shouldnt a 4-3 shift happen at 30mph? or would it be at 35?

Ashford,

No, definitely not at 30. The speed for a shift depends on the bins, whether it is an upshift or downshift, and whether either of the hysteresis conditions have been met (as well as whether the resulting shift would over-rev or under-rev the engine if rpm checking is enabled, of course).

In your example, an upshift would happen at 40, and the downshift at 39.9 (if at least one of the hysteresis conditions have been met). If both of the hysteresis conditions have not beet met since the last shift, then the upshift will happen at 45, and the downshift will happen at 34.9.

However, if the upshift happens at 45, that would reset the hysteresis conditions, so the next down shift could happen at 39.9, but the next upshift couldn't happen until 50 if you were to continue to accelerate after the 45mph shift. So the hysteresis is not an up/down difference from the table for the shifts, instead it completely blocks shifts until the conditions are met. In normal operation, the hysteresis conditions are met naturally by accelerating towards an upshift, or decelerating towards a downshift, so hysteresis does not normally block shifts. When it will block shifts is if the speed or load are very near a shift point and they are not changing much. In those cases, the shift is blocked to prevent hunting.

This is explained in more detail here: http://www.msgpio.com/manuals/mshift/tuning.html

BTW, if the shifts in your table are 5mph apart (for example 35 and 40 mph), and you have the speed hysteresis set to 5 mph, you are going to cause all sorts of seemingly unfathomable issues due to the way the hysteresis and shift table are going to interact. If your shift table has values that close, I would suggest a hysteresis value of no more than 3 mph.

Lance.

[ashford]

i have scoped my vss and redid my vr circuit to the point where the speed input is perfect, this has fixed 95% of my problems i have notice over the last 200 miles only 3 times it shifted 4-3-4-3 a really good improvement the 2-3-2 i have only noticed once. no log of it hapening though. i have lowered my 3-4 shift to 35mph at 0% tps to soften the shift(4-3) and have noticed it downshifting at different times sometimes at 40 sometimes at 35.

i saw the v5 code and i think we need a discussion about the ups and downs of some features. i am a firm believer that the shift tables "should" be based on driver demand ie tps and the pressure table "needs" to be based on engine torque ie map.

[Bernard Fife]

Ashford,

The idea in the code is that the load is based on the engine torque output at any given point (relative to it's maximum torque at that point). Obviously the driver can change the engine's torque output using the throttle, but changes in throttle that do not result in changed engine output are irrelevant. So that's the idea behind the 6x6 TPSxRPM table - it changes the TPS into a "torque demand" value.

I don't believe in any case that the line pressure should be based on anything other than the current load, as the engine output is what determines the load on the friction elements and thus the need for a specific line pressure to manage slippage (whether in gear or shifting).

Furthermore, the shifts should be based on the engine output, and this is a function of the throttle and rpm; i.e. the MAP or the "torque demand" mentioned above. As well, MAP *is* a function of "driver demand" - and it is one of the best measures of that, in that it scales quite linearly with torque output at any given rpm (unlike TPS, which needs the table mentioned above to do the same thing), reacts very quickly, and it not as subject to calibration and wiring errors as the TPS is.

You may be thinking that TPS responds even more quickly than MAP. That might be true in the sense that TPS is a cause and MAP is an effect, but it is MAP that changes the cylinder filling and thus the torque output. Furthermore, the time difference between TPS changes and MP changes is very small compared to things like shift times, etc. And on top of that, the load is already averaged in the code to slow down changes (because we don't want the trans shifting with every slight tremble of your throttle foot).

You haven't shown us any evidence at all that suggests that TPS is better for the shift table. And we don't have any theoretically sound reasoning for such a setup. You have said you like it better, but that's not much for us to go on, and no-one else is telling us it is any better at all (in fact, only a few other users even tried it to my knowledge (related privately), and they all switched back after seeing no benefit and some problems in short trials). So without good reasons, it's hard to justify continuing that line of development.

Perhaps you are saying that in a turbocharged application with a lot of lag that discrepancies between TPS and MAP can develop, but we need to see evidence of how this affects the line pressure and shift requirements differently.

Of course, if you can clearly demonstrate, based on a full understanding of how the shift table works and illustrative datalogs, that mixed indices are better, and that they can solve a specific problem shown in datalogs, then we can revisit this. In any case, the mixed indices will stay in the 4.1xx code (which will continue to get bug fixes), so you can use that for as long as you like, of course.

Lance.

[ashford]

Ashford,

The idea in the code is that the load is based on the engine torque output at any given point (relative to it's maximum torque at that point). Obviously the driver can change the engine's torque output using the throttle, but changes in throttle that do not result in changed engine output are irrelevant. So that's the idea behind the 6x6 TPSxRPM table - it changes the TPS into a "torque demand" value.

from a perspective of engine torque yes that is true. but from a standpoint of available power or transmission output, no. so someone is in 3rd gear and accelerates to 50%throttle and engine torque is maxed out and the driver is ok with the power output at that point there is no need to downshift that is why the throttle is at 50% if more is wanted give it more throttle to downshift, and power to the wheels is increased. it is the concept of the kickdown cable used on virtually all 3 speed transmissions.

I don't believe in any case that the line pressure should be based on anything other than the current load, as the engine output is what determines the load on the friction elements and thus the need for a specific line pressure to manage slippage (whether in gear or shifting).

i agree fully, i wont argue with this one bit that is why i wanted line pressure map based and shift tables tps based

Furthermore, the shifts should be based on the engine output, and this is a function of the throttle and rpm. As well, MAP *is* a function of "driver demand" - and it is one of the best measures of that, in that it scales quite linearly with torque output at any given rpm (unlike TPS, which needs the table mentioned above to do the same thing), reacts very quickly, and it not as subject to calibration and wiring errors as the TPS is.

throw in a turbo and everything above changes. driver demand is throttle with a turbo engine map is a function of throttle, TIME and rpm. for eqample imagine a naturally asperated engine with 100%throttle it makes 50kpa in the manifold at lower rpm and after it has been at 100% for a few seconds and rpm increases it increases to 100 kpa.basically a turbocharged engine works backwards from an na one in regaurds to throttle/rpm.

You may be thinking that TPS responds even more quickly than MAP. That might be true in the sense that TPS is a cause and MAP is an effect, but it is MAP that changes the cylinder filling and thus the torque output. Furthermore, the time difference between TPS changes and MP changes is very small compared to things like shift times, etc. And on top of that, the load is already averaged in the code to slow down changes (because we don't want the trans shifting with every slight tremble of your throttle foot).

with map based shifting on a turbo an increase in map with a steady tps gives an unwanted downshift.

You haven't shown us any evidence at all that suggests that TPS is better for the shift table. And we don't have any theoretically sound reasoning for such a setup. You have said you like it better, but that's not much for us to go on, and no-one else is telling us it is any better at all (in fact, only a few other users even tried it to my knowledge (related privately), and they all switched back after seeing no benefit and some problems in short trials). So without good reasons, it's hard to justify continuing that line of development.

both ford and gm use tps based shift setups with engine torque dictating the line pressure, gms way of doing it is simple and effective while fords is complex.

Perhaps you are saying that in a turbocharged application with a lot of lag that discrepancies between TPS and MAP can develop, but we need to see evidence of how this affects the line pressure and shift requirements differently.

YES IT DOES, pics below

Of course, if you can clearly demonstrate, based on a full understanding of how the shift table works and illustrative datalogs, that mixed indices are better, and that they can solve a specific problem shown in datalogs, then we can revisit this. In any case, the mixed indices will stay in the 4.1xx code (which will continue to get bug fixes), so you can use that for as long as you like, of course.

Lance.

here is a pic of what is desired behavior for my setup at half throttle full torque.

desired.png (36.22 KiB) Viewed 14564 times

note that the map increases as i let up on the throttle. i am at roughtly 50% throttle when boost comes on as that i wan about half of the engine POWER not torque. if this was map based it would of downshifted to the lowest possible gear giving me all the POWER available from the drivetrain. if i wanted more power to the wheels i would give it more throttle and then i would have more engine rpm with the same torque since power product of torque and rpm.

i hope this better conveys my reasoning.

just for curiosity i have both ford and gm tuning software and will post a few pics

fords.JPG (251.1 KiB) Viewed 14564 times

shifting.png (113.44 KiB) Viewed 14564 times

[Bernard Fife]

it is the concept of the kickdown cable used on virtually all 3 speed transmissions.

Ahford,

Yes, but only because they were conceived before electronic controls and TPS was the only measure of load that they had.

with map based shifting on a turbo an increase in map with a steady tps gives an unwanted downshift.

I would think that if the boost is rising the engine's output is rising and a more aggressive shift strategy is warranted. The code is designed so that you can avoid a shift by putting the appropriate values in the cells near that shift, of course. If you show us an specific example using a datalog and MSQ of a shift that isn't working using your shift table (and assuming you have your VSS issues worked out) we can try to see if there is a combination of bins, cells, smoothing, and hysteresis that will work for your setup.

note that the map increases as i let up on the throttle.

That is a good reason for an electronically controlled blow-off valve (which can be done with the GPIO, and BTW I hope to add TPS to the MShift spare port conditions a some point as well), but I don't see how it is a good reason to change transmission control strategies.

i am at roughtly 50% throttle when boost comes on as that i wan about half of the engine POWER not torque.

Maybe, but that's a job for an electronic turbo controller, not a transmission controller. The trans controller cannot control the engine output (since it does not know what the torque will be after any given shift), it can only respond to it.

In an OEM application, where the engine's torque output at all speeds and throttle openings is a known, and with a drive-by-wire throttle in place, the TPS can act as a 'demand sensor', and the engine and drive-line strategies can be based on it. But where we don't have such a map of the engine's output, and we don't control the throttle position - we only measure it, the throttle position poorly reflects the engine output (both because of the engine rpm and any turbo boost lag/overshoot), the TPS isn't really delivering a lot of useful information.

Have you tried the new TPS/MAP percentage based function? You might find that 50%/50% or some other proportion delivers the transmission behavior that you want. The TPS part of the input would stabilize the load value, while the MAP factor would allow it to respond to boost to some degree.

Lance.

[Bernard Fife]

Ashford,

It occurred to me that there is an option that might suit both of us: we could make the line pressure output a user option to be a spare output, with a 16x9 table (and user chosen indices) so you could use TPS only for load for the shift table, then set up the optional spare port to use for PWM on the line pressure with MAP and speed as indices. Then you have the flexibility to implement the set-up you prefer, and we haven't altered the conceptual basis of the code.

In fact, you could do this right now using spare port 0 if we enabled MAP as an index option (right now it is only load, speed, rpm, and temperature). I will add the ability to use MAP or TPS as index values to the next code when I enable the line pressure output as a spare port. That should give you lots of options.

Lance.

[ashford]

it is the concept of the kickdown cable used on virtually all 3 speed transmissions.

Ahford,

Yes, but only because they were conceived before electronic controls and TPS was the only measure of load that they had.

not true, all ford and gm 3 speeds had a vacuum modulator( except on a diesel) to control line pressure and control shift points to a moderate level. the kickdown cable was used for the more agressive driver demand and was not actuating till about %50 throttle with the exception of some th400's they had an electric kickdown .

with map based shifting on a turbo an increase in map with a steady tps gives an unwanted downshift.

I would think that if the boost is rising the engine's output is rising and a more aggressive shift strategy is warranted. The code is designed so that you can avoid a shift by putting the appropriate values in the cells near that shift, of course. If you show us an specific example using a datalog and MSQ of a shift that isn't working using your shift table (and assuming you have your VSS issues worked out) we can try to see if there is a combination of bins, cells, smoothing, and hysteresis that will work for your setup.

currently i have it shifting for the most part how i want it on 4124 with tps shift tables, and finally have my vss sorted.

note that the map increases as i let up on the throttle.

That is a good reason for an electronically controlled blow-off valve (which can be done with the GPIO, and BTW I hope to add TPS to the MShift spare port conditions a some point as well), but I don't see how it is a good reason to change transmission control strategies.

using a bov to control boost pressure is only practical on a supercharded engine on a turbo it will overspeed the turbo causing damage if done repeatedly. it sort of like pulling a boat prop out of the water at wot.

i am at roughtly 50% throttle when boost comes on as that i wan about half of the engine POWER not torque.

Maybe, but that's a job for an electronic turbo controller, not a transmission controller.

i do have a controller(ms3) but the purpose of one is to increase boost above spring regulated pressure of the wastegate, it is not possible to reduce it, but have not implememted it yet because i am not ready to crank up the engine yet.

The trans controller cannot control the engine output (since it does not know what the torque will be after any given shift), it can only respond to it.

i don't need the gpio to control the engine, i simply want it to control the line pressure with map and shifting with what my foot says. the pic i uploaded is actually what i wanted it to do. i had full engine torque in 3rd gear, less than half of the torque i have available to the tires, if this were map based the gpio would of downshifted to 2nd and posibly 1st giving ALL available torque to the wheels almost 3 time what i would of wanted. with tps based i can give it more throttle say 75% to get 2nd gear and multiply the torque to the wheels by the ratio of 2nd gear or 100% to get it all.

if i set up my shift table on map based to shift aproxamately what it does with tps( boost controller can be tps based so would change kpa with foot position) then i will have the problem of not being able to get downshifts till the turbo is doing its thing which can take a while if at a low rpm.

In an OEM application, where the engine's torque output at all speeds and throttle openings is a known, and with a drive-by-wire throttle in place, the TPS can act as a 'demand sensor', and the engine and drive-line strategies can be based on it. But where we don't have such a map of the engine's output, and we don't control the throttle position - we only measure it.

oem actually measure torque based of of maf and or map. tps serves little purpose on oems for load. it is mostly used for driver demand, accel enrichment setting idle and limp mode if one of the other sensors fail

the throttle position poorly reflects the engine output (both because of the engine rpm and any turbo boost lag/overshoot), the TPS isn't really delivering a lot of useful information.

it serves for the perfect indication of driver demand.

Have you tried the new TPS/MAP percentage based function? You might find that 50%/50% or some other proportion delivers the transmission behavior that you want. The TPS part of the input would stabilize the load value, while the MAP factor would allow it to respond to boost to some degree.

Lance.

i was going to till i read it also controls line pressure along with the shift tables.

[ashford]

Ashford,

It occurred to me that there is an option that might suit both of us: we could make the line pressure output a user option to be a spare output, with a 16x9 table (and user chosen indices) so you could use TPS only for load for the shift table, then set up the optional spare port to use for PWM on the line pressure with MAP and speed as indices. Then you have the flexibility to implement the set-up you prefer, and we haven't altered the conceptual basis of the code.

In fact, you could do this right now using spare port 0 if we enabled MAP as an index option (right now it is only load, speed, rpm, and temperature). I will add the ability to use MAP or TPS as index values to the next code when I enable the line pressure output as a spare port. That should give you lots of options.

Lance.

if shift pressue limits are carried over i will give it a try

[ashford]

a thought occurred to me. i can setup a spare port on the ms3 to activate at X throttle and hysteresis then switch between table 1 and 2 using the 4wd input. make a "grandpa" table and wild table with some overlap of kpa.

then i also thought if tables could be blended via tps that would be even better.