Understanding Torque and Torque Inverse, EBT>ETC

[blackbolt22]

I have read a lot of threads regarding Torque / Inverse Torque and believe I have a decent understanding about how the ETC request system works to fulfill the request but the correction method seems to work the opposite of what I would think.

Here is an example scenario that closely parallels my own, from the datalog perspective (fake numbers but realistic):

RPM = 2000
ETC Request = 140ft/lbs.
Engine Indicated Torque Reference = 175 ft/lbs (basically gross)
Inverse Torque Table Y Axis @ 175 ft/lbs = .40 Load value @ 2000rpm.
------------------------------------------------
Actual Engine Brake Torque =185 ft/lbs net (215ft/lbs approx, so 40 too much)
Actual Air Load is .500 (the air equivalent of .10 load too much)
ETC Angle Error is say -3.00


Logically if ETC wants 140ft/lbs net output and it takes 175ft/lbs gross power to get us there and the model says ".40 load will do that for us at this rpm" and the actual torque output and actual air load is higher meaning throttle is open more than it should be , i'd think either the throttle body effective area is wrong (except its not in my case, it's just a common ford twin) OR the torque model is wrong and Load at the Torque Inverse Table Y Axis@RPM would have to be LOWERED (which RAISES Torque in the Torque Table).

The fix -should- be since .40 load in the inverse table (and requested?) outputs .50 actual.. we should lower load in that same position by roughly the same amount... so .30 might give us .40 actual output (humor me).

It seems in reality though, and what I'm reading, I need to raise load in the torque inverse table (which lowers in torque table) to fix this scenario in order to match the model to what the car is really doing, but WHY? From a request standpoint it seems completely backwards! Has anyone else figured this out?

[murfie]

Desired Torque(DD) -> TQ model(scheduled torque -> desired load) -> desired MAF

Actual MAF(MAF sensor)-> (load -> indicated torque) TQ model -> engine torque

The throttle is controlled by looking at the actual MAF value and opening or closing it to meet the desired MAF value. Or MAP sensor if that's what your car has.

Scheduled torque should match indicated. This is the IPC checks and balances/ idle control.

Engine torque should match desired. This is the request from the pedal and what the engines doing.

MAF and load have a direct relationship based on RPM, engine size, and number of cylinders. MAP gets to load directly through SD.

MAF is usually off when injector data or fuel system data is not correct. This can skew things up or down. That's when you have to look at VE and do your own checks and balances, like, no I'm not getting 2.0 load at 11psi of boost.

For the more detailed flow chart.
torque control.jpg

[MRRPMBRP]

MAF is usually off when injector data or fuel system data is not correct. This can skew things up or down. That's when you have to look at VE and do your own checks and balances, like, no I'm not getting 2.0 load at 11psi of boost.

Never thought about it this way, since most dial in their MAF table with fueling corrections, if inj data is good, that means maf data will be good, if inj data is off, then maf will be off. When the ecu looks at MAF data, and tries to make throttle opening match the maf number (it opens the throttle until it sees the maf it's looking for) if maf is right, then throttle will open to match, once tuned.
Seems the ecu would be going in circles with wrong inj data, if you were trying to tune the throttle body, no?

[murfie]

The other spot people have trouble with is lining up their SD and MAF to agree where MAP= barometric pressure. This is usually where injectors are rated at, so when that's off, injector data may be right, but calibration causes it to be off.

[Grim5.0]

The other spot people have trouble with is lining up their SD and MAF to agree where MAP= barometric pressure. This is usually where injectors are rated at, so when that's off, injector data may be right, but calibration causes it to be off.

im noticing the calculated baro is off by a few inhg compared to actual using iphone sensors and confirmed with small airports weather station 2-3 miles down the road. The learning can be forced to stop to keep it near actual, other wise it drifts or learns a lower baro than actual.

how do we correct? it almost seems like there needs to be an offset to get it accurate.

[murfie]

ETC Vacuum(determined by airflow, RPM, and throttle angle going into one side of the inverse throttle model, the other side of the inverse is for the correction) + MAP( air flow into the speed density) will reflect what it thinks Baro is and how it "learns" Baro.


Have a known good throttle body model, and get your SD accurate so calculated MAP= actual MAP, that's all that's needed for it to reflect Baro some what accurately.

[murfie]

Then part of the throttle body model is Default Baro, the pressure in which the model was made, as the reference point.

[Grim5.0]

i was expecting a shift in the entire TB model with a different base baro but im only seeing it show up in fuel trims. Seems learned baro is much like the other learned parameters, specific loads/rpms must be present for it to learn the value. The most dominant is a load above 21-22% and usually EBT and ETC are in agreement too. should be helpful to filter actual map/mp to see if any SD might be corrected.

-tunes only have default baro adjusted, 27/30inhg respectively. same exact route driven back to back after tune loaded.
30inhg default baro.png27inhg default.png27inhg 104 air temp.hpl30inhg 104 ait temps.hpl

not trying to highjack your thread blackbolt, seemed relevant since the end of the tq/inv is the tb and then back again. and murfie left the door open on the baro..