Calibration Integrity of the 2010–2012 EcoBoost SHO HPTuners

[802SHO]

I have been working through a complex set of tuning challenges on the 2010–2012 EcoBoost SHO platform. There has been a significant amount of misinformation circulating regarding the capabilities of this OS, particularly concerning fuel system scaling and hardware management. To clear the air and ensure others on the platform have access to accurate information, I want to present a technical audit of my findings based on actual, verifiable data.

A recent video produced by SleeperSolutions claimed that the 2010–2012 OS is "hardware limited" and essentially un-tunable for aftermarket fuel system upgrades because it lacks specific "injector profiles" and "HPFP parameters" found in newer operating systems. The presenter asserted that because these specific parameters are not visible in his editor, they must not be adjustable, further claiming that this results in a "20% loss" of HPFP volume.

The empirical data directly refutes these claims. If we look at the live logs from my R7 and R8 sessions, we can see the fuel rail pressure climbing steadily and maintaining over 2,200 psi under wide-open throttle conditions. If there were a 20% loss in volume due to unscaled parameters, the system would be physically unable to sustain this pressure. These logs prove the fuel system is stable, high-performing, and fully under PCM control, regardless of the parameters visible in the standard GUI.

I also want to point to the most objective indicator of fuel system health: oil analysis. I have included my oil reports from October 2025 and April 2026 for comparison. Despite a period of heavy electrical diagnostics and extensive, excessive idling, the April 2026 analysis shows no abnormal fuel dilution. Fuel contamination is the hallmark of poor injector scaling or inadequate fuel system control. The fact that these reports show no significant fuel in the oil confirms that my XDI60 HPFP and XDI2000cc injectors are being managed with precision. Fueling is not a bottleneck, and it is not a concern for my calibration team.

The performance "dips" we previously observed were not caused by the fuel system; they were traced to Electronic Throttle Control (ETC) intervention enforced by an internal torque-calculation ceiling. We have successfully worked with HP Tuners engineering to expose previously hidden definitions, such as the Brake Torque Limit (ID 3049), which was the actual cause of these interventions. The fact that we arrived at HP Tuners to solve these specific torque issues, without needing to ask for "missing" fuel definitions—proves that those definitions are already present and functioning as intended for this hardware.


It is a fundamental error to judge the 2010–2012 OS through the lens of newer 2013+ definition standards. True tuning expertise is measured by results on the specific OS being modified, supported by logs, and verified by physical engine health data like oil analysis. The insistence that this platform is "broken" or "un-tunable" regarding fueling, despite contradictory evidence from lab reports and live logs—indicates a significant gap in platform-specific knowledge.


When a tuner prioritizes speculative theories based on an incomplete understanding of available table architecture while ignoring empirical, log-based evidence, it creates a high-risk environment for the engine's longevity. I believe the methodology currently being advocated for this platform demonstrates an insufficient understanding of how to properly access and utilize the existing table architecture.

Given that this lack of understanding likely permeates his approach even on his preferred 2013+ platform, he is demonstrably not a qualified tuner for the 2010–2012 SHO. SLEEPERSolutions should not be tuning these cars, nor should he be speaking with any authority on their capabilities.

My recommendation to the community is clear: avoid engaging with this individual for any tuning needs, as doing so places your engine at unnecessary and preventable risk.
Engage at your own risk.

 

[Sleeper.Solutions86]

Me big danger. AI guy said so.


Sent from my iPhone using Tapatalk

 

[802SHO]

 

[802SHO]

I was just talking to my buddy Brendan V up in Canada, and his take on this whole situation makes a ton of sense. It’s a great addition to the discussion and helps clarify where the disconnect might be happening.

To understand why Brendan's perspective is so valuable, you have to look at his background. Before he got into tuning, he was training to be a psychologist. That discipline prides itself heavily on teaching the scientific method, and he took that rigorous statistical and lab training and applied it to his current work. It really shapes how he looks at this platform. He maintains total openness—if new data presents itself, he absorbs it. He isn't emotionally attached to a single result or a single hypothesis. As Brendan elegantly put it, "That salient neutrality has to be maintained, in life in general especially with stuff like this." He lets the physical data dictate the conclusion, which is exactly the lens we need to view this ECU debate through.

