Looking to see how everyone has setup their Mapped points for torque tables, i have attached a snip of what i setup but i am not sure its reading right. thanks in advance.
Printable View
Looking to see how everyone has setup their Mapped points for torque tables, i have attached a snip of what i setup but i am not sure its reading right. thanks in advance.
What are you trying to learn?
Doing it that way... Is limited to the point of not being useful.
One you have to choose view zoomed data range only for it to work.
Second If you use a low number, you have to zoom way in to see only the relavent data points populate and remove bad data.
Third theres no real good choice on what > number to go with. Lower/ Higher doesn't really matter, it depends on where you go with the zoom and what the weight is doing. (you can only zoom in to 1 second view window)
So it kinda becomes this balancing act of zoom and >number%. That leaves it a balancing act between what to adjust and how much to adjust. Heisenburg uncertainty principle, just applied to mapped points.
IDK if you read my recent post on my 2019 GT. The way I showed how I control my timing. I use a similar method to the torque tables, appling broad adjustments(closer or further from target values) to a bunch of them at a time, rather than tring to narrow down where its getting the value and how much I should adjust, across just a few spot in a few tables.
Its just what you have to do, or calibrate one mapped point at a time. I've tied explaining its a linear relationship between load and torque(when engine is stoich, MBT, and STP conditions(100%VE refering to the conditions in the cylinder)) that you use for your target, its built into the axis values of the tables. Then in stock tunes the relationship is skewed, kinda like BDL and MBT use different load values in their axis. Its just the relationship is across the tables, offset a row or in between a row on the other table. Its ok to simplify the tune by making the BDL and MBT load axis the same, its okay to simplify the TTL model by making the axis match the row in the opposite table.
Mike-trying to see the values in the torque tables, using that data and appling broad adjustments(closer or further from target values). I thought the best way was to do each mapped point. After reading Murfie's post and going back to his 2019 post Individually trying to monitor and apply data is excessive. When i t come to building these complex Histograms my math skills are not as great as others on this forum. ThanksQuote:
Originally Posted by engineermike
The other way to do it, is to make all the Mapped point tables use the same values. Again it just forces you to adjust all the mapped points every change you want to make. A broad adjustment.
-Tune one mapped point at a time.
-Tune all mapped points to the same map.
-Copy values from roush/whipple calibrations and stick to making broad adjustments if needed.
If you’re trying to calibrate the torque tables then where are you getting the known “actual” values, such that the tables can be adjusted to match?
I figured absolute torque / load/ rpm is what i was trying to do with my mapped points, I know these tables blend based off Points. I though thats how i would set up my histogram, except ETC torque would only show data. easy pezzy lemon squeezy. Ha ha haQuote:
Originally Posted by engineermike
I’m still lost. The purpose of revising torque (speed density, borderline spark, fuel trims, etc) calibration is to remove or minimize error. So you are commanding a certain torque via driver demand. Something is telling you the actual torque produced by the engine is not equal to what you are demanding. What is it?
Matching demand to model, or model to demand, which ever way you are choosing to doing it, is just making the ECU "happy".
Matching your demand to an actual engine torque output value, then correcting the model, that takes a dyno. Plus doing it this way is limited to if you have access to raising/ adjusting limits when you run into them. They are numerous as there are sometimes 4 or more feedback loops all with defined IPC limits. It just won't work in some extreme applications. You then have to get creative if you want to keep a feedback loop.
Lowering WOT start/end is an example of disabling a corrective loop for torque demand. Some find it easier to just leave it disabled and not correct it, but then drivability suffers and IPC errors popup and you get wrench lights.
I don't think OP is trying to get that deep into this. I think they are just tring to follow along with what the torque is doing. For that its easier to plot ETC torque, engine brake torque, and scheduled torque in a chart. ETC and engine brake torque should follow each other, with scheduled toque remaining about 40-60 ftlbs above them. On full decel it may go a little higher but not much. The only time it will drop below 40 is on opening the throttle quickly, and even then it should only be very briefly.
Put another way, I think he is just trying to visualize this error you are asking him for, and not have to do a bunch of math.
Attachment 120266
This is Cam angles that define the MP vs a RPM- load table of where the MP weight is used. Red is heavy weight, yellow is no weight.
in certain MPs like 2-3 you could probably spot adjust. In other MPs like 14-21, the weight is spread out and adjusting the table for that MP would mean adjusting it in its entirety plus other entire tables they happen to be blending with.
Ok when logging the “brake torque” parameter (which AFAIK is calculated torque based on measured airflow, cam timing, spark timing, lambda, etc.) should follow “torque demand” closely. If it doesn’t, then the TTL or LTT tables are bad or you don’t have good control over all the components. The TTL and LTT are a function of mapped point. Is the goal of OP to fix the TTL and LTT tables?
Yes, If OP is G2G, then i can use the data to compare average against the other Maps lesson the errors.Quote:
Originally Posted by engineermike
Engine brake torque is calculated torque based on airflow, spark timing, and lambda by starting at the TTL/LTT model value and adjusting for the their measured values. I keep saying the TTL tables are at stoich, MBT, and STP. These are ideal in cylinder conditions so STP would mean 100%VE the way ford treats it off manifold absolute pressure. The intent is to have a modeled value that is as consistent as possible so it can be used against an IPC for limiting and saftey functions that don't depend on variations/ error that would be in a model of the actual values. The model factors in the effect of cam timing by having multiple mapped points. Its a simple model, relative to tring to model all variables of an actual torque output. Its nearly flat at all RPMS and loads/ torques. It takes broad adjustments well.Quote:
Originally Posted by engineermike
The driver demand would be a model of actual torque output, its different in the manuals and automatics. The automatics have the torque convertor to deal with and the model of engine toque controls the transmission pressues, again because it is expected to be consistent with so many variables fixed. Its simpler than a bunch of MPs,and because of that its inaccurate at times. Because its simpler, its usually what I reccomend correcting after copying whipple or roush tables to extend the load up. The feedback will take care of what ever error can't be removed from the table.
If you trust your TB model, you can fix the torque model tables via that. well until...
The delta above baro table in speed density is an example of ignoring that TB feedforward loop. Aboslute load when entering into boost conditions usually trends downward to something low like 60%. Speed density is thrown off to satisfy TB model no longer at standard barometric input.
You need some data you trust or know the limit you are working around. Getting to far into it again.