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
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.
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.
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.
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
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.
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
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.
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.
- Driver Demand takes RPM and pedal position to give a requested torque
- Reqested torque is run through the Torque / Inverse tables to look up a desired load
- Desired load is turned into a desired airmass (MAF rate)
- Desired MAF rate is run through the ETC tables (effective area / predicted angle) to give a throttle body opening angle
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
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?
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?
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.