Coyote Torque Loss Tables

[CCS86]

So, the driver demand system works using an ETC torque request (pedal position vs RPM) to establish what torque the driver wants to the wheels.

Then it somehow calculates an adder, to arrive at a scheduled torque amount (higher than the request, so that wheel TQ = requested TQ, after losses)

Then it uses tables like [Torque], [Torque inverse], [Throttle body effective area & predicted angle], etc; to decide how far to open the throttle to achieve this torque.

This means that [Scheduled Torque] - [ETC Torque Request] = some positive value. In theory this value comes from one or more tables that I have yet to see. Does anyone know where this value comes from? Certainly making big changes like a belt driven supercharger, overdrive pulleys, etc; would have an impact on this value, and benefit from tuning.

Where does this mythical table live? Do any Coyote strategies have it, so we can request HPT add it to others?

Thanks!

[murfie]

No adder is calculated. Schedule torque comes directly out of your torque/inverse tables from the load the engine is at. The MAF or MAP sensor will give the engine load input. It is the torque the engine would make at lambda stoich, MBT spark, STP, the same as indicated by those tables. From your actual values of these and many other factors, the actual engine torque is estimated. There are functions that take things like the delta from MBT and actual stoich and calculate a torque difference, these are not look up tables. They would be coefficient tables similar to the pumping loss or SD values. Looking at them would make no sense unless you knew the formula they go into. If these formulas come out to adding torque to the Schedule torque value, I guess you could say that would be an adder, but in reality, this only happens at low loads, and even then schedule torque isn't usually beaten before you are wanting the engine to idle or make less torque than it is.

The driver demand torque is kept = to the estimated engine torque. Quick changes to pedal position can cause one to lag behind the other momentarily. DD describes torque at the wheels so that if the transmission controller, or another system modifies engine torque, the torque going to the wheels is the same as the driver wants when these interruptions no longer are needed. The driver only gets what they want when the ECU is happy with what they are requesting.

The main reason schedule torque is used is because it is a very constant/ stable value. From it a dependable plausibility check can be made on the engine parameters. When done right, the engine is kept in very safe running conditions with out being too conservative in any conditions. A low torque ratio means the engine is under performing and not being efficient. A high torque ratio means the engine is over performing and is at risk of damage. If nothing has changed from a good running state, this can both either mean a sensor has failed, or some mechanical issue has occurred. Once wheel torque error goes over a certain value, the check engine light or wrench light will come on.

[CCS86]

DD requests wheel torque.

Scheduled torque, like you confirmed, is using [edit] torque tables [edit].

To get from engine brake torque, to wheel torque, you would subtract a whole host of losses: AC compressor (could be on or off), alternator (variable load), supercharger (if you have one), driveline losses, etc.

Are you saying that all these things are ignored, and that the only reason that scheduled torque is consistently above ETC request, is due to operating condition correction factors (spark below MBT, atmospheric pressure below 14.7 psi, EQR away from stoich, etc)?

[murfie]

Scheduled torque is not using engine brake torque. That is not what I said. Schedule torque is looked up in the torque tables. Then certain losses that are relevant are applied. The goal being a constant that can be used for a baseline to compare to.

Estimated engine brake torque is derived out of schedule torque by actual inputs and many other modeled losses, some the same as applied to scheduled, some not as the torque is tracked from flywheel to tire not just at normal operating temperature. There are more all in an attempt to get the most accurate estimate. Even abstract things like engine age could be a factor.

In a properly calibrated setup the main two things being fuel and spark for the difference. Altitude or some crazy temperatures could be a factor, but they don't usually rapidly change like the other two.

The airflow can also cause a difference when models don't agree on what the airflow means. This is where DD/TTL, throttle body model, LTT/TTL, and the actual air gong through the intake, engine, and out of the exhaust as determined by MAF or MAP type sensors, corrected by O2 sensors and models like SD or cylinder filling, all need to agree about the LTT calculations and not be out side of IPC or any limits of either load or torque. The transmission needs to be happy with the torque coming into it and going out of it, traction control needs to be happy with the speed of the wheels.