Brendan has spent a lot of time working on the newer Copperhead ECUs. He mentioned that on certain models (like an '18 Explorer), the ECU actually wouldn't run the XDI pump without having proper scalars added. But the catch is that those scalars simply don't seem to be needed for our older Green Oak PCMs. The fact that my car and David's car run the XDI perfectly fine without those specific voltage tables or max Amp scalars suggests his hypothesis probably doesn't apply to this platform.

It seems like he might be taking what is true for a Copperhead ECU and extrapolating it backward to the Green Oak, operating under the assumption that it has the exact same requirements.

Brendan brought up a solid point about the injector profiles, too. Yes, the Copperhead has tables for an injector profile. It was likely designed that way so Ford could easily adapt larger injectors for racing variants—select a profile, and it instantly changes the calculations to match the flow rate. But there’s not necessarily a reason to assume the older OS needs that level of profiling. On ours, we have an adjustable injector flow rate that can be mapped directly. You increase the flow rate, and the math changes based on that. It’s a simpler strategy, which implies a complex "profile" might not be inherently required for it to function correctly.

The electrical side of the theory follows a similar logic. The newer OS was likely designed to strictly protect the factory pump from too much voltage or amperage (preventing blown fuses or sensors), which would literally require you to increase the electrical load limit in the software for a larger pump. Brendan suspects the older OS either works off a much simpler design for limiting load, or those early 2010–2012 HPFPs naturally had a similar voltage and amperage capacity to the XDI, despite having a lower overall flow rate.

Ultimately, a lot of this comes down to understanding the tuning software itself. This is similar to what we saw with Matt from Gearhead. Sometimes people look at the user-friendly versions of the tuning software and assume that if a table isn't visible, the hardware can't function. The reality is that the engineers behind the scenes can unlock and code essentially anything the OS is capable of handling. It gets frustrating when assumptions about these software limits are stated as cut-and-dry facts, confusing a missing menu option with a hard physical limitation. Right now, the physical data we're logging is pointing strongly in one direction, and keeping that salient neutrality is the best way to keep the facts in perspective.

 

[802SHO]

Limits: Missing Engine brake torque was added to torque management. Allowing the OEM 369 lb.ft limit (500nm) to be visible and editable to 5,000 nm.

The next limit is the Indicated engine torque and indicated engine torque inverse tables. Previously couldn’t scale above 2.0 load. It’ll be scalable to 5.0 load later today, next Beta release.

Load is essentially airflow the motor can make. Think of 1.0 load as 100% airflow. 2.0 load is double the normal air mass entering the cylinders. My car reached 1.922 load, which means it was operating at nearly twice the airflow of naturally aspirated state. Ford set the max limit to 2.0 thinking nobody would ever need more. Once you exceed that modeled range, the PCM switched torque sources and identified the next bottleneck in the torque model, the model itself

Which will now be adjustable

 

[802SHO]

I’m working mostly with David Siebert II right now and we are working on the torque model pretty heavily.

We’ve basically separated capacity from demand. Which is likely what every successful tuner does…..so this isn’t something we’re starting it’s more of saying….we found this state on our own.

What I kept seeing in my observations while using the compare file function is the massive headroom the OEM calibration gives the car. It’s already setup for massive capacity VS what it’s demanding.

OEM indicated torque hits a load axis of 1.9 and 500+ torque. Meanwhile it’s capped at 369 engine brake torque….and many other factors but do you see how much leg room the ECU has? It’s mathematically plotted and expanded so essentially there’s no point where the ECU doesn’t know what to do. My assumption ….its an assumption….but my assumption is I bet that torque model doesn’t change when ppl start doing a tune. More boost and more power and it can operate within that massive headroom setup by Ford engineers. So it requires no edit up until a certain power level. Not saying nothing gets edited but I have a feeling that generous torque model can hangout unedited for a while.

It seemed like my car kept hitting the edge of the model. 1.9 hit it. 2.2…hit it. Then I realized that’s not how you do it. You don’t try to edit the torque model for what demand you want today. It’ll always be a battle or hitting the fence and unnecessary interventions. So looking back at the OEM model with a 1.9 load ceiling it all clicked.

We expanded the torque model to 2.6 to give us capacity. And we didn’t add rows. David went into excel and mapped our new torque and inverse tables completely keeping the original 10 rows. He rescaled driver demand and OSS. We now have mathematically given the ECU OEM like capacity for the new hardware. There isn’t a point where it isn’t in complete control.

What I mentioned before about tuning for today. What do we want to tune for today’s goal? We don’t want to tune it to capacity….that’s why that’s been expanded. We want to tune demand for today. Demand operates within the capacity and the ECU has no blind spots.

We are still learning how the G25’s behave relative to WGDC, so the demand gets hard capped. We want to command a pressure limit of 69.22 inHG which is 34 psi absolute. Minis BARO 14.7 psi it’ll put the turbos at 18-19 psi boost. WGDC% is set to .25 and we also gave the turbo a failure limit of 60 lb.min so if it behaves differently than we expect the PCM will drop spark and the throttle. So we have tuned our demand within the capacity with a fence. And spark hard capped at 16.

Then load can fall where it falls. 2.0? ECU says no problem. 2.1? ECU says sure. 2.34? ECU says yup and? It says we got 2.6 load here.

But it’s hard capped to 16 spark and 60 lb/min. 60 gives it some wiggle room bc if we set turbo failure to 58 lb/min that’s right on the edge of 18 psi. We don’t want to clip it.

Just think about it. If you can do a back flip within 6’ you wouldn’t do a back flip in a 6x6 enclosed space. You need room. What does everyone do? Back up and give you room. Give you space. The ECU calibration is no different. Scale the capacity for the new hardware and then demand your back flip so it has room to land it

 

[802SHO]

There’s many tables stuck on OEM load limits. And really low lb.min table limits. So once you hit that table row it’ll use that value into infinity at 2.0+ load. I’m going to ask David if we can get those rescaled properly so that when you calibrate the demand all the respectful parties have similar load values. And the more power we make the more these become increasingly critical.

 

[Stefano]

Me big danger. AI guy said so.


Sent from my iPhone using Tapatalk

Nice Rebuttal.

 

[802SHO]

It happened. I popped my tuning cherry. Lmfao. But seriously I edited my own tune and I’m just waiting to hear from Mike @ XDI before flashing. That’s only a small part. I’ve been influencing David and also learning from David and that dynamic is working really well. I’ve now made some edits to OSS modifier and our Driver Demand tables I can’t wait to try.

So on the XDI side of things I’ve been just using 2150psi rail pressure (stock value) this whole F time…….my 8k fuel system? Just doing stock stuff, well except the XDI2000cc injectors doing their thing. That’s all about to change. DI pump settings are now at 3,000psi (XDI60 flows 3600psi)
The problem? Well not really a problem but the important part is knowing this auto scales the injectors to 2,977cc. Essentially 3,000cc. They max around 3100cc+.

So we need Mike to say ok or lower rail so we aren’t that close to max. Maybe he offers me a deal to upgrade to 2500cc injectors base pressure. But also the injectors only scale to 2500psi.

Thats not good so past 2500psi the ECU only knows that flow rate and it will definitely lead to artificial rich trims and if we said…eh should be fine we’d be relying on the widebands to clean it up and that’s a hack.
Just waiting on Mike to check my work and give us a blessing or new lower targets.

The OSS modifier will take your pedal position relative to your Driver Demand table and say ok at this TP you’re asking for 200 tq? I’m going to only give you 120 tq. So you’d see a value of 0.6000. Or 0.8000. Then like 1/2 pedal it’s multiplying 1.1 or even 1.4. So even if you press harder and reach the top of driver demand you’re sort of already there in a way earlier. It’s just setup to make the car feel quicker than it is in some spots but it also can create the TB to try to close on you here and there if it’s not setup right.

Our demand we want is a peak of 600lb.ft and I reshaped DD so that it’s always pulling equally and I matched OSS Modifier 1:1 so what you ask for is what you get. The car should feel as close to a cable-driven TB as you can get. And it’s mathematically consistent so it’s equally increasing everywhere. It should feel more responsive and just keep giving you what you want with no dead spots.
This is f awesome! This will be how David and I tune my car thread.

 

[802SHO]

Like I mentioned we have scaled capacity high enough right now to watch the car land its back flip in Driver Demand and not get clipped.
When this was set to 1.9 the car hit it and got clipped with PCM intervention. When it was set to 2.2 the car hit it and got clipped with PCM intervention. Now it won’t get clipped but also I don’t believe this is the new ceiling, it’s only the new ceiling for now.

 

[802SHO]

A new Team has formed. David S, Johnny P and me. We will continue to collect all the Infinite Stones of the Green Oak OS hahahahahahahahah

But seriously though. Johnny on Monday is going back in the OS looking for more wastegate controls and torque arrays. David is going to search for ID’s and also compare and look through a 2011 Copperhead F150 V8 for anything we might need.

We’ll unlock all the power

 

[802SHO]

Uh oh! We got rear differential control coming soon! Johnny responding to David’s ID list: Ecm[6819] wastegate proportional
Ecm6822 gain
Ecm 45575 closed base
Ecm11041 intercooler volume
Ecm 11844 max gross torque
Ecm 19629 max torque array
Ecm 6833 lower clip transmission protection
Ecm 40754 max tq request

Johnny, “As far as the rear diff stuff I have those tables just waiting for a good slow day to find them lol. I’ll check on these ID’s on Monday.”

We uncovered the rear drive clutch Infinity Stone haha!
We already have the missing torque limiter and torque model expansion Infinity Stones lmfao

 

[802SHO]

Uwe responded.
I see this up myself. Coming in at 2200psi at 4500 rpm peak torque and ramped to 2800psi for 6500 rpm.

I’ll be getting a log tomorrow.

 

[802SHO]

Man my first edited tune with David went well. I changed 3 and 4th gear speed for shifting and it was way better. I’m holding 3rd until 38 mph and 4th until 51 mph.

My target of 1.88 load was looking like it was a direct bullseye. I hit 1.9 load. Preignition capped it at 14 spark it did like 14.5. Torque source driver demand. 17 psi EMP. Right at 20 psi boost basically. 439 engine brake torque. 53.45 lb.min. Right over 5k rpm and we got 2500 psi rail. We wanted 2200 at 4500 and 2800 at 6500 that’s on track. EQ .81 beautiful. It shows 100.0% throttle positing but reposts part for pedal state, not WOT? 70inhg inlet pressure actual and desired was 75 inhg. That’s interesting. I didn’t hit -1.00 KOM yet it was -.71. TCC slip 308.8.

So I’ve this made some adjustments to pressure settings and feed forward WGDC settings to keep boost under control better when I make another attempt. I did look at TC apply rate and it was all stock lmfao.

I made multiple changes and rescaled the tables to ramp TC apply rate much faster on steady state, upshift and downshift. I think that TC value will plummet drastically.

And now I actually wait bc we just uncovered the Rosetta Stone of my OS!!!!! 10,106 tables/scalers!!!

Engine speed is one. Johnny is on it. This is getting better and better as we uncover literally every single possible controller for power. Here’s a few the AI I use to review my logs searched for.
Wastegate PID Control & Multipliers

These are the scalars that define your Base PID, plus the 1D tables that act as error multipliers (which is how you fix deviations from your target TIP).

0x186280⁠ (⁠WGC_PGAIN⁠): Proportional gain for wastegate duty cycle control (Scalar)

0x18626C⁠ (⁠WGC_IGAIN⁠): Integral gain for wastegate duty cycle determination (Scalar)

0x186270⁠ (⁠WGC_DGAIN⁠): Gain for wgc derivative term (Scalar)

0x1AE988⁠ (⁠FNWGC_PGAIN_TIPERROR_ADJ⁠): Multiplier on proportional gain used to implement variation with tip error (1D Table)

0x1AE918⁠ (⁠FNWGC_IGAIN_TIPERROR_ADJ⁠): Multiplier on integrator gain used to implement variation with tip error (1D Table)

Airflow Failsafe Limits
The hard caps on total airflow (these are the ⁠20⁠ and ⁠62⁠ limits you hit previously).

0x186494⁠ (⁠WGC_MAX_AIRFLOW⁠): Airflow limit imposed during normal operating conditions (Scalar)

0x18649C⁠ (⁠WGC_AIRFLOW_LMT_LOWERBND⁠): Lower bound on airflow limit, imposed when wastegate has no authority to limit boost (Scalar)

AWD Torque Limits & Coupler Testing

The tables limiting torque specifically when AWD is active, plus the manual override to force torque to the coupler for testing.

0x1EC608⁠ (⁠FNTQLM_AXL_AWD⁠): Final drive/axle torque limit for AWD vehicle as function of vsbart_rt, in ft-lb (1D Table)

0x1EC6A8⁠ (⁠FNTRLM_AXL_AWD⁠): Final drive/axle torque limit ratio for AWD vehicle as function of vsbart_rt (1D Table)

0x18A8E0⁠ (⁠TQO_4X4_TQTEST⁠): Desired 4x4 coupler torque value for test purposes (Scalar)

0x18A8DC⁠ (⁠TC_FM_LIM⁠): 4x4 coupler torque limit applied when 4x4 CAN message lost (Scalar)

Manifold / Intercooler Volume

I searched specifically for volume-related logic. In this ECU architecture, Ford uses Intake Manifold Volume rather than a specific "Intercooler Volume" to model manifold filling and lag. If you significantly increased the piping or core size, this is the parameter you adjust so the ECU knows the system takes longer to pressurize.

0x1804BC⁠ (⁠AIR_MAN_VOL⁠): Intake manifold volume for use in manifold filling model (Scalar)

0x18EC8C⁠ (⁠FN1052_BOOST⁠): Volumetric efficiency correction for the manifold filling model, boosted apps (1D Table)

Hidden / Overarching Torque Limiters

I queried the database for all engine brake torque limits. These are the main culprits that can trigger unexplainable throttle closures if conditions aren't perfect:

0x1ECCE0⁠ (⁠TQ_LM_GR⁠): Transmission input torque limit for each shift type (2D Table)

0x1ECD30⁠ (⁠TQ_IMPLR_LM_GR⁠): Impeller torque limit for each shift type (2D Table)

0x18B5DC⁠ (⁠TQ_CVTR_LMT_LKD⁠): Torque converter torque limit when converter clutch is locked (Scalar)

0x1EC748⁠ (⁠TQ_CVTR_LMT_OPN⁠): Torque converter torque limit when converter clutch is open (2D Table)

0x184970⁠ (⁠CSL_TQE_LMT_MAX⁠): Maximum value allowed for engine brake torque limit to prevent spark retard induced combustion instability (Scalar)

0x18FB30⁠ (⁠FNPD_WOP_TQE_LMT_A⁠): Wide Open Pedal (WOP) engine torque limit based on air adjustment factor and engine speed (2D Table)

These ECU IDs will let you completely expose what the PCM is actually thinking.

Now to send Uwe the WOT blip of my DI pump and injector Scaling data log

 

[802SHO]

Looks like AI parsed some of those ID’s wrong as Johnny just corrected me. We’ll leave it up to Johnny.

Edit: it wasn’t wrong it was only part of it

 

[SM105K]

Heck yeah. Keep that shit up.

 

[802SHO]

From Uwe
This is pretty damn cool. Yes sir, I’ll send the file right away.

 

[802SHO]

Holy $hit!!! I got flex fuel

The ⁠DMJKB⁠ strategy has a fully baked-in flex fuel logic architecture. Here are the most critical ECU IDs mapped out for you, broken down by function so you know exactly where to point HP Tuners.

1. The Main Flex Fuel Switches (Scalars)
These are the binary on/off switches and thresholds the ECU uses to determine if Flex Fuel logic is active and what it considers "minimum" and "maximum" alcohol content.

0x1811B4⁠ (⁠CAT_FFV_CAL⁠): Cal flag to allow Flex Fuel logic to be active. 1 -> FFV logic enabled. (This is your master switch).

0x1832E4⁠ (⁠TFC_PM_MN⁠): Threshold on pm value below which there will be no FFV modification. (Minimum ethanol % to start blending).

0x1832E8⁠ (⁠TFC_PM_MX⁠): Max PM value above which it will be considered 100% FFV. (Maximum ethanol % to cap blending).

2. Flex Fuel Spark & Torque Blending (1D Tables)

Once Flex Fuel is active, the ECU uses these tables to blend spark and torque limits based on the percentage of ethanol detected/inferred.

0x1A8FE4⁠ (⁠FNSPKPM⁠): Shaping function to blend between gasoline and ethanol spark tables based on fuel.

0x191854⁠ (⁠FN612⁠): INDICATED TORQUE MULTIPLIER AS A FUNCTION OF PERCENT OF METHANOL.

0x1A95AC⁠ (⁠FN727⁠): Multiplier to borderline spark modifier for flex fuel.

0x1AABF0⁠ (⁠FN751⁠): Preignition spark modifier for flex fuel.

0x1AC654⁠ (⁠FNTQE_LD_LMT_PM⁠): Load limit applied for percentage of alcohol. (Crucial for not hitting a torque ceiling when running E85).

3. Open Loop Fueling & WOT (2D Tables)
These tables control the actual fueling targets when you go wide open throttle or are starting the car cold on E85.

⁠0x1A4670⁠ (⁠FNWOT_LAM_F⁠): Desired lambse during power-demand with alcohol fuel (flex). (Your E85 WOT fueling target).

⁠0x1A4368⁠ (⁠FN1362LBX_FF⁠): Base Open Loop desired exhaust lambse fuel table (15 x 8) for alcohol based on time.

0x1A45A4⁠ (⁠FNCRK_LAMX_FF⁠): Crank open loop commanded lambda single column table (1x15) for alcohol. (Crucial for E85 cold starts).

4. Transient Fueling (Acceleration / Deceleration) (2D Tables)

Because E85 evaporates differently than gasoline, transient fueling (tip-in and tip-out) requires completely different math to prevent lean spikes.

0x19D380⁠ (⁠FNGTC_GN_FFV⁠): Transient fuel accel gain for flex fuel.

0x19D760⁠ (⁠FNGTC_TC_FFV⁠): Transient fuel accel time constant for flex fuel.

0x19CBC0⁠ (⁠FNGTC_DGN_FFV⁠): Transient fuel decel gain for flex fuel.

This OS is wayyyyyyyyyyyyyyy more capable than anyone thought

 

[802SHO]

So what we have here is the complete blueprint of my strategy A2L. Every thing it can do. Like I mentioned there are over 10,000. Johnny can only spend so much time each time he goes in there so it will take a while to get this all set but I’d imagine we get flex fuel right when I’m ready to switch to ethanol.

 

[802SHO]

Missing torque arrays.
1. The Driver/Pedal Demand Arrays

These are the tables where your foot translates into an actual torque request.

0x18FE50⁠ (⁠FNPD_TQE_BSE⁠): Base engine torque pedal demand table. (This is your primary 10x10 array. You will likely need to scale the Y-axis and cell values here to request more torque at higher RPMs).

0x190170⁠ (⁠FNPD_TQE_MOD⁠): Used to scale engine torque values (from fnpd_tqe_bse) for engine torque based pedal demand. (A 10x10 modifier array).

0x18FFE0⁠ (⁠FNPD_TQE_LOW⁠): Engine torque pedal demand table for 4x4 low operation.

2. The Engine Indicated Torque Arrays (The Core Math)

This is the holy grail of Ford tuning. The ECU uses these arrays to convert your requested torque into actual throttle angle, boost, and load limits.

0x191CE4⁠ (⁠FNTQE_IND⁠): Engine indicated torque @ stoich, MBT and other STD conditions. (A 10x10 array determining what the engine is theoretically capable of).

0x191B44⁠ (⁠FNTQE_INDINV⁠): Load as a function of Engine Speed and TQE_AM_CONV. (This is the Inverse Model array. It is a 10x10 table that calculates how much engine Load is required to meet your requested torque).

3. The LSPI Load/Torque Limit Arrays

Since you are pushing high boost at lower RPMs with those new turbos, you need to watch these arrays like a hawk. They act as dynamic ceilings to prevent Low-Speed Pre-Ignition (LSPI).

0x1AC934⁠ (⁠FNTQE_LD_LMT_LSPI_EFFHI⁠): Load limit at high effectiveness of LSPI mitigation (10x6 Array).

0x1AC834⁠ (⁠FNTQE_LD_LMT_LSPI_EFFNM⁠): Load limit at nominal effectiveness of LSPI mitigation (10x6 Array).

0x1AC734⁠ (⁠FNTQE_LD_LMT_LSPI_EFFLO⁠): Load limit at low effectiveness of LSPI mitigation (10x6 Array).

4. Cam Timing Torque Arrays

Ford uses arrays to calculate torque efficiency based on where your VCT (cam timing) is sitting.

0x1B08F4⁠ (⁠FN5520_TQ_C⁠): Optimum cam timing for fuel economy and combustion stability limits for IMRC closed (11x9 Array).

0x1B0A90⁠ (⁠FN5520_TQ_O⁠): Optimum cam timing for fuel economy and combustion stability limits for IMRC open (11x9 Array).

If you are trying to command more than the factory ECU thinks is physically possible, you usually have to scale the X/Y axes of ⁠FNTQE_IND⁠ and ⁠FNTQE_INDINV⁠.

Lol ok thanks AI assistant