Calibration Integrity of the 2010–2012 EcoBoost SHO HPTuners

So basically I reached a point where the existing commercial definition could no longer answer the question. Instead of guessing mechanically or globally increasing pressure, I obtained the OS documentation, identified the missing control path, and worked directly with an HP Tuners engineer to expose individual VFS pressure scheduling. Now the next test can separate insufficient commanded clamping force from an actual hydraulic or mechanical fault.

Got it!
Stock is 110 psi to all. We got some headroom. Just need to learn what that headroom is. Clutch pressure control is now here!

I called Sonnax hoping they could tell me more about the solenoid pressure capacity and they didn’t know. They said post on HPTuners forum and/or contact my transmission builder.

I spoke with Kevin Quinlan and this is what he said:
So I’m starting them at 132 psi. Since they are all 110 I’m changing them all. I don’t believe they’re going to need too much. 50% more pressure would be 165psi.

20% is a safe starting point. Now that the TCM is programmed to its native GUB firmware everything will be speaking the same language. I’ve added all these channels to VCM Scanner when I log
I’ll just do 5-6 laps around the house easy as it relearns bc I also cleared all adaptive learning. Then I’ll just take it easy. Attempt to see if it grabs or not. If it slips at all. I stop and go back home and review the log.

And if it all looks good I’ll add more pressure. But I suspect I’ll feel a difference in 2 ways. It being programmed in all GUB now. And that 20% increase is going to be felt…so we will see

Holy f shit. So I had my digital assistant help me setup TunerPro and make an XDF file to add scalars myself to HPTuners after buying a user defined license. It worked flawlessly! Check it out! It even sent me a dummy bin file to satisfy a TunerPro bug that was originally stopping me from completing a scalar. I downloaded it and uploaded it to TunerPro and it let me start making them. So f cool.
Next I’ll learn how to setup a 2D table

Hit a snag. Since I reprogrammed the TCM to GUB it altered my OS. Not recognized by HPTuners. I had to do a read on the ECU with it still tuned. Even though it was tuned it like auto restored every change to stock. I compared the new stock GUB file to my other stock file and they are at least identical in the software but definitely not the same strategy.
Before- DMJKBL5
After- DMJKB52

Cost me 2 credits. I already had 6 credits so it didn’t cost me anything.
The 13+ Tricore is Kryppto’s. I bought the MPVI3 from him.

So now I need to use the compare function and remake the tune file for DMJKB52.

I learned how to copy an entire table and paste it to the new stock file. That’s making redoing the file a lot easier. Not quite done but getting there.

I feel like I’m really starting to get the HPTuners workflow a little bit

I would be worried if I was a tuner honestly. AI is opening Pandora's box in many ways.

Yeah or tuners need to be on their A game. You can learn as you go but if you are working with a tuner who is really f good…you have no reason to check their work.

Ryan and I are having a conversation about driver demand torque request and the indicated engine torque tables and inverse.

He tried to say 500 driver demand lands on indicated engine torque as 500 and that’s 1.6 load.

But bc I have 100+ hours in my specific OS and looking at logs …everything I’ve done…I don’t take what he said like law. I say ok, then why did the last log I sent you request 478 brake torque in a WOT blip, not even a sustained pull, and that landed at 640+ torque in indicated torque and 2.0 load inverse? I didn’t even request the full 550 driver demand.

Crickets since I sent that. lol He’s had a lot of success with EcoBoost in general but his 30-60 min takes …if they are wrong…I catch them from my 100+ hours living in my specific OS only. I can still learn a ton from him but I see the file, I see what the car did and I can reconcile it. What he just tried to say actually has not been the case for any file or any log.

Quick debrief on the first DMJKB52/GUB transmission relearn. This is the working tune I rebuilt myself.

After flashing the native GUB firmware, programming the correct solenoid-body strategy and clearing the transmission adaptives, I ran the stock transmission calibration with only VFS_PRS_MAX changed from 110 to 132 psi across all seven VFS rows.

I drove for about 40 minutes. The recorded section was 12 minutes 14.5 seconds. I intentionally did not go WOT because the transmission was clearly still improving throughout the drive.