[CCS86]

I meant to write torque table, and fixed my post.

You didn't answer my question though. Where / how is the PCM accounting for losses like alternator, AC, driveline loss, etc; when scheduling torque?

[CCS86]

Here is an example.

I created two math parameters:

TQ Loss = [Sched Torque] - [ETC TQ Request] (This tells us how more more TQ the PCM tries to create, in order to satisfy the driver request)

TQ Loss % = [TQ Loss] / [Engine Brake TQ] (I tried dividing by ETC TQ, and Sched TQ, but the result is similar)



TQ Loss Growth.jpg


You can see that during a WOT blast, the TQ loss increases in value, but also as a percentage.

[murfie]

HPT doesn't give access to those functions.
They would be similar to the pumping losses tables under the loss tab. Finding more accuracy in them probably wouldn't be possible outside of a engine dyno, and monitoring through a jtag or what ever the direct connection to the ecu is. Maybe one could guess and get lucky.

You could ask support, but I don't think you would get it any time soon.

[CCS86]

HPT doesn't give access to those functions.
They would be similar to the pumping losses tables under the loss tab. Finding more accuracy in them probably wouldn't be possible outside of a engine dyno, and monitoring through a jtag or what ever the direct connection to the ecu is. Maybe one could guess and get lucky.

You could ask support, but I don't think you would get it any time soon.

The whole point of this thread was my assumption that tables like this do exist in the PCM, and me wanting to find out exactly what they are called, so I can request them.

So, why did you state that no such thing exists?

Your last post in here really should have been your first, if you wanted to help.

Do you know what these tables are called (beyond the pumping loss table), or any identifying numbers for them?

[murfie]

I guess you didn't comprehend the very first paragraph of my first post.

Idk what they would be called, or have identifier numbers for any of them, as I don't think they have been defined in any software outside of Ford.

[blackbolt22]

I agree there has to be a table or something to reference each component of loss. For instance if the A/C is on or off. Having the table may end up being useless though since we can't see the formula(s) being used , like murfie is saying.

[CCS86]

I guess you didn't comprehend the very first paragraph of my first post.

Idk what they would be called, or have identifier numbers for any of them, as I don't think they have been defined in any software outside of Ford.

The first paragraph you wrote jumps around a bit.

You are assuming that the only way the PCM calculates losses would be through complex table/formula combinations. It sure seems like AC compressor loss could be described much more simply than that.

Even if it is all more complex calcs, you could say the same thing about the speed density tables, yet HPT has a calculator built in for that.

[murfie]

Complex to us, is simple in coding and efficient for CPU/ memory. Think of the number of different factors that could go into the estimate. Coefficients would be a lot easier of a CPU /memory load than look up tables and a lot more versatile. They could be obvious, they could be abstract. Figuring out which is which would be a serious needle in a hay stack task.

Then when that's done, you want them to make calculators for them all... So you can get your estimate another 1/2% closer to actual if you are very lucky. Just face it, HPT is never gong to be an OEM calibration replacement. It is damn good for what it is.

I like my cost per credits as it is, and don't want them to go up. I don't like the cost and labor that goes into aftermarket ECUs. Can you figure out a better way for support to spend their time to get your car running better? Maybe your car is running as well as it's going to through calibration changes?

[elerico]

Here is an example.

I created two math parameters:

TQ Loss = [Sched Torque] - [ETC TQ Request] (This tells us how more more TQ the PCM tries to create, in order to satisfy the driver request)

TQ Loss % = [TQ Loss] / [Engine Brake TQ] (I tried dividing by ETC TQ, and Sched TQ, but the result is similar)



TQ Loss Growth.jpg


You can see that during a WOT blast, the TQ loss increases in value, but also as a percentage.

Do you apply tq loss % to driver demand ?