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