Page 2 of 2 FirstFirst 12
Results 21 to 29 of 29

Thread: NAG1/A580 Part Throttle Shift Scheduling Table Tuning

  1. #21
    Tuner in Training
    Join Date
    Nov 2019
    Posts
    22
    Time for another update.
    Heard back from HP tuners support and they added a set of shift tables matching the values of what I saw in bluegoat06's screen shot to 4.5.1417 Beta.
    Long story short, those tables didnt solve the part-throttle shift tuning issues. Bugger!

    However, I think I may have determined and confirmed how the actual part-throttle shift strategy works in these NAG1 boxes, well at least in the Jeep JK platform.

    To try and figure this out I made the shift speed under each pedal breakpoint the same, thus eliminating the influence of the pedal % and therefore only relying on the trans output shaft speed to command the shift.
    I also copied the tables over so that the same table in each shift mode (Normal/Performance/Winter/Unknown) was exactly the same eg all the 1-2 upshift tables had the same pedal breakpoints and shift speeds etc. On top of that I disabled the performance driving factor switch so no table blending could occur.
    TransTest6.6.JPG

    Even with this very simplified shifting strategy I found that the shifts would still occur in somewhat random fashion! However I managed to correlate virtually every shift in my 20min road test (within +/- 15rpm of the shift speed) from the datalog.
    Im now 99% confident that the upshift/downshift speed offset does infact offset the shift speed commanded in the part-throttle shift tables eg the upshift flag is set and a shift is commanded only once the commanded shift speed + upshift speed offset >= output shaft speed.

    Here's a good example of the 3rd gear "hang" issue that Ive been struggling with.
    transTest6.6_3-4shift.JPG
    From the shift tables this should occur at an output shaft speed of 1375rpm. However the upshift flag does not get set until the output shaft speed reaches nearly double that at 2461rpm! The upshift offset at this point is 1116rpm but due to the data capture rate (10ms) and refresh rate for the TCM check for this PID (~250ms) the value of 1087rpm needs to be used. This corresponds to the slight discontinuity in the upshift offset trace.

    In this case the actual shift speed now equals: 1375 (commanded from table) + 1087 (upshift offset) = 2462rpm, which pretty well matches the output shaft speed of 2461rpm when the actual upshift flag is set!
    Using this method I managed to correlate the error in shift speeds (error = output shaft speed - shift speed) to the upshift/downshift speed offset for a set of 10 up/down shifts, picked at random from the datalog. If the upshift/downshift offset speed is added/subtracted to/from the commanded shift speed then everything matches to within +/-12rpm of the actual output shaft speed.
    shiftSpeedErrors6.6.JPG
    Note that when the offset speed = 0, the shift flag gets triggered when the output shaft speed virtually matches the commanded shift speed. Only then do the shifts occur at the exact output shaft speed commanded in the tables (as you would want).

    Now the question is: What factors influence this offset speed? This needs to be known to be able to predictably tune these part throttle shift tables.
    In the 3rd gear hanging example, the upshift offset speed only begins to drop once I lift off the throttle. It also shows a discontinuity just as a shift state is flagged.
    From these influences I would have to guess that the "Term Coefficients" under "Shift General" have something to do with it.

    Ill have a play with these coefficients but ideally it would be great for the engineering team who dissembled the code and wrote the HP platform for the NAG1 to chime in with the underlaying equations to determine how to "tune"/control or zero the upshift/downshift speed offset. There also seems to be a PID missing that should lump all the coefficients in the a single factor

    Datalog and tune attached

    Cheers,
    Dan

    modTransTest6.6.hpt
    mod6.6.hpl

  2. #22
    Tuner in Training
    Join Date
    Nov 2019
    Posts
    22
    Still at a loss with this issue.

    I started making large changes to the Term Coefficients and Decay Divisors under the Shift General tab in an attempt to control and minimize this Upshift/Downshift Offset Speed parameter. I tried both maximizing and minimizing the the Term Coefficients and Decay Divisors but doing so or any combination of max/min does not seem to have much, if any affect on the Upshift/Downshift Offset Speed. The explanation of these variables relate them to the "Driving Factor". Is this the "Aggression Blend" PID?

    After many hours of datalogging it seems that this Upshift/Downshift Offset Speed parameter somewhat randomly changes value, thus any effort to "tune" the part throttle shift scheduling tables will result with the desired shift speed being offset by this parameter and therefore, the actual shift speed will not match that of the table. It is only when the Upshift/Downshift Offset Speed = 0 that the shift speeds match the desired speeds in the tables.

    In extreme cases, such as my "3rd gear hang" example, the Upshift Offset Speed can reach such a high value that the 3rd -> 4th gear shift is effectively blocked as the shift will only be commanded once the actual output shaft speed > shift speed + upshift speed offset. This results in stupidly high engine RPMs for no reason eg 4000+rpm at low throttle openings (~15%) even though the desired shift speed translates to engine rpms of ~2500 or so. In most cases lifting off the throttle will decay this upshift offset speed parameter and allow the shift to occur but this is a serious annoyance!

    This Upshift/Downshift Offset Speed parameter is really messing with these shifts. How do we control, "tune" or disable it so we can gain full control over these part throttle shifts?

    Anyone have any other ideas or inputs?

    Cheers,
    Dan

  3. #23
    Potential Tuner
    Join Date
    Dec 2019
    Posts
    3
    Hello all.

    My first post on this forum. I have zero experience from dodge but i have done some tuning on egs52 in mercedes diesel. There ecu send throttle position value to egs52 which is used on those tables. And for that there is "inverse driving map" in ecu where is pedal % and axis are engine rpm and injected duantity. So pedal value to egs52 is not real value or same what ecu uses. Maybe similar thing here?

  4. #24
    Have you thought about disabling the torque management on the engine side to see what happens?

    What about resetting all adaptives?
    Last edited by Moparmatty; 3 Weeks Ago at 11:28 AM.
    2006 Chrysler 300C SRT-8
    JBA 3" stainless catless mid pipes
    3" Flowmaster American Thunder stainless cat-back
    Injen CAI
    Innovate dual WBO2 sensor kit
    Custom tuning by me via HPT

  5. #25
    Tuner in Training
    Join Date
    Nov 2019
    Posts
    22
    Quote Originally Posted by Juuso124 View Post
    Hello all.

    My first post on this forum. I have zero experience from dodge but i have done some tuning on egs52 in mercedes diesel. There ecu send throttle position value to egs52 which is used on those tables. And for that there is "inverse driving map" in ecu where is pedal % and axis are engine rpm and injected duantity. So pedal value to egs52 is not real value or same what ecu uses. Maybe similar thing here?
    This is rather interesting Juuso124. I wonder if the OS's are the same as in these FCA vehicles? Do you have a read from a Mercedes with a egs52 that I could have a look at?

    To try and figure this all out I'm currently running simplified shift scheduling tables, where all the shift speeds are set to the same value (see post #21). In doing so the pedal position shouldn't have any bearing on when the shifts occur. Doing this I was able to correlate the actual shift speed to the desired shift speed +/- the upshift/downshift offset speed.

    I still need to check if the pedal break points make sense once this upshift/downshift offset speed can be controlled

  6. #26
    Tuner in Training
    Join Date
    Nov 2019
    Posts
    22
    Quote Originally Posted by Moparmatty View Post
    Have you thought about disabling the torque management on the engine side to see what happens?

    What about resetting all adaptives?
    Every time after a TCM reflash I use the scanner and do a trans initialize and reset the trans adaptives. Don't know if its required but this is the same procedure I've followed every time.

    Torque management on the engine side? Any table/switches in particular?

    HP support have gone a bit quiet of late so I'm willing to give any suggestions a go.

    Just want to be able to actually tune when this trans shifts..

  7. #27
    Potential Tuner
    Join Date
    Dec 2019
    Posts
    3
    I read egs52 with Ktag and modify file in Winols. I looked dodge file (downloaded from somewhere) in vcmsuite and managed to find same maps for mercedes in winols. I have understood that A580 is same tranny what MB calls 722.6. Also example porsche files are allmost identical to mb so i think if dodge tcu is readed with then it would be similar also.

    If this problem is in pedal value, then changes needs to be done in ecu, not in tcu. Maybe hptuners cannot find this map in ecu? Then you need to find it from hexdump in winols or similar.

  8. #28
    Potential Tuner
    Join Date
    Dec 2019
    Posts
    3
    Ecuconnection.com and there egs52 thread you can find many mercedes maps if interested. I havent found any dodge maps from internet. Maybe anyone havent read them with ktag to get hexdump file?

  9. #29
    Tuner in Training
    Join Date
    Nov 2019
    Posts
    22
    Thanks for the info Juuso124! I'll browse through that forum and check out the EGS52 thread. You might be correct about his bizarre calculated pedal value, however when I effectively eliminate this pedal variable (by making all the shifts speeds the same) this upshift/downshift offset speed variable still messes with the actual shift speeds. I believe that once control over this variable has been achieved then its time to look at the randomness associated with the pedal variable.