Log summary:
-Maximum APP (applied pedal position)was 44.5%, maximum engine speed was 4,620 rpm and maximum air load was 1.396.

• TFT increased normally from 173.4°F to 185.3°F.
• All six forward gears were used with 45 commanded gear changes.
• I did not see another sustained neutral-out or ratio-release event.
• Reverse was still present when I returned home hot, unlike the previous event.

The log also appears to have captured the adaptive learning in progress. Using the commanded 1–2 change until TSS/OSS ratio settled within approximately 1% of the expected 2nd-gear ratio and remained there for 0.15 second, the comparable 1–2 shifts at roughly 14–17% pedal progressed as follows:
1.135 sec
1.136 sec
1.024 sec
1.008 sec
0.944 sec

That downward trend under similar pedal input is strong evidence that the transmission was still learning and reducing the shift completion time. Because of that, I believe avoiding WOT during this drive was the correct decision. I want to give it at least another complete warm driving cycle or two, with repeated normal upshifts and coast-downs, until the shift behavior stops noticeably changing and reverse remains repeatably present hot.

The 132 psi VFS change is definitely active. Shift Solenoid C reached 131.984 psi during the drive, so the controller accepted and used the increased VFS_PRS_MAX value without requiring WOT.

However:
-Shift Solenoids A, B and D each peaked at approximately 109.939 psi.
-Line Pressure Desired reached 299.938 psi

We therefore need to determine whether the approximately 110 psi plateaus represent expected VFS latch behavior or whether another calibration item is still limiting those commands. I do not want to blindly force them higher without understanding the state logic.

Overall, this was a successful diagnostic relearn. The transmission completed repeated shifts, shift completion improved during the drive, the 132 psi ceiling was actually used, and reverse remained present hot. I think the next step should be more normal adaptation time plus exposing the latch and final-pressure information before the first WOT test.

Johnny gave me the green light to scout my OS and make my own definitions that will be useful. Check them, change a pressure and search my file, anything turned red means it’s already available. Present Johnny with a legit XDF file of confirmed working definitions and he will permanently add them to Green Oak 2368k for everyone.

This process is going to be light speed. There’s been a shift in the dynamic between my digital assistant and myself.

The first set of scalars I made with my digital assistant, Chuck, walking me through step by step, line by line how to make them in TunerPro. During this time Chuck impressed me big time by making and sharing a link for me to download a dummy bin file to satisfy a TunerPro bug. It worked……and I made the scalars with Chuck guiding me. Screen shots are a powerful tool. Hint.

So now that Johnny said yes, if you can make an XDF file and check your work it’ll save me a boat load of time. Mission accepted.

“Scout” is the project code name LOL. I was ready to start making XDF files again with Chuck but Chuck had other plans. Chuck made his own XDF file. And created a link for me to download. He was sending me a test. And what Chuck has done in the background leading up to this is absolutely astonishing and I’ll get to that next.

I uploaded Chucks test XDF. He remade Johnny table on his own and also created from the A2L a latch 1D table.
The test: I went in to his table and changed VFS6 to 110. Then I went into the permanent table Johnny made and it worked
Unbelievable. His latch 1D table captured OEM values. Interesting the 500 value.
Chuck is reverse engineering the 6F55.

Sharing screen shots of his test the process is validated. It took him just under 5 min to create this first test. And he cautioned to test just this so that errors don’t follow.

He then made a new XDF in less than 2 min with 7 new tables for me to validate. And in his definitions he is prepping Johnny because he lists the exact ECU ID and coordinates so Johnny gets the list of validated definitions and can quickly add them. Cutting his time down drastically.

The behind the scenes mastery. I downloaded David’s Excel A2L that he prepared to make it easier? Chuck made the first 4 definitions with me in TunerPro and we had them active right before Johnny added the real VFS 1D table 1-7 solenoids. Sharing screenshots we confirmed Chuck’s single scalar changed only Johnny’s VFS1 value. Then Chuck realized David’s A2L excel version had an error, assuming 0
=0 when in fact 0=1.

Chuck immediately asked if I had access to the raw A2L. I did. I fed it to Chuck and he reversed engineered how and why he got it wrong. He then corrected David’s A2L excel file. I sent David a corrected version. Now Chuck is using the raw A2L and the excel version and my screen shots of my tune file settings and I’m uploading my data logs to Chuck.

