a few issues with shifting

[Bernard Fife]

Ashford,

I am open to suggestions. I am generally happy to make changes based on:
- quantifiable, demonstrated, and operationally significant issues users are having with real transmissions in the real world (I don't want to get caught up in endless changes to match people's often conflicting theories about how things ought to happen),
- what makes sense to the majority of users,
- what can be accomplished within the current framework of the code and hardware, and
- what doesn't defeat or duplicate existing functions.

Lance.

[ashford]

the first is to actually make something simpler for reverse a 9x16 table is not needed a simple 4-6 point graph of xload = x pwm would be sufficient.
instead of using a maximum shift pressure limiters for individual gears use a 6 point graph for shift pressure load = pwm like mentioned for reverse for each gear. the ford 4r70 2nd gear require less pressure than the rest of the gears this is in the factory programming.

and lastly(for now?) i would like to have a load lockout for overdrive if i was running a kpa based shif table this could be easily done but i am using tps based tables and most transmissions ar not designed to hold >400 ft.lbs of torque in high gear.

[Bernard Fife]

make something simpler for reverse a 9x16 table is not needed

Ashford,

There are already two pressure limiting options for reverse: use the table, or use a fixed user value. 100% and a fixed setting the default. You can change the fixed value to whatever you like (between 100 and 40, lower number gives less pressure since this is a bleed valve and the PWM% is 100-setting). See: http://www.msgpio.com/manuals/mshift/V41tune.html#gs and a discussion here: viewtopic.php?f=4&t=583#p3294 I am not sure why an additional table is needed for this (but then my use for reverse is pretty much only for backing out of parking spots on pavement, and other users may have more extreme circumstances I haven't imagined in which they are using reverse).

instead of using a maximum shift pressure limiters for individual gears use a 6 point graph for shift pressure load = pwm like mentioned for reverse for each gear

