The tune is ready, the car is ready for its next test hit.
I actually heard from Ryan earlier this week. He said I’m getting caught up from other the weekend and I’ll send you a file. I said, let me send you mine….plot twist.
Ryan made changes to the tune. He raised pressure limits and he ramped spark instead of my top end flat curve and he extenders the last rows of my Driver Demand. This looked very tempting and I was happy he made the changes he thought would be good to help the car.
But then I ran a mathematical audit on it and I kept seeing that it was actually making the math even more imbalanced. What David and I keep doing is respecting the torque model math. And I had to let go of arbitrary numbers and balance it and that meant doing something counter intuitive, lowering my driver demand.
The order of operations goes like this:
Driver demand (your gas pedal)
IT (indicate torque adds pumps and losses)
Inverse torque mirrors IT.
David had spent some time in excel using Garrett G25-550 turbo flow data and what he already knew from working on tuning his ‘13 SHO. That’s what our new IT and inverse are.
So the indicated torque and inverse tables are David’s. The runaway tune wasn’t based off turbo flow data but they were an extension of the OEM model scaled to 2.2 before we took capacity to heart. What we learned is why it ran away. His Math is nearly perfect. But he forgot to take into consideration OSS modifier so there was a 1.2 multiplier running in the background for the driver demand WOT request.
His original Driver demand request + the 1.2 multiplier + pumps and losses were requesting over 800 torque in the indicated torque and 2.6 load in inverse. That’s why the car wanted to fly off the 2.2 IT torque table, realized the massive torque loss and to hit its torque target it needed a lot more airflow. The torque model protects its target. It will automatically clamp the wastegates shut to attempt to satisfy the request. Which led to 24+ psi boost, 3.5 knock retard, 2.38 load and 64lb.min turbo airflow and PCM intervention bc it ran off the torque map. It did protect itself from our mistaken request only after trying to satisfy it.
This is where we started respecting the math. Life or death type of respect. I keep seeing in the logs the ECU carrying out the calibration exactly how it’s been asked to work. It keeps getting stuck in math errors. Math errors are torque errors. It’s balancing the main 3.
Driver demand
IT
Inverse.
Load and boost are directly connected. If you can mathematically plot your load based off your driver demand request you can predict desired boost. And I’ve been using an AI assistant to use data logs from this year to correlate peak load and peak boost and wgdc%. Not guessing. Using data of what the car actually does.
It’s intimidating until you realize ok, we need to mathematically align 3 tables. The order of operations begins with Driver Demand but the IT and inverse are what needs to be mathematically aligned together first. Then your groom Driver Demand to them and remember what you’re asking. Driver demand is the smaller number. That is embedded into my head now. I’m not asking for 500 when my Driver demand requests 500. With pumps and losses I am requesting just over 700 torque in the IT table and that corresponds with 2.19 load. And to make 2.19 load my car has shown it takes around 20 psi boost.
Another catch is efficiency losses. Spark. When I commanded a flat top end of 14 spark the ECU (still thinks it’s a stock 3.5 and stock turbos) and it gets my right foot driver demand request, and sees that 14 spark is nearly 20 spark away from MBT, realizes it’ll never meet my torque request (which at this time was 550) so it said, “This spark is too weak to hit my target I need more airflow.” It clamped my wastegates shut and used my TIP max to make 20-21 psi boost wirh only 49% pedal ….but in log my throttle angle went just over 80 degrees. The ECU stomped the pedal, overrode my foot! It is absolutely fascinating.
I’m slowly piecing it together and I was thinking shit, bc it’s not reacting the way I wanted let’s lower spark to 13. So Ryan ramped spark to 13 but he then upped my Driver Demand to 630-640.
So wait a second. That’s increasing efficiency losses with spark. I’d be asking for even more torque and even less spark. The data is saying that is 100% the wrong direction.
What I had to realize is it’s just balancing the math. That’s all it is. And letting go of arbitrary numbers like my 550 driver demand request I’ve dropped it to 500. Bc now I know the main number I’m requesting is in IT (indicated torque). Which calculates to around 700 Tq. And that calculates to about 2.19 load.
And I’ve relented on spark. But I liked Ryan’s spark ramp so I mimicked his ramp and I peak at 16 spark from 5500-6500 although we are commanding shifts back to stock values.
By reducing my Driver Demand request from 550-500 I have reduced spark inefficiency but also improve it by adding back 2 spark. So the car shouldn’t freak out like last time and stomp the throttle open.
Our load target, our Driver demand request and IT torque request all mathematically align within the torque model. We won’t be hitting any torque limits and bc the math itself checks out we have no gross toque losses.
Bc I know 2.19 load is around 20-22 psi boost I’m ok with that and I raised pressure limits. Before I was curious if it would want to steam roll over my anticipated boost level …..and I caged it in with limiters. But now I am curious if it will hit my target and naturally I have dropped my guard.
This isn’t guessing the tables were mathematically on par in the last test hit verified by the log but I didn’t realize I was asking for so much IT torque too focused on my Driver demand request. And I didn’t realize the efficiency losses of too low of spark.
David and I are ready. He thinks I’ll hit 18-19 psi boost to satisfy the torque request and I’m prepared to see 23 max. But either way….we aren’t wondering what load or what IT we have it set to. It’s intentionally mathematically requested.
Also from real data I’m at 30% wgdc down from 35 in the last test hit to see how close it is and I know it’s in the pocket just idk if it’s a bullseye dead center but I believe it’s in the bullseye perimeter.
This torque controller is about to get obedient. The throttle should stay open and we will have a real pull.
And I can’t stress enough the ability to look at the tune file. Bc I solved Ryan’s (idk why it keeps clamping to Engine speed) torque source at WOT.
He originally had OEM TCM engine speed values that maxed at 6200rpm. But he had changed gear rpm shifts to 6500rpm. So what happened was simple. He was basically asking , “Can you shift 300rpm past your limit?” And the TCM said…LOL…so when I went WOT, Torque Source is reporting WHO is in charge. So it would report engine speed even before the rpm of 6200 bc it’s saying ,”You asked for WOT but your engine speed limit is the authority bc you’re asking for more than 6200rpm.”
Then Ryan caught on but he matched engine speed limit with his shift request so it had no transient room. And the second I went over 6500 it would report: engine speed limit.
Even OEM allows 200 extra rpm for shifts. But even though we are back to OEM rpm shifts reducing variables we left engine Speed limit at 6500 incase we blow the tires off.
You see? It’s all in the file exactly the orders the ECU will execute. So the money authorities are
Torque source: driver demand
Spark source: preignition
Spark source might change as we switch to ethanol but we’re wanting preignition to be the final authority on 93.
Otherwise if we see something else in Torque Source: like engine speed limit or Ind.engine.tq limit it’s essentially a neon sign saying this table has math errors. It tells on itself and that’s a massive diagnostic tool.
I actually heard from Ryan earlier this week. He said I’m getting caught up from other the weekend and I’ll send you a file. I said, let me send you mine….plot twist.
Ryan made changes to the tune. He raised pressure limits and he ramped spark instead of my top end flat curve and he extenders the last rows of my Driver Demand. This looked very tempting and I was happy he made the changes he thought would be good to help the car.
But then I ran a mathematical audit on it and I kept seeing that it was actually making the math even more imbalanced. What David and I keep doing is respecting the torque model math. And I had to let go of arbitrary numbers and balance it and that meant doing something counter intuitive, lowering my driver demand.
The order of operations goes like this:
Driver demand (your gas pedal)
IT (indicate torque adds pumps and losses)
Inverse torque mirrors IT.
David had spent some time in excel using Garrett G25-550 turbo flow data and what he already knew from working on tuning his ‘13 SHO. That’s what our new IT and inverse are.
So the indicated torque and inverse tables are David’s. The runaway tune wasn’t based off turbo flow data but they were an extension of the OEM model scaled to 2.2 before we took capacity to heart. What we learned is why it ran away. His Math is nearly perfect. But he forgot to take into consideration OSS modifier so there was a 1.2 multiplier running in the background for the driver demand WOT request.
His original Driver demand request + the 1.2 multiplier + pumps and losses were requesting over 800 torque in the indicated torque and 2.6 load in inverse. That’s why the car wanted to fly off the 2.2 IT torque table, realized the massive torque loss and to hit its torque target it needed a lot more airflow. The torque model protects its target. It will automatically clamp the wastegates shut to attempt to satisfy the request. Which led to 24+ psi boost, 3.5 knock retard, 2.38 load and 64lb.min turbo airflow and PCM intervention bc it ran off the torque map. It did protect itself from our mistaken request only after trying to satisfy it.
This is where we started respecting the math. Life or death type of respect. I keep seeing in the logs the ECU carrying out the calibration exactly how it’s been asked to work. It keeps getting stuck in math errors. Math errors are torque errors. It’s balancing the main 3.
Driver demand
IT
Inverse.
Load and boost are directly connected. If you can mathematically plot your load based off your driver demand request you can predict desired boost. And I’ve been using an AI assistant to use data logs from this year to correlate peak load and peak boost and wgdc%. Not guessing. Using data of what the car actually does.
It’s intimidating until you realize ok, we need to mathematically align 3 tables. The order of operations begins with Driver Demand but the IT and inverse are what needs to be mathematically aligned together first. Then your groom Driver Demand to them and remember what you’re asking. Driver demand is the smaller number. That is embedded into my head now. I’m not asking for 500 when my Driver demand requests 500. With pumps and losses I am requesting just over 700 torque in the IT table and that corresponds with 2.19 load. And to make 2.19 load my car has shown it takes around 20 psi boost.
Another catch is efficiency losses. Spark. When I commanded a flat top end of 14 spark the ECU (still thinks it’s a stock 3.5 and stock turbos) and it gets my right foot driver demand request, and sees that 14 spark is nearly 20 spark away from MBT, realizes it’ll never meet my torque request (which at this time was 550) so it said, “This spark is too weak to hit my target I need more airflow.” It clamped my wastegates shut and used my TIP max to make 20-21 psi boost wirh only 49% pedal ….but in log my throttle angle went just over 80 degrees. The ECU stomped the pedal, overrode my foot! It is absolutely fascinating.
I’m slowly piecing it together and I was thinking shit, bc it’s not reacting the way I wanted let’s lower spark to 13. So Ryan ramped spark to 13 but he then upped my Driver Demand to 630-640.
So wait a second. That’s increasing efficiency losses with spark. I’d be asking for even more torque and even less spark. The data is saying that is 100% the wrong direction.
What I had to realize is it’s just balancing the math. That’s all it is. And letting go of arbitrary numbers like my 550 driver demand request I’ve dropped it to 500. Bc now I know the main number I’m requesting is in IT (indicated torque). Which calculates to around 700 Tq. And that calculates to about 2.19 load.
And I’ve relented on spark. But I liked Ryan’s spark ramp so I mimicked his ramp and I peak at 16 spark from 5500-6500 although we are commanding shifts back to stock values.
By reducing my Driver Demand request from 550-500 I have reduced spark inefficiency but also improve it by adding back 2 spark. So the car shouldn’t freak out like last time and stomp the throttle open.
Our load target, our Driver demand request and IT torque request all mathematically align within the torque model. We won’t be hitting any torque limits and bc the math itself checks out we have no gross toque losses.
Bc I know 2.19 load is around 20-22 psi boost I’m ok with that and I raised pressure limits. Before I was curious if it would want to steam roll over my anticipated boost level …..and I caged it in with limiters. But now I am curious if it will hit my target and naturally I have dropped my guard.
This isn’t guessing the tables were mathematically on par in the last test hit verified by the log but I didn’t realize I was asking for so much IT torque too focused on my Driver demand request. And I didn’t realize the efficiency losses of too low of spark.
David and I are ready. He thinks I’ll hit 18-19 psi boost to satisfy the torque request and I’m prepared to see 23 max. But either way….we aren’t wondering what load or what IT we have it set to. It’s intentionally mathematically requested.
Also from real data I’m at 30% wgdc down from 35 in the last test hit to see how close it is and I know it’s in the pocket just idk if it’s a bullseye dead center but I believe it’s in the bullseye perimeter.
This torque controller is about to get obedient. The throttle should stay open and we will have a real pull.
And I can’t stress enough the ability to look at the tune file. Bc I solved Ryan’s (idk why it keeps clamping to Engine speed) torque source at WOT.
He originally had OEM TCM engine speed values that maxed at 6200rpm. But he had changed gear rpm shifts to 6500rpm. So what happened was simple. He was basically asking , “Can you shift 300rpm past your limit?” And the TCM said…LOL…so when I went WOT, Torque Source is reporting WHO is in charge. So it would report engine speed even before the rpm of 6200 bc it’s saying ,”You asked for WOT but your engine speed limit is the authority bc you’re asking for more than 6200rpm.”
Then Ryan caught on but he matched engine speed limit with his shift request so it had no transient room. And the second I went over 6500 it would report: engine speed limit.
Even OEM allows 200 extra rpm for shifts. But even though we are back to OEM rpm shifts reducing variables we left engine Speed limit at 6500 incase we blow the tires off.
You see? It’s all in the file exactly the orders the ECU will execute. So the money authorities are
Torque source: driver demand
Spark source: preignition
Spark source might change as we switch to ethanol but we’re wanting preignition to be the final authority on 93.
Otherwise if we see something else in Torque Source: like engine speed limit or Ind.engine.tq limit it’s essentially a neon sign saying this table has math errors. It tells on itself and that’s a massive diagnostic tool.