He is now making his own XDF files. He’s my eyes in the files and I’m his eyes to his results. This is going to get very interesting FAST

It gets better. Chuck advised to keep other conversations going in a new chat. He said leave this chat purely for expanding your OS. Sir, Yes Sir!!! Unbelievable

This 2010 ROM doesn’t stand a chance of hiding anything with Ford’s raw A2L of my strategy in the hands of a 2026 digital intelligence. I myself have been demoted to copy and paste boy. A position I gladly accept lmfao

@Sleeper.Solutions86 how stupid is AI now? I bet you’d like your A2L file and expose your OS definitions at will.

Ok we are at a checkpoint: Recap.

VFS maximum raised and proven active: 110 → 132 psi
-Stock latch and mapping architecture decoded
-Dormant hysteresis/precharge branches ruled out
-HP already exposes the shift starting-pressure maps
Strategy agreed:
-up to roughly +30% oncoming pressure at high torque
-roughly +20% static holding pressure
-leave offgoing pressure coordinated rather than blindly increasing it

Next we expose the stroke/fill, pressure-ramp, and post-shift holding layers

We have exposed static pressure and ramp rate previously missing from the operating system.

Kevlar Rev1
Kevlar Rev1 uses Ford’s original 6F55 hydraulic choreography, gives the oncoming clutch 30% more initial and ramp authority under meaningful load, gives the established clutch assembly 20% more modeled holding capacity, raises the VFS ceiling to support that demand, and leaves offgoing, fill, timing and protection logic intact.


That is an actual coherent transmission calibration, not a blanket line-pressure hack.

The full debrief is data dense. This is the summary.

Kevlar Rev1 isn’t a rescue tune built around a failure. It’s the first calibration that actually matches the hardware and the native GUB control architecture. What makes it different:
-GUB firmware is the correct native baseline.
-Ford’s gear-specific pressure relationships remain intact.
-Ford’s torque and turbine-speed contours remain intact.
-Ford’s fill, release, latch, adaptation, and protection logic remain intact.
-The capacity-producing parts of the strategy are strengthened for the Kevlar hardware.
-Static holding directly addresses the exact 3rd-gear failure mode.
-Oncoming start and ramp authority support the clutch before and during torque transfer.
-Stock TCC behavior removes the old GUC calibration’s aggressive loading contribution.

In practical terms, this is absolutely a bespoke, architecture-based calibration for my exact build.

And I didn’t get it from a pro tuner. That’s the wild part.

Just goes to show that fairly stock style builds don't need a lot of in depth changes. At this point it's a race car based off of a taurus. Not to downplay all of the cool things that the others in the market have done just nobody has pushed the platform to this extent to need this kind of detail.

Jordan_R said:

Just goes to show that fairly stock style builds don't need a lot of in depth changes. At this point it's a race car based off of a taurus. Not to downplay all of the cool things that the others in the market have done just nobody has pushed the platform to this extent to need this kind of detail.

Click to expand...

Yeah that’s fair. Especially now as I’m coming to where I believe respecting the underlying Ford strategy is the key.

Rather than create a new Ford strategy, enhance the existing model to support the hardware.

Same thing I’ve been working ******* with the torque model on the engine side. I believe the key is to respect the math, enhance it to support the new hardware.

Let the controller retain the logic and control architecture. Don’t disable x, y and Z and raise limits, then use a spark inefficiency and torque loss to weaponize its panic of satisfying the torque model by grabbing airflow and then intentionally clip the pressure settings and say look at that wonderful calibration I made when really it’s full of math errors and torque losses.

I respect the math so I want to make it agree with what it’s doing and see no reason intervene essentially, it’s in the background smoking a cigar because everything is running smoothly

I’m basically a product of my own design at this point because there’s nobody that’s gonna spend hundreds of hours on this but me and feeling like I was 30% capable I had to try but then knowing where I came from with limited resources, experience and knowledge to get this far well now I also think that an accomplished Tuner would have as well just unfortunately, I never met that Tuner.

My list of mods have been the same. It’s just now I’ve been able to actually support some of my own hardware to a degree I believe is satisfactory.

