Results 1 to 9 of 9

Thread: Car is ignoring my torque table changes

  1. #1
    Tuner in Training OverNightPartsFromJapan's Avatar
    Join Date
    Aug 2018
    Location
    Bossier City, LA
    Posts
    21

    Car is ignoring my torque table changes

    Despite my best efforts to adjust the torque tables to accomodate error logs, the car does not respond to my torque table changes. Ive locked map point to OP for this trial, i am logging etc error vs load, and engine speed which is the same as the torque tables to show where im having torque discrepancies. When reaching loads of 70% im getting heavy throttle oscilations from what i assume are torque related disagreements. I am manually adjusting the torque table in attempt to reduce this disagreement, however no changes have any impact. Any siggestions? Ive tried torque values ranging from 0-700 with seemingly no impact to drivability.

  2. #2
    Advanced Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    467
    I think the TQ inverse table is actually more heavily used for driver demand than the TQ tables.

    No one on the forum has conveyed an understanding of how driver demand works, how to properly tune out IPC TQ errors, etc; which matches the testing results I have seen.

    I honestly think you are better off running stock GT TQ/inverse tables, with a little load rescaling at the top if you need it.

  3. #3
    Quote Originally Posted by CCS86 View Post
    I think the TQ inverse table is actually more heavily used for driver demand than the TQ tables.

    No one on the forum has conveyed an understanding of how driver demand works, how to properly tune out IPC TQ errors, etc; which matches the testing results I have seen.

    I honestly think you are better off running stock GT TQ/inverse tables, with a little load rescaling at the top if you need it.
    Its been covered pretty extensivly by people here and on a few tuner schools as well. Though the schools didnt say much about it other than "you need a dyno"

  4. #4
    Advanced Tuner veeefour's Avatar
    Join Date
    Oct 2016
    Location
    Poland
    Posts
    330
    Quote Originally Posted by CCS86 View Post
    I think the TQ inverse table is actually more heavily used for driver demand than the TQ tables.

    No one on the forum has conveyed an understanding of how driver demand works, how to properly tune out IPC TQ errors, etc; which matches the testing results I have seen.
    Nope, ECU looks for torque which is calculated from load...

    Wrong, many have a good understanding on how the Fords's torque model works - including me.

  5. #5
    Senior Tuner
    Join Date
    Jan 2013
    Location
    Hawaii
    Posts
    1,270
    Air, fuel, and spark gives you torque. The model is not that hard to understand.

    Air starts at the MAF, Or MAP sensors. The various models and calculations arrive at an estimated cylinder air charge.
    Fuel is modeled in the injector data. It matches that cylinder air charge in your commanded stoich ratio. It is corrected by o2 sensors closed loop and openloop corrections for changes in airflow that would happen faster than O2 sensors could predict.

    Spark is where most people get lost, or make changes that don't reflect whats happening in reality, throwing off the torque model. Air and fuel are usually well taken care of by the ECU unless you have some physical problem or made some poor calibration changes. You have MBT and borderline base tables. You have correction tables to these values. Then you have limits. You also have the entire knock strategy that happens when the engine is detonation limited. You also have a separate spark control strategy for idle and return to idle thats based around a percentage of MBT to produce a desired RPM.

    Grossly simplified to the major part of it, the torque model basically describes the torque the engine would make at the MBT spark values you have input. Minimum timing for best torque. Airflow gives you load, torque is going to be directly proportional to this as it is to manifold pressure. lambda also has an effect but to a much lesser degree as it shouldn't stray too far from lambda 1 or WOT lambda values. This model can then be manipulated to compensate for pumping loss, friction, etc. to provide an even more accurate torque value. It can be used to make sure the engine is performing as it should be, not making too little or too much power. Measured values of air, fuel, and spark can be compared to this model to estimate the torque the engine is actually making. Driver demand tables describe what a position of the pedal for a given rpm means in torque, this gives the ecu what the driver wants the engine torque to be at. The ecu tries to satisfy the driver, but if it detects some thing wrong it has the ability to override this request. The torque values are also used to control much of the automatic transmission/TCC operations.

    Paying attention to your sources will point you to what is causing your issue. When you make changes you should be looking for those changes in your logs. If you don't see any thing change, you either are not logging the correct channels, not truly flashing your changes as you need to do a write entire, or are having some other scanner issue. If you do see the changes, but are still having the issue, then what you changed probably isn't the cause. ETC error can be caused from other things beside torque, TPS voltages being out of calibration, physical problems with the gears, motor, or bearings. The TPC itself is very sensitive, more so in later models, just having an older/high mileage TB thats a little dirty and sticky can result in small error you cant get rid of with the calibration.
    "We can never be right, we can only be sure that we are wrong"- feynman

  6. #6
    Tuner in Training OverNightPartsFromJapan's Avatar
    Join Date
    Aug 2018
    Location
    Bossier City, LA
    Posts
    21
    Quote Originally Posted by CCS86 View Post
    I think the TQ inverse table is actually more heavily used for driver demand than the TQ tables.

    No one on the forum has conveyed an understanding of how driver demand works, how to properly tune out IPC TQ errors, etc; which matches the testing results I have seen.

    I honestly think you are better off running stock GT TQ/inverse tables, with a little load rescaling at the top if you need it.

    I actually agree with this, not to imply everyone else in here is wrong. I would say I have spent the better part of 20 hours researching torque manipulation and I find plenty of people who understand the inner workings of the torque calculations but to what degree? I am a genuine believer that if you ask how or why enough you will always find the limits of what people actually know and I find plenty of "what is happening" all over this forum but no "how to manipulate it" or "why this change impacts the tune in this way" type of information. I am sure you all do understand it, just like a metallurgist understands that he needs a welder to avoid the creation of martensite for a particular purpose on a job. The welder doesn't have a clue what martensite is but he knows how to avoid it's characteristics from experience. It takes both to create the product and I see plenty of "metallurgists" on this forum. I hope that did not come off as negative, as I did not intend for it to.

    I understand that a dyno is needed to have these values accurate, but imo, the name of accuracy went out the door when I started manipulating the maf signal to make the car run right. We are talking about a car with half its sensor values being inferred and our quick and dirty method to tune the car is to use the MAS, the most important sensor, as a global scaler. Sure it works and hell I can even manipulate numerous other settings to make my airflow model seem accurate again, but something somewhere in the tune is still going to be inaccurate. My goal is to have a car that is enjoyable to drive again, and it would seem torque manipulation is my current roadblock, not accuracies.

    If the car knows there is a torque disagreement, then I see no need to dyno to obtain the correct torque values. One, because the car isn't running well enough to capture any accurate torque reading and two, if the car is aware its wrong, it will be aware when it is right after manipulation of whatever needs to be changed. My problems stem from the fact that the car is aware of the torque errors, not the fact that they actually exist. At this point in time I'm not terribly concerned with their accuracy so much as manipulating them to reduce my throttle surge and prevent the car from going into limp mode. Once I get the car to listen to my changes I will delve further down the accuracy hole.

    Back to my specific problem, I simply do not understand how I am having torque disagreements within the ecu and changing the torque values have no impact. My original post stems from the fact that I was originally going into limp mode at 50% to 120% loads but WOT and low load driving was fine. I logged throttle error along with torque errors and notice they seemed directly related. I have a stock gt500 throttle body with its calibration data pulled directly from the repository on a stock gt500 tune so it seemed logical to attempt to change torque values. I tried changing them by 20 ft/lb increments using the inverse calculator, flashing, and recreating the same rpm/load scenario. Regardless of what the torque values were changed to the errors never lessened. I thought perhaps the deviation between the current driver demand table on the car and the torque table could be so large that I could not reach an agreement between the two which was why even at values of 100 or 700 tq I saw no reduction or increase in errors. In a fit of anger, I dropped in the gt500 driver demand table and to my surprise, the car no longer went into limp mode. The errors were slightly lessened but still could not be changed by changing values on the torque and inverse tables. Could this be from the same scenario I described earlier where the difference between the dd tables and torque tables are so great that changing the torque tables cannot compensate? Thank you all very much for your input and thank you for the detailed explanation Murfie.

  7. #7
    Advanced Tuner
    Join Date
    Jul 2017
    Posts
    268
    One thing, since almost all the calculations rely on the torque model, and the torque model must know the amount of air coming in, when we scale the MAF sensor we mess up the actual airflow. Add to the fact that with a larger hole or tube to mount the sensor in, to keep sensor from maxxing out, there is no way the airflow is anywhere correctly metered into the ecu. We are working around this in the tuning, but it doesn't matter, as if it gets dialed in, it works. On mine, I have the JLT super big tube, my A/F ratio swings around some under low rpm, low loads, I'm thinking that there is air going into the motor that is not metered accurately, in other words air is going around the sensor, since the sensor is mounted in such a big hole. No way the computer can know this, but this must be done to use the meter we currently have.
    So, if the ecu doesn't accurately know the amount of air going in, it cannot know how much to open the tb to get the correct amount of air in. I think this is why we have throttle errors sometimes. Mine will have as much as 1? or so, but it seems ok like that. I know stock cars tend to run less than one, which is expected with stock size tb & MAF sensor, & cams.

  8. #8
    Quote Originally Posted by MRRPMBRP View Post
    One thing, since almost all the calculations rely on the torque model, and the torque model must know the amount of air coming in, when we scale the MAF sensor we mess up the actual airflow. Add to the fact that with a larger hole or tube to mount the sensor in, to keep sensor from maxxing out, there is no way the airflow is anywhere correctly metered into the ecu. We are working around this in the tuning, but it doesn't matter, as if it gets dialed in, it works. On mine, I have the JLT super big tube, my A/F ratio swings around some under low rpm, low loads, I'm thinking that there is air going into the motor that is not metered accurately, in other words air is going around the sensor, since the sensor is mounted in such a big hole. No way the computer can know this, but this must be done to use the meter we currently have.
    So, if the ecu doesn't accurately know the amount of air going in, it cannot know how much to open the tb to get the correct amount of air in. I think this is why we have throttle errors sometimes. Mine will have as much as 1? or so, but it seems ok like that. I know stock cars tend to run less than one, which is expected with stock size tb & MAF sensor, & cams.
    Not starting an argument or anything; just curious...... but don't you think the swinging would be caused by turbulence in the tube?

    MAF sensors heat an element/diode and measure the voltage drop required to keep the element heated which is then (by ford) turned into a sampling rate that we see in the MAF transfer function.

    So, wouldn't that mean we are measuring the velocity of that airmass and not the actual quantity of molecules entering the manifold? If that is true then that would be an explanation to Fords Statistical SD system and why it is compounded with a traditional MAF sensor. SO; that would mean you could eliminate the swinging in cmd vs actual by appropriately calibrating the SD system and with a total of 26 iterations of the same process, it would be possible to scale and calibrate them so that under just about any condition you would not see the same issue arise.......... or at least in a perfect world that would be the situation.

  9. #9
    Advanced Tuner
    Join Date
    Jul 2017
    Posts
    268
    Could be turbulence for sure, but the end result would or is the same, unmetered air entering the motor. At least that's my thinking anyway.

    I think the way it works is that a certain airmass will flow through a certain orifice at a certain pressure. This airmass will cool a certain wire a certain amount, at a certain velocity (speed). This info is used to calculate the airmass going into the motor.

    I think that in a large tube, one side of the air is flowing faster than the air on the metered side, so the meter has no way to know what's happening so far away. This air could be tumbling, spinning, or whatever, & the meter wouldn't know it, since it's so far away.

    The only way I would know how to fix this is to use two meters & divide up the flow somehow in the ecu. In other words, we need the tube diameter smaller to get a better sample of what's going through the tube.