This is essentially what the 16 x 9 line pressure table does. The line pressure is set for two reasons: it must keep the trans from slipping while in gear, and it must provide adequate but not excessive pressure while shifting. The code sets the pressure based on the lower of the line pressure from the table or the user limit. This allows the user to be sure the shift pressure won't be excessive (with the limit), while letting the user 'soften things up' at lower loads (using the 16x9 table instead of your proposed 6 element tables). These slip/shift requirements are similar, on identical components, so perhaps you can show me precisely why the 16 x 9 table isn't working for you (the table concept was developed from GM's design documents specifying pressure and shift tables for the 4L60e, which are set as speed x load). One of the many advantages of user 16x9 tables is that users can put the values where they need them most (i.e., they might only have one PWM for the 1-2 shift, but 8 for the 3-4 shift) without restrictions on how they place them.

the ford 4r70 2nd gear require less pressure than the rest of the gears this is in the factory programming.

If you have both MAP load tables, or both TPS load tables, you can easily accomplish this by setting your lower value all the cells in the line pressure table that have 2 in the corresponding shift table. If you split the table's load indexes (one TPS and one MAP) then you can't do this, but that's a choice you make in setting up that way. Just to be clear for anyone else that stumbles on this thread though, I personally think sure MAP is a much better measure of load for 95% of users, so that's what I recommend anyone with a reasonable intake manifold vacuum signal use (possibly adjusting the smoothing value to get a stable signal, and the load hysteresis value to prevent gear hunting). TPS load was only put in initially for those that didn't have CAN, or that had no usable vacuum signal (hot cam, etc.) and had to use TPS (TPS is a poor indicator of load, especially at low rpms). I made the split loads available because users asked for it, and it was easy, but it was never going to be a preferred option, and comes with a set of compromises on the setup.

i would like to have a load lockout for overdrive

As you say, this can easily be done with MAP based tables. The code does allow locking out the TCC based on load (the TCC is typically the most torque limited component in high gear). With TPS, you could decide what level of throttle is 'unwise' (presumably the amount that gives an unhealthy level of torque) and make all the cells above that level a lower gear. However, things like rev limiting come into play, so I hesitate to put this in play without a clear demonstration that the current algorithm can't be made to work.

However those are just initial thoughts, and I will think about your suggestions much more. For example, maybe what I need to do is have a combination MAP/TPS based load (like MegaSquirt has had for years), though I am not sure that puts us any further ahead and would have to think about it. Or maybe I could make both indexes on the table user-settable to MAP, TPS, speed, rpm, temperature, etc. like the spare port 0 table. Then you could have PWM by MAP versus TPS, or any other combo you liked... But all of these make the code and documentation more complex, and harder to understand for the user.

I would also like to say that I think it is bad engineering practice to simply keep adding tables and factors to 'correct' the operational algorithms for physical systems like a transmission. This causes a number of problems, including increasingly complex and harder to write, debug, test, document, configure and tune the resulting code; as well as increasing deviation from the physics of the hardware we are controlling (making it harder to apply physical logic and experience to the code). So ultimately it is best if such additions refer to physical quantities and verifiable measurements.

But if enough users want the code changed in any particular way, I will certainly do it regardless of whether I think it is a great idea or not.

Lance.

[Bernard Fife]

Ashford,

It occurred to me that we could use a table to get a better load measurement from the TPS signal, like MS-II does (see this: http://www.megamanual.com/mt29.htm#ra )

The problem with TPS is that the load for an given TPS depends highly on the RPM. For example, on my engine, 25% throttle at 2500 rpm gives all the power the engine has at that rpm (and 100 kPa manifold pressure). But at 6000 rpm, 25% throttle is only about 20% of the torque available, and 100% throttle is required to get full power (and 100 kPa). This is dictated by the facts that: the airflow depends on the engine speed as well as cylinder filling, and the throttle opening dictates the airflow BUT only up until the point where the cylinder is filled, and any wider opening does not affect power output at that rpm (until the rpm rises, of course).

If we use the throttle and engine speed as a look-up table for load, then we can set the the low rpm, high TPS cells all to 100% and more properly use the TPS to control both shifts and line pressure. Like this:

TPSrpm_load.jpg (47.94 KiB) Viewed 13664 times

The table cells then represent the ratio of airflow at an given TPS and engine speed versus the maximum airflow possible at that engine speed; i.e. the table represents real physical quantities.

If users wanted to use the pure TPS signal only for their load, they could simply set all the values is a given row to the TPS bin value for that row. The the looked-up value would be the actual TPS, and RPM would not be a factor.

The other thing I am mulling over is an option to blend TPS and MAP in a user specified ratio (again, like MS-II) but I have to think though the ramifications of doing this, it is not as simple as it might seems (in part because we now have the option for different load indices on different tables).

Neither of these will necessarily help you (though I hope they might), but they ought to help some users.

Lance.

[ashford]

sounds like it is getting over complicated, the reverse idea i had is actually a simplificationremove the 16X9 and single point and replace with a 6 or so point graph. i have a turbo and 50% trhottle can make all different kinds of torque, what i am trying to avoid is the enevatable downshift of a map based table if i only want half of the engine power. eg i go to 50% throttle on the highway it will downshift to 3rd the turbo will then start to spool and build moderate boost, if this were map based it whould then downshift to 2nd- no i have the torque and i want to use it, if i want more power i give it more throttle to go to 2nd. basically the whole reason i asked for the tps based shift table with map based pc and i actually like it execpt for a few things i cant work out.

ok aside from the above rant im still sure something is wrong with hysterisis for 3rd gear a gradual approach to 3rd from 2nd or 4th resurlts in stutters if it is in 3rd gear aproaching 2nd or 4th everything is fine

stutter.png (45.74 KiB) Viewed 13657 times

i tried map based shifting again and went promply back to tps. i set in a large(40kpa) hysteresis, rescaled the loads and tried some testing around 60 mph i crept it up to 80kpa and it held then about 1 second after i let off it downshifted to 2nd . it show this twice in the logs.

its a busy weekend and week it is the nhra openers here ill try out the v2 code when i have a chance to see if it works. i did however do a 6.3@ 110mph today in the 1/8 mile with 100% humidity tomorrow the 1/4 mile should be open if the weather drys out.

[Bernard Fife]

Ashford,

Thanks for the logs, they helped pin-point the problem (when the hysteresis flag was set, the look-up gear was set to the currently selected gear (aka. 'current_gear'), but should have been set to the current 'target_gear'; because the shift was block, the current gear did not equal the target gear, and this cause an oscillation). This has been fixed in the 4.124 code here: http://www.msgpio.com/manuals/mshift/V4code.html That and the signature increment were the only changes for this code. The code is entirely untested, so use with great caution. I am reasonably confident this code will solve the hysteresis issue, but let me know if it doesn't and I will dig even deeper.

The problem with making things 'simpler' is that almost always removes some capabilities for some other users/applications, meaning others are unhappy, and the code is less universal. That's how these thing get so complex in the first place. If you want truly simple code that suits your application in the manner you would like, you can certainly write your own code with only the parameters and capabilities you need using either the 0.99 MShift code or the 1.101 template code as a base. They are here:

http://www.msgpio.com/manuals/mshift/GP ... E_Proj.zip
http://www.msgpio.com/manuals/iocode/code.htm

There is a sub-form for discussing custom code here: viewforum.php?f=3

Lance.

[Bernard Fife]

around 60 mph i crept it up to 80kpa and it held then about 1 second after i let off it downshifted to 2nd . it show this twice in the logs.

Ashford,

Looking at your log, I think this downshift is happening because you are very near a speed related 3/2 shift, but the load smoothing is keeping the load table high for a few seconds after you let off. You probably need to reduce your LOAD smoothing factor quite a bit from the 1000 it is now if you want to change that behavior. The load smoothing is intended to keep the engine/trans in 'full attack' mode even if you lift momentarily (like you might if you were racing on a road course).

Lance.

[ashford]

tried the 4124 code took it for a drive and logged it, it was mostly highway so it was out of the problem area most of the time. i did notice 434343 stutter while decelerating, ii will take a look at it this evening when i get home

[Bernard Fife]

Ashford,

I will keep looking for the cause then.

Lance.

[ashford]

i took a closer look at my log th e 43434 stutter happens at 40mph on my lowest tps bin on the shift tablei have 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?
also when i took my logs i noticed it was doing gear shift way to early i took a look and my shift table had map values 20-100 instead of tps 0-100 it seems it didn't get impoted/converted corectly from the old msq, i changed these somewhere in the middle of the log.