And somehow, I’m actually currently underwriting new definitions to be permanently added to my operating system that benefit every other 2010 to 2012 SHO owner.

The calibration philosophy ended up being pretty simple:

Preserve Ford’s curves.
Preserve Ford’s timing.
Preserve Ford’s protections.

Increase the clutch authority where the hardware can support it. Test.

Had to steal this from Chuck. So true.

Kevlar Rev1 is basically walking up to the controller and saying:
“You’re still in charge.
Your math is still good.
The hardware just got stronger.”

That’s a very OEM way of solving an aftermarket problem.

Now comes the fun part:
Data wins arguments.
The next log will tell us:
-Did shift times improve?
-Did calculated slip reduce?
-Did adaptives calm down?
-Did line pressure behave the way we expected
-Did GUB and Kevlar finally start speaking the same language?

That’s where theory becomes calibration.

And if the first logs come back clean, you’ll have something pretty unusual:

A native GUB transmission calibration built specifically around upgraded friction hardware while retaining Ford’s control philosophy.

That’s not a pressure hack.
That’s an engineered solution.

**** yeah

Kevlar Rev1 in the history books! The GUB firmware TCM program was the key! It picked up right where I left off, quick, crisp low speed, low-mid throttle shifts. Outstanding! I’m going to email Forscan bc I think they’re message about GUB and GUC is very misleading. Program to GUB (less risky) or program to GUC (more risky but more new firmware could work better) that’s what led me down the GUC path. The new TSB updated valvebody was intended for GUC but it’s listed as compatible for one firmware older GUB. So they need to warn people the opposite way. Something like flash to GUB (highly recommended) or flash to GUC (intended firmware but more risky and may not work better). That would align with my real world experience.

What’s surprising is even my paddle shifters were faster. Now bc the static and ramp torque arrays where previously unmapped in my OS….im not sure if the speed increase is GUB alone or the increased ramp pressure to take the next clutch. But its way better.

Low load was fine and moderate throttle it felt firmer. 3-4 is probably the fastest shift. Downshift is more firm bc all the oncoming clutches are stock x1.3 pressure increase too in the oncoming and skip clutch settings already provided in HPTuners. Not harsh, just firm.

As I drove around for a little less time than last time (about 30-35min) I was absolutely loving it. No more awkward slow and delayed shifts just going through the gears quickly more like a normal coherent vehicle.

I played a little in manual mode and this is when I noticed 4-5 manual had a delay but I also would do 4-5 and then let off as I was speeding and it would delay and catch 5th.

Now when I attempted to go WOT this is where the magic happened and also my foot told on me.

I floored it and I downshifted from 5-3 and went 3-4 and then 4-5 and let out. 5-3 was aggressive but smooth, 3-4 was fast and firm and 4-5 did the delay again. Ford actually assigns 4-5 and 5-6 less pressure by default which ties into the overall stock power settings but in this car it’s not adequate, not even already with a tiny increase.

So that right there, moderate throttle 4-5 delay and WOT delay we captured the same delay and flare so we had a direct target to clean up for Kevlar Rev2. I’ll get to that part in one moment.

So the part about my foot telling on me…..my OSS modifier settings of 1:1. If I ask for it with my foot…I get it. And I didn’t ask for it like I thought I did. I went about 75% and then backed off low 60% and during the 4-5 I let off even more some. I don’t really realize I’m doing this. But bc I set it to 1:1 it did exactly what my foot said. And my foot is cautious come to find out lmfao.

So I never went WOT. Pedal position reported part throttle. It’s interesting bc I’ve only seen it report part throttle since I changed OSS to 1:1. So I am relenting on this despite simply trying to floor it. In the last 3 rows of pedal position I have now added back some OSS modifier, essentially it multiplies what your pedal position actually is. So now if my foot does the same thing I won’t ruin a pull, but you have to get deadly with math (edit) bc you don’t want to multiply too much and ask for more than your max Driver Demand requests before your foot actually floors it. So I’ve done it like this 1.025, 1.050, 1.075, 1.1, 1.2x 1.25. So as I put my foot down half way I’ll hit near max pedal position and not breach my Max request. But as my foot (if I push hard enough lol) continues to press the pedal further it’ll ramp back to 1:1. I can basically handicap my cautious foot. If I press it hard once and get the response…if my foot backs off I’ll lose maybe 28 lb.ft but I still need to floor it for max request. So it looks like this:
62.5% pedal ≈ 528 lb-ft
67.5% pedal ≈ 556 lb-ft
74% pedal ≈ 575 lb-ft
100% pedal = 630.5 lb-ft

