Page 4 of 6 FirstFirst 123456 LastLast
Results 61 to 80 of 116

Thread: Whats the torque/ inverse calculation?

  1. #61
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    After making some very large changes to the OP Torque table, my next log is nearly torque error free. However, the ETC still does some janky movement:


    ETC-crop.png
    Attached Files Attached Files

  2. #62
    Advanced Tuner
    Join Date
    Jul 2017
    Posts
    529
    Quote Originally Posted by CCS86 View Post
    After making some very large changes to the OP Torque table, my next log is nearly torque error free. However, the ETC still does some janky movement:


    ETC-crop.png
    Still not sure how, but the torque tables control everything. When I get to a hard place, I can go make major revisions to torque table, and go from there. My 14GT500 wanted to idle badly, & not settle to idle good, I put stock torque tables in, cut them in half, calculated inverse, & drives 100x better down low.

  3. #63
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    I'm finally making a bit of headway. The inverse tables seem to be what influences IPC TQ Errors. The TQ table itself doesn't seem to impact them.

  4. #64
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    So I thought. Still fighting bizarre torque errors, even using murphie's method of using logged abs/air load against rpm and requested/brake torque to correct the inverse tables; then using inverse to calculate new torque table values.

    I still feel like we have a fundamental misunderstanding about how this torque system works.

    In this case below, I can't fathom how there can be a torque error of 264 lb*ft, given the logged and tune values:

    TQ-error.png
    Attached Files Attached Files

  5. #65
    Senior Tuner
    Join Date
    Jan 2013
    Location
    Hawaii
    Posts
    2,101
    Quote Originally Posted by CCS86 View Post
    So I thought. Still fighting bizarre torque errors, even using murphie's method of using logged abs/air load against rpm and requested/brake torque to correct the inverse tables; then using inverse to calculate new torque table values.

    I still feel like we have a fundamental misunderstanding about how this torque system works.

    In this case below, I can't fathom how there can be a torque error of 264 lb*ft, given the logged and tune values:

    TQ-error.png
    I'm not sure if I mentioned it in this thread, but I've said it before. Your axis values are critical to get you in the ball park first.

    Imagine the model extremely simplified, fill the tables with the value of the axis in the opposite table. It would basically be the axis values. You would only then need to worry about your 0 torque and base load value, your maximum torque and maximum load values, then the few cells between to establish a relationship. This is a model of indicated torque when thinking about it think of the engine running stoich(lambda 1) and mbt timing values.

    At 1.2 load 480ft lbs of torque may be a little high.
    At 1.6 load 660ft lbs is high.
    All kinda depends on where your MBT values are at so it's just a guess.

  6. #66
    Potential Tuner
    Join Date
    Dec 2013
    Posts
    2
    Hey Murfie, have you used the Calc with a boosted app with higher load and torque values? I set this up for a boosted app and as i apply the logged air load values, calculated torque seems to be very low at high load areas which is throwing me for a loop. I was following the revised directions bill posted, and understanding you apply the logged load to get you new torque values, just seems off for me

  7. #67
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Quote Originally Posted by murfie View Post
    I'm not sure if I mentioned it in this thread, but I've said it before. Your axis values are critical to get you in the ball park first.

    Imagine the model extremely simplified, fill the tables with the value of the axis in the opposite table. It would basically be the axis values. You would only then need to worry about your 0 torque and base load value, your maximum torque and maximum load values, then the few cells between to establish a relationship. This is a model of indicated torque when thinking about it think of the engine running stoich(lambda 1) and mbt timing values.

    At 1.2 load 480ft lbs of torque may be a little high.
    At 1.6 load 660ft lbs is high.
    All kinda depends on where your MBT values are at so it's just a guess.


    That doesn't really explain anything.

    At 1.2 load, there is nothing set to 480 ft lbs, it is ~380. The axis values I am using are straight from the FRPP strategy.

    I think this procedure is flawed. I can start with the FPDX0A8 strategy, which gives me no torque errors, then follow this procedure, and create more and more errors. The FPDX0A8 torque tables have rescaled the load axis to replace 0.9 with 1.2, and added 1.6. They have different values in every single cell of the OP torque table, yet the inverse table is a carbon copy of the 2012 GT table, except for the very last row. That seems like quite a shortcut, as 90% of the TQ/inverse tables don't match, yet it gives no torque errors.

    Check it out for yourself. I'm attaching the stock GT and FPDX0A8 tunes to compare.
    Attached Files Attached Files

  8. #68
    Senior Tuner
    Join Date
    Jan 2013
    Location
    Hawaii
    Posts
    2,101
    Quote Originally Posted by CCS86 View Post
    That doesn't really explain anything.

    At 1.2 load, there is nothing set to 480 ft lbs, it is ~380. The axis values I am using are straight from the FRPP strategy.

    I think this procedure is flawed. I can start with the FPDX0A8 strategy, which gives me no torque errors, then follow this procedure, and create more and more errors. The FPDX0A8 torque tables have rescaled the load axis to replace 0.9 with 1.2, and added 1.6. They have different values in every single cell of the OP torque table, yet the inverse table is a carbon copy of the 2012 GT table, except for the very last row. That seems like quite a shortcut, as 90% of the TQ/inverse tables don't match, yet it gives no torque errors.

    Check it out for yourself. I'm attaching the stock GT and FPDX0A8 tunes to compare.
    I guess you are not understanding what I mean by, look at your axis values. This is the values of load in one axis and the value of torque in the other tables axis.

    1.2=480
    1.6=660

    These are describing the reflection line the model is based around. Its very important you have these point set up appropriately to populate the tables appropriately.

    This is the best I can do for a visual representation from my phone.
    https://en.m.wikipedia.org/wiki/File...uare_graph.svg

    The axis values would be points on the black line.

    The values of torque populating cells of the table are the MBT torque values. Paying attention to MBT ignition values and how they flow is important. Your actual ignition advance against the MBT value are going to be the main factor between indicated torque and engine brake torque.
    Unless you can get the car to run MBT ignition values, you are not going to populate torque values from a dyno. That idea is flawed.

    The connection in the model between the estimated torque and indicated torque is the load value. Getting their relationship so that the commanded torque is in the right relative place for the desired action is what you need to accomplish. Surging, torque errors, etc. are because the commanded is saying one thing and the model is indicating another.

    Don't be afraid to simplify things to get a handel on how changes effect things. Flatten the MBT ignition values, add a degree, remove a degree compare what it does to engine brake torque and what it did to indicated torque. Do the same in the torque and inverse tables.

  9. #69
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Quote Originally Posted by murfie View Post
    I guess you are not understanding what I mean by, look at your axis values. This is the values of load in one axis and the value of torque in the other tables axis.

    1.2=480
    1.6=660

    These are describing the reflection line the model is based around. Its very important you have these point set up appropriately to populate the tables appropriately.

    This is the best I can do for a visual representation from my phone.
    https://en.m.wikipedia.org/wiki/File...uare_graph.svg

    The axis values would be points on the black line.

    The values of torque populating cells of the table are the MBT torque values. Paying attention to MBT ignition values and how they flow is important. Your actual ignition advance against the MBT value are going to be the main factor between indicated torque and engine brake torque.
    Unless you can get the car to run MBT ignition values, you are not going to populate torque values from a dyno. That idea is flawed.

    The connection in the model between the estimated torque and indicated torque is the load value. Getting their relationship so that the commanded torque is in the right relative place for the desired action is what you need to accomplish. Surging, torque errors, etc. are because the commanded is saying one thing and the model is indicating another.

    Don't be afraid to simplify things to get a handel on how changes effect things. Flatten the MBT ignition values, add a degree, remove a degree compare what it does to engine brake torque and what it did to indicated torque. Do the same in the torque and inverse tables.





    I see what you mean now.

    I was actually running a slightly modified version of the FRPP axis values in that tune.

    Here is a chart showing the row axis values plotted against one another in the stock GT tune, the FRPP, and my modified version. They all have a fair amount of non-linearity, so I mocked up a linearized test as well:


    TQ Axes.png






    The stock GT settings really have to be fairly well optimized with as much attention as you would assume they received, and with how well a stock car drives. Not to say it can't be improved upon.

    If I run the stock MP0 tables through your calculator, it shows calculated changes of up to 22% (most of the table is much closer though):

    Murphie-stock-gt.png





    If I run the same data through a calculator I built, the largest calculated change I see is 1%:


    My-Stock-GT.png

  10. #70
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Murphie?

  11. #71
    Advanced Tuner
    Join Date
    Sep 2018
    Posts
    213
    Just for clarity sake. The column table in your tune should never be adjusted to the values calculated in the spreadsheet? Just change the actual inverse values with your logged airload?

    Another question. If load is used to calculate torque and the "load with failed MAF" table is used to predict airflow by RPM & pedal position than what is the driver demand table for??? My thinking is MAF calculates airload, airload calculates torque, and Alpha N is Airload based on pedal position. I know the driver demand has a lot to do with pedal feel but why have it if Alpha N is pretty much doing the same thing? Or, does driver demand have to do with spark control? I know it's a dumb question but it's got me wondering what the true purpose of each table is. What I'd do to talk to a Ford engineer lol.

  12. #72
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Load with failed MAF is only used when the MAF sensor is deemed to be failed. It's just an attempt at a fail-safe condition.


    This is a rough flow.

    1. Driver Demand takes RPM and pedal position to give a requested torque
    2. Reqested torque is run through the Torque / Inverse tables to look up a desired load
    3. Desired load is turned into a desired airmass (MAF rate)
    4. Desired MAF rate is run through the ETC tables (effective area / predicted angle) to give a throttle body opening angle

  13. #73
    Advanced Tuner
    Join Date
    Sep 2018
    Posts
    213
    Quote Originally Posted by CCS86 View Post
    Load with failed MAF is only used when the MAF sensor is deemed to be failed. It's just an attempt at a fail-safe condition.


    This is a rough flow.

    1. Driver Demand takes RPM and pedal position to give a requested torque
    2. Reqested torque is run through the Torque / Inverse tables to look up a desired load
    3. Desired load is turned into a desired airmass (MAF rate)
    4. Desired MAF rate is run through the ETC tables (effective area / predicted angle) to give a throttle body opening angle

    Ohhh! That makes sense! Hey thanks for sharing that. As far as the spreadsheet goes do you adjust your column tables in the tune and log to the new values in the sheet or is it just there for math? Also, have you used this sheet and if so how did it work out?

  14. #74
    Tuner in Training
    Join Date
    Feb 2019
    Posts
    26
    Quote Originally Posted by murfie View Post
    No. Etc torque is going up, but load isn't because it's not opening the TB. Because the torque/ load tables are saying it doesn't have to, to make the desired torque. You went too far with it and the graphs are taking you further down the wrong way. The goal is to get ETC torque and engine brake torque closer together with out it causing throttle closures or rev hang. You can replace ETC torque with engine brake torque in the graph to go the other way. You can also use the ETC / engine brake TQ ratio to multiply your load value.
    Could you explain this a little more? Using your method I've managed to get my throttle to stay open under load, but now i'm getting rev hangs when I back off the pedal.

  15. #75
    Tuner
    Join Date
    Apr 2018
    Location
    Canada
    Posts
    50
    How do you Setup the MP histogram? Do you use a custom math for each MP? Im newer to HP so setting up Histograms is still far from my own reach as far as custom stuff outside of norm

  16. #76
    Tuner in Training
    Join Date
    Feb 2019
    Posts
    26
    Quote Originally Posted by murfie View Post
    I guess you are not understanding what I mean by, look at your axis values. This is the values of load in one axis and the value of torque in the other tables axis.

    1.2=480
    1.6=660

    These are describing the reflection line the model is based around. Its very important you have these point set up appropriately to populate the tables appropriately.

    This is the best I can do for a visual representation from my phone.
    https://en.m.wikipedia.org/wiki/File...uare_graph.svg

    The axis values would be points on the black line.

    The values of torque populating cells of the table are the MBT torque values. Paying attention to MBT ignition values and how they flow is important. Your actual ignition advance against the MBT value are going to be the main factor between indicated torque and engine brake torque.
    Unless you can get the car to run MBT ignition values, you are not going to populate torque values from a dyno. That idea is flawed.

    The connection in the model between the estimated torque and indicated torque is the load value. Getting their relationship so that the commanded torque is in the right relative place for the desired action is what you need to accomplish. Surging, torque errors, etc. are because the commanded is saying one thing and the model is indicating another.

    Don't be afraid to simplify things to get a handel on how changes effect things. Flatten the MBT ignition values, add a degree, remove a degree compare what it does to engine brake torque and what it did to indicated torque. Do the same in the torque and inverse tables.

    I'm a little lost, but I think you are saying there is a direct relationship between the axis values of each table so if one is changed the other needs to also. If I'm understanding this correctly, how would one go about determining the torque axis values on the inverse table after scaling the load axis values on the indicated torque table after adding forced induction?

  17. #77
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    I don't agree with Murphie on this one.

    I think that needing a linear distribution of axis values is a false assumption.

    Just look at stock GT tables, the RPM axis, the load axis, and the torque axis; of the TQ and inverse tables; all have a kink in them.

    Regardless of whether the axis value distribution is linear or not, the cell values are still related to an axis value, and you can use linear interpolation to look one table up from the other.

  18. #78
    Tuner in Training
    Join Date
    Feb 2019
    Posts
    26
    Quote Originally Posted by CCS86 View Post
    I don't agree with Murphie on this one.

    I think that needing a linear distribution of axis values is a false assumption.

    Just look at stock GT tables, the RPM axis, the load axis, and the torque axis; of the TQ and inverse tables; all have a kink in them.

    Regardless of whether the axis value distribution is linear or not, the cell values are still related to an axis value, and you can use linear interpolation to look one table up from the other.
    I'm a noob. I was getting quite a bit of IPC error. I've managed to cut it down considerably, but it's still causing trouble. I've scaled the Load axis on the torque tables up to 1.4 because I've added boost. I'm realizing that the values in my inverse tables are not exceeding 1.2. I think I need to scale up the torque axis on my inverse table in order to reflect the higher loads I'm obtaining. Originally I was thinking I could just use arbitrary values, but after reading this I'm wondering if I have to maintain a relationship between the two tables axis. I'm also wonder if part of the reason I'm having trouble tuning out the IPC error is because I didn't maintain this relationship when I initially scaled the torque table. I did attempt to scale them arbitrarily and used the built in calculator to populate the inverse table as a starting point. I now see values up to my max load, but I noticed that the values in the rows I didn't scale were radically different then they were before. Any suggestions?

  19. #79
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Quote Originally Posted by Boody78 View Post
    I'm a noob. I was getting quite a bit of IPC error. I've managed to cut it down considerably, but it's still causing trouble. I've scaled the Load axis on the torque tables up to 1.4 because I've added boost. I'm realizing that the values in my inverse tables are not exceeding 1.2. I think I need to scale up the torque axis on my inverse table in order to reflect the higher loads I'm obtaining. Originally I was thinking I could just use arbitrary values, but after reading this I'm wondering if I have to maintain a relationship between the two tables axis. I'm also wonder if part of the reason I'm having trouble tuning out the IPC error is because I didn't maintain this relationship when I initially scaled the torque table. I did attempt to scale them arbitrarily and used the built in calculator to populate the inverse table as a starting point. I now see values up to my max load, but I noticed that the values in the rows I didn't scale were radically different then they were before. Any suggestions?


    You don't need to maintain a relationship between the two axes, but you do need to make sure all your operating conditions are spanned by each axis range.

    Use the 3D view of these tables to keep the same slope and just project it out further:
    Attached Images Attached Images

  20. #80
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Not all TQ errors are cause by the TQ/inv tables though. Issues with your MAF transfer function and throttle body tables can be to blame. Possibly even speed density tables, if you are using cylair anticipation and filtering.