That’s a much more progressive and coherent setup. OEM settings use pretty aggressive multipliers even one set to 1.7. So this is taking another slice out of the OEM strategy just a little more control but not too much control back to me as my foot is a wimp lmfao.

Which brought me back around to see that Ryan was fundamentally right about his Driver Demand request. How it lands on indicated engine torque. 500 Driver Demand request with pumps and losses added back to it make it around 560 on IT. Which lands around 1.7-1.8 load. So thinking I would hit 2.0-2.2 load with a 500 Driver Demand max request was not supported by the log.

The next revision is taking a play out of Ryan’s handbook. It’s Ryan’s last Driver Demand, his preignition table, his pressure settings. So we should make 2.0-2.1 load.
And it’s Kevlar Rev2. We added a bump in pressure for the ramp of 4-5 gear change along with went back to 4-5 oncoming clutch and we did stock X 1.5 from 100-350 rows so only under moderate load + does 4-5 receive 50% more pressure. Combined with the ramp pressure increase, 4-5 gear change should come with more authority and grab harder too. I suspect on the next log 4-5 is cleaned up. And we have OSS modifier back in play to make my skiddish foot reach closer to true WOT even if it falls back.

But my mission is clear. Stomp the pedal to the floor. No lift, all data

From Chuck
F U Chuck hahahaha little digital douche

Nope. Going back to my Driver Demand max 500. From pure curiosity I was exploring the A2L with Chuck and we found and exposed this inverse torque load clip.
Hmmm how can that be? I’ve never seen load enforced that low. We exposed several more in a Scout pack to see the OEM values. Nothing special but we found it very interesting and it’s a real definition.

Went to bed and this morning I was looking at it and wait a min….max load on my last log was 1.46. Chuck, run the Kevlar Rev1 datalog and look for this clip being enforced. I told Chuck, “Even though my OSS modifier was 1:1 and my foot was cautious, check this clip.”

Chuck:
Yes. This log makes it look like the clip was absolutely active.

Both things happened in sequence:
-Pedal position correctly selected a partial-pedal Driver Demand torque.
-That torque was converted to indicated/scheduled torque.
-The inverse table calculated a higher load.
-FNTQE_INDINV_CLP then capped that inverse output.

At the maximum-load point:
-4,504 rpm
-63% pedal
-Desired Brake Torque: 447.9 lb-ft
-Scheduled Torque: 501.3 lb-ft
-Desired Load: 1.4665
-Interpolated inverse-table result from 501.3 lb-ft: approximately 1.61
-Interpolated clip value at 4,504 rpm: approximately 1.470

The PCM delivered 1.4665—essentially the clip value, not the unrestricted inverse result.

Your partial-pedal DD request also makes sense. At roughly 63% pedal and 4,500 rpm, the Driver Demand table lands around 445–450 lb-ft, which is exactly the 447.9 lb-ft logged. So Driver Demand itself was behaving correctly. But after the brake-to-indicated conversion raised that to roughly 501 lb-ft, the inverse model wanted about 1.61 load and got chopped to 1.47.

That first row is particularly valuable. Before the inverse result reaches the clip, Desired Load follows the inverse table normally:

1.222 inverse < 1.391 clip → 1.220 logged

Then, once requested torque raises the inverse result above the curve:

1.455 inverse > 1.383 clip → 1.383 logged

That is basically a live demonstration of:

Desired inverse load ≈ minimum(raw inverse result, FNTQE_INDINV_CLP)

The strange falling Desired Load through the upper rpm range is also exactly the clip:

-Around 4,500 rpm: approximately 1.47
-5,000 rpm: approximately 1.46
-5,650 rpm: approximately 1.38
-6,200 rpm: approximately 1.33

Your logged Desired Load follows that same taper. Pedal position alone does not explain that precise rpm-shaped decline.

For a true 500 lb-ft Driver Demand request that becomes approximately 560 lb-ft indicated, the inverse table would calculate roughly:

-3,000 rpm: 1.74 load
-4,500 rpm: 1.76
-5,000 rpm: 1.77
-5,650 rpm: 1.77
-6,000 rpm: 1.78

But the current clip would only permit roughly 1.35–1.47. So yes—this little bastard is not theoretical. You hit it at only 74% maximum pedal, and then continued riding it through the pull.

Holy F shit. I then asked Chuck: in the log was the PCM closing throttle actively enforcing this clip?

Chuck: The PCM closed it. Your foot set the demand, but the large throttle closure was commanded by torque control.

Here’s the smoking gun:
At about 231.51–231.77 seconds, your pedal stayed dead steady at 69%.

During that same quarter-second:
-Desired Brake Torque stayed essentially fixed at 459 lb-ft
-ETC Torque Request stayed fixed at 459 lb-ft
-Desired Load rose to about 1.46—the hidden clip value at roughly 4,450 rpm
-Throttle Desired Angle collapsed from 80.2° to 29.5°
-Actual Throttle Angle followed from about 82° to 30°
-Throttle Position fell from essentially 100% to 36.5%

Your foot did not cause that. The PCM explicitly changed the desired blade angle while APP and requested torque remained constant.

Even more revealing, actual Air Load overshot to roughly 1.57 while Desired Load was stuck around 1.46. The PCM had already capped the inverse result, saw actual airflow exceed that clipped target, and closed the throttle hard to pull actual load back toward it.

So the sequence was: 69% APP → ~459 brake torque request → ~511 scheduled torque → inverse model wants more than ~1.46 load → hidden RPM clip outputs ~1.46 → actual load overshoots → PCM closes throttle

Your foot did move during other parts of the pull—you initially reached about 74%, dropped to 69%, and later tapered farther—but that only changed the requested torque modestly. It cannot explain a throttle blade going from fully open to approximately 40% while APP sat perfectly still.

Also, the closure continued after Torque Source returned from Trans Shift Mod to Driver Demand. So this was not merely the transmission requesting a shift reduction. Throttle Angle Source remained Torque Control, and the requested blade angle itself dropped first. That is definitive ETC intervention.

The really sneaky part is why your ordinary channels did not announce a limiter:

-Driver Demand Limit Source continued to report No Limit Active
-Torque Source reported Driver Demand
-ETC Torque Request still matched your requested brake torque

Because this clip is apparently inside the torque-to-load inverse conversion. The PCM was not clipping the displayed Driver Demand torque request—it was silently clipping the calculated load needed to produce that torque. Then the normal ETC controller closed the throttle to obey the lower load target.

As for the GUC/DMJKBL5-to-GUB/DMJKB52 change: that is now a very credible explanation for why this behavior suddenly appeared. I would phrase it carefully as:

DMJKB52 demonstrably enforces this inverse-output clip in the active Driver Demand path.

We still cannot say whether DMJKBL5 lacked the curve, had different values, or simply did not call it under the same conditions without comparing that strategy. But in this GUB log, the PCM absolutely rode the hidden curve and used the throttle to enforce it. This is a huge find.

My Driver Demand is back in play. We will see what it really can do with OSS modifier giving my foot more power and we’re using this clip as a safely limit choosing out load ceiling. As follows
Smoothed up to about 3750rpm then in case something goes South we shut the party down at 2.1 load! Unbelievable! I am learning and expanding my operating system simultaneously. Didn’t even mean to find this hidden mother f u. C k e. R

Boom
That’s DMJKBL5!!!!!!! It was raised to 3.0 somehow.

From Chuck:
We didn’t merely find a plausible limiter. We found the exact calibration change between the two strategies that caused the new behavior. Honestly, this is the kind of limiter I would keep intentionally. Instead of defeating Ford’s protection, we converted a badly calibrated hidden restriction into a useful safety tool.

Me: Now to comb through and try to figure out what settings could raise it indirectly. I’d much rather keep it active as a safety limiter. Choosing my load ceiling opposed to raising it to the moon and letting anything happen. Edit: who cares what indirectly raised it previously we have full control of it now and will be using it as a safety limiter