Boost demand is influenced by the torque model, so the target moves with operating conditions. That makes Boost Target Error the useful measure: how closely actual pressure follows what the ECU is requesting.

A steady target makes diagnosis easier, but the car needs to track changing demand properly too.

How the target is built, and the PID tables as they stood before this work, are in Boost Control on the Emtron KV12: Where the Target Really Comes From. That post describes refining the initial position table by no more than 3 percent at a time. The changes here are much larger, and they are provisional.

What the original logs showed

The earlier logs contained periods where boost remained around 10–25 kPa below target, alongside substantial changes in wastegate duty.

Three features of the original calibration stood out:

• An isolated 10.00 proportional-gain cell, at −25 kPa error with manifold pressure rising at 5 %/second, compared with 0.50 in every other cell at that error.
• Integral gain dropping to zero at ±10 kPa error, limiting its ability to correct a sustained deficit outside the narrow near-target region.
• Derivative output making sizeable contributions to duty during some transients.

Those observations justified investigating the tables, but they didn’t establish a complete replacement calibration. Some logs also had gaps exceeding a second and channels updating at different rates. That limits how confidently individual output changes can be tied to events happening a few hundredths of a second apart.

The first PID revision

The first revision removed the isolated proportional-gain spike, extended modest integral action further from target and reduced the positive-error derivative gains.

These were trial values, not a finished calibration.

Proportional gain

The only change from the original was the 10.00 cell. With it gone, proportional gain no longer depends on how fast pressure is rising.

That made the gain surface consistent. It did not establish that overshoot would improve. That cell was the overboost catch: boost well above target and still climbing was the one situation where the controller was allowed to hit hard. Removing it removes that correction too.

The table is also asymmetric, which was inherited rather than introduced. Gain is 0.20 at −5 and −10 kPa, against 0.50 at +5 and +10 kPa. Proportional correction is weaker when boost is above target than when it is below.

Integral gain

The near-target values stayed unchanged. Adding 0.010 at ±10 kPa allowed integral action to extend beyond the original narrow region, tapering towards zero at ±50 kPa.

The integral limits remained ±5 duty percentage points.

Derivative gain

The gains at +10, +20 and +25 kPa were halved from 3.00 to 1.50. The negative-error end was retained.

The output limits remained 5–80% duty, and the initial-position table was initially left unchanged.

That last decision became important.

Why boost status mattered

Some of the earlier duty changes coincided with changes between Emtron boost status 15: ON–Mass Flow Limit and 1: ON.

Those transitions could change both the final boost target and the initial duty selected from the table. A sharp duty change therefore wasn’t automatically evidence of a PID problem.

The distinction matters on this car because the final boost request is influenced by the torque model. Looking only at the base target, or only at the PID outputs, misses part of the control sequence.

Boost system status and boost PID status are also separate channels. Their numbers cannot be interpreted interchangeably.

Status names are from Emtron’s Boost Status reference.

The sixth-gear log below shows how large those transitions are. Between about 3,000 and 3,100 rpm, the status flipped between 1: ON and 15: ON–Mass Flow Limit four times. Each flip moved the target between 290 kPa and roughly 190–200 kPa, and moved commanded duty between 80% and about 31%. None of that was the PID.

At a target near 190 kPa the initial position also read zero, because the table holds zero at 200 kPa and below. From about 3,100 rpm the status stayed at 15 for the rest of the pull, so the whole overshoot happened with the mass flow limit setting the target.

The run that exposed the overshoot

The next useful log contained a sixth-gear pull from approximately 3,000 to 4,300 rpm, with no shift recorded during the pull.

It showed a clear overshoot:

Positive error means actual pressure is below target. Negative error means it is above target.

This wasn’t simply an apparent overshoot caused by the target suddenly falling. During the initial pressure rise above target, the target itself increased from approximately 261 to 271 kPa absolute.

Actual pressure climbed much faster.

The maximum logged error and maximum manifold pressure occurred at slightly different timestamps. With independently updating channels, those figures should not be forced into an exact same-row calculation.

The initial-duty table explained much of it

At approximately 3,680 rpm, boost was almost on target:

• Boost Target Error: +3.3 kPa
• Initial duty: 75.5%
• Final commanded duty: 74.6%

The engine was already reaching the requested pressure while the controller was still commanding substantial spool duty.

The original initial-position table held 100% duty through 3,500 rpm for target rows from 220 to 340 kPa. It then dropped sharply towards the values at 4,000 rpm.

For the 260 kPa target row, interpolation produced this curve:

The table tapered spool assistance according to engine speed, without directly accounting for how close actual boost had come to target.

In this sixth-gear pull, boost reached target before RPM had advanced far enough through that taper. Feedback then had to remove a large amount of duty while pressure was already rising rapidly.

Between target crossing and the pressure peak, about half a second, the taper itself took initial duty from 75.5% to about 51%, and P removed roughly another 26 points. Pressure kept rising anyway.

That strongly implicated the feedforward transition. It did not prove that every aspect of the overshoot came from that table.

What P, I and D were doing

The individual outputs helped separate the causes.

P was correcting the overshoot. It eventually removed approximately 27 duty percentage points. That correction arrived as negative error developed, but it did not prevent the pressure peak.

It was also starting from its weakest settings. Between −2 and −10 kPa the gain was 0.10 to 0.20, reaching 0.50 only at −25 kPa. This overshoot passed −25 kPa with pressure still rising, which is the region the removed 10.00 cell used to cover. The log can’t show what that cell would have done, but this run went through the conditions it was there for.

I was not winding up and driving the event. Integral output was approximately zero at target crossing and slightly negative at the peak. Increasing integral correction would not address the main cause shown here.

D had a gap around target crossing. The revised table had zero derivative gain from +5 to −40 kPa error, as the original did.

As error approached zero from the positive side, derivative gain tapered away. It then remained zero through the first 40 kPa of overboost, approximately 5.8 psi. Gain only returns beyond −40 kPa, reaching 3.00 at −50. With a worst logged error of −57.6 kPa, derivative gain was available only over the last 18 kPa or so of the overshoot.

The log shows what that did. Above target, derivative output was zero from about −13 kPa to beyond −50 kPa. Its only negative contribution there was −2.1 points, at the peak. As pressure began to fall it switched to +6 and then +12 points, with boost still 30 to 50 kPa over target.

That is derivative doing its job, resisting the rate of change. Here, though, it was adding duty to an engine that was still overboosting, and final commanded duty briefly climbed from 17% back to 46% in that window. On this run, the −50 kPa end of the D table added more duty during recovery than it removed at the peak.

The combination was the problem: high initial duty approaching target, with weak proportional and no derivative correction through target crossing.

The first D revision had retained that gap. The later log showed why it could not be treated as a validated overshoot-control calibration.

Adding resolution where the problem occurred

Seven engine-speed breakpoints were added to the initial-position table: 3,250, 3,600, 3,700, 3,800, 3,900, 4,100 and 4,250 rpm.

The existing 3,500 and 4,000 rpm breakpoints were kept. The 4,000 rpm values stayed as they were. The 3,500 rpm values did not: for the 220–280 kPa rows they came down from 100% to between 50 and 57%.

Adding columns alone changes nothing if the new values simply reproduce the old interpolation. The purpose was to create enough resolution to reshape the transition deliberately.

The revision reduced duty earlier and brought it closer to the existing 4,000 rpm values before the previous target-crossing point. It covers the 220–280 kPa rows from 3,250 to 3,900 rpm.

These are provisional trial values, chosen to reduce the excessive duty carried into target crossing. They were not calculated from measured equilibrium wastegate requirements.

At 3,700 rpm and a 260 kPa target, initial duty falls from approximately 72% to 38%. That is a substantial change, with a possible cost in spool response.

The 80% at 3,250 rpm changes less than it looks. It matches the 80% output limit, so while boost is still below target the commanded duty there is the same as before. The real reduction starts at 3,500 rpm.

The 4,100 and 4,250 rpm columns are there for later shaping. For now they hold interpolated values only.

Checking the entries mattered

The first screenshot of the edited table showed that the 280 kPa row had been missed.

That would have affected operation below 280 kPa too, because the ECU interpolates between target rows. EMtune had filled the new 3,700 rpm cell in that row with 72.5%, the original interpolation rounded to the nearest 0.5. At 270 kPa and 3,700 rpm, that would have produced approximately 55.25% initial duty, rather than the intended 39%.

The row was corrected before considering the revision complete.

A separate limitation remains above it. The 300–340 kPa rows retain the original aggressive spool profile, and the step into them is steepest at 3,500 rpm:

That matters in sixth gear. With the 10 kPa sixth-gear target offset, 290 kPa is the full-demand target in that gear, and this log requested exactly that whenever the status returned to 1: ON. The revised 220–280 kPa region does not establish that the rest of the table is suitable.

Where the calibration stands

The revised initial-position values have been checked in the calibration screenshots. There is not yet a subsequent log demonstrating their effect.

P, I and D are being held unchanged for the first comparison so the effect of the feedforward change can be assessed separately. Three closed-loop issues remain open: the derivative gap from +5 to −40 kPa, the weaker proportional gain above target now that the 10.00 cell has gone, and a −50 kPa derivative gain that adds duty during recovery from overboost.

The next assessment centres on Boost Target Error:

• Peak negative error during boost arrival.
• Time spent above target.
• Recovery after the peak.
• Any additional positive error or slower spool introduced by the reduced duty.
• Behaviour when the torque model changes the target or boost-control state.

The useful result will be a smaller, shorter overshoot without creating an excessive boost deficit elsewhere. Until that is demonstrated, this remains a calibration under development.

The lesson from this stage is specific: before asking PID to correct a boost error, examine the initial duty it is correcting around. In this run, boost was arriving on target with roughly three-quarters duty still commanded. That was the first problem to address.

More to come.

The post Tuning the Supra’s Boost Control: PID Gains Were Only Part of the Problem first appeared on BlownByTwins.

The post Tuning the Supra’s Boost Control: PID Gains Were Only Part of the Problem appeared first on BlownByTwins.

What is worth showing is how the pieces fit together. Where the boost target actually comes from, which tables do the real work, and how the PID is kept out of the way.

Each section is marked. Verified means it comes straight from the calibration. Theory means it is my reasoning, not something I have measured. Observed means it is how the car behaves on the road.

Configuration

Status: Verified

• 2JZ-GTE VVTi, 3.4 litre, Pulsar G42-1200, pump fuel
• Turbosmart 60 mm wastegate, 15 psi spring, which gives 18 psi as installed
• Single Link boost control solenoid
• Emtron KV12, closed loop, absolute target, manifold pressure as the control input

Who did what matters here, so to be clear: the structure, the lockouts and the base duty cycles are SRD’s. My changes are to the initial position table, made from logged corrections, and none of them is more than 3 percent.

Where the target comes from

Status: Verified

Emtron builds the boost target from a base table, adds a stack of offsets, then clamps the result. Here is the base table:

Look at the biggest number in it. 100 kPa absolute is atmospheric. The base table on its own never asks for any boost at all.

The boost comes from the first of the user offsets:

Once the manifold reaches atmospheric, 200 kPa is added to the target. So with the pedal past 40 percent:

• Below 3,000 rpm: 80 + 200 = 280 kPa absolute
• From 3,000 rpm: 100 + 200 = 300 kPa absolute

And then the clamp. The Boost Target Clamp is 300 kPa absolute, roughly 2.0 bar of boost at sea level. Whatever the offsets add up to, the target cannot go past it. That is deliberate. The car runs on pump fuel, and the clamp is the safety switch that stops anything else in the stack asking for more than the fuel will take.

The rotary columns being identical is also deliberate. Every traction setting gets the same boost ceiling, and the torque model decides how much of it is actually used. Boost is not the throttle on this car. Torque is, and that is covered in Traction Control on 1,114 whp.

Why the offset can look on manifold pressure

Status: Theory

An offset indexed on manifold pressure is a feedback loop: as pressure rises from 50 to 100 kPa, the target rises with it. That would be a problem if the solenoid were active through that range. It isn’t, which is the next table.

When the solenoid is allowed to work

Status: Verified

The solenoid stays off until the manifold is already 10 kPa above atmospheric. By then the user offset has finished ramping in and the target is fixed. Off boost, cold, or at a whisker of throttle, the wastegate simply does what its spring tells it.

What takes boost away

Status: Verified

Three offsets pull the target down. Two are protection, and both are indexed against the target itself, so the higher the target, the more they take.

The third is by gear, and it is there for the gearbox rather than the engine:

Sixth, seventh and eighth lose 10, 20 and 30 kPa to protect the ZF’s clutches from slip. Where that gearbox runs out of capacity is covered in Where the Stock ZF 8HP70 Gives Up.

The table that does the work

Status: Verified

Everything above decides what boost to ask for. This decides how to get it. The initial position table is the feedforward: the solenoid duty the ECU applies before the PID has done anything at all.

Read the 300 kPa row from left to right and it tells the story of a pull.

2,000 to 3,500 rpm: 100. Hold the wastegate shut and let the turbo spool. In practice this is 80, not 100, because the Max Duty table clamps the output at 80 percent everywhere. The 100 in the table is a way of saying “as much as you’re allowed”.

4,000 rpm: 32.5. The turbo is lit. Drop straight to the duty that holds 300 kPa, so the gate opens instead of letting boost run past the target.

5,500 to 6,000 rpm: 26. The lowest duty in the row.

6,500 to 8,000 rpm: 30 rising to 42. More duty is needed to hold the same target as rpm rises.

The lower rows show the spring at work. The spring holds 18 psi as installed, about 225 kPa absolute. So at a 220 kPa target the duty falls away as rpm rises, and by 7,500 rpm it is zero: the spring alone is enough. Every row above that is the solenoid adding pressure on top of the spring.

Why the duty rises at the top

Status: Theory

A wastegate valve is pushed open by exhaust pressure acting on its face, as well as by boost pressure acting on its diaphragm. As rpm rises, exhaust manifold pressure rises with it, and the valve gets more help opening. To hold the same boost, the solenoid has to fight harder, so the duty goes up. I don’t measure exhaust manifold pressure on this car, so that is the mechanism I’d expect rather than one I have logged.

How I refined it

Status: Verified

If the initial position were perfect, the PID would have nothing to correct. So the logs tell you where it is wrong. Wherever the closed loop consistently added or removed duty in the same cell, the feedforward was out by about that much.

I moved those cells towards what the PID was asking for. None by more than 3 percent. It’s refinement, not a rebuild. The aim was to take work away from the closed loop wherever the data said it was doing work it shouldn’t have to.

The PID: kept on a short lead

Status: Verified

The loop runs at 35 Hz, against Emtron’s typical 25, with a deadband of ±0.1 kPa and no input or target filtering. Emtron’s own note on the control rate is worth repeating: change it and the gains need re-tuning, because every gain is effectively per calculation.

All three gains are scheduled on boost target error. Negative error means boost is above target.

The integral is clamped as well: the Positive and Negative Integral Limit tables hold it to ±5 percent duty at every rpm. Overall output is held between a 5 percent minimum and an 80 percent maximum.

One cell in the proportional table stands out. At -25 kPa of error, with manifold pressure rising at 5 percent per second, the gain is 10.00 instead of 0.50. That is the overboost catch. Boost well over target and still climbing is the one situation where the controller is allowed to hit hard.

Why it is shaped this way

Status: Theory

Proportional gain is smallest near target. Once the boost is where it should be, small errors are corrected gently, so the solenoid isn’t hunting.

Integral only works within 5 kPa of target and is zero beyond 10. During spool the error is enormous, and an integrator running through that would wind up and then overshoot when the turbo arrives. Here it simply doesn’t run until boost is close. Add the ±5 percent clamp and the integrator can trim the feedforward but never replace it.

Derivative is active between 10 and 25 kPa below target. That is boost on its final approach, rising fast towards the target. Derivative reacts to rate of change, so it starts opening the gate before the boost gets there, taking the edge off the arrival rather than correcting an overshoot afterwards.

It’s the same philosophy as the traction control. Feedforward does the work. The closed loop is soft near target, gated where it could do harm, and clamped so it can never take over.

Housekeeping

Status: Verified

Two things in the file worth knowing if you are reading your own:

• The Boost Solenoid Deadtime table is zero from 10 to 20 V, so solenoid duty isn’t corrected for supply voltage.
• The Boost Overall Target Trim is zero. It’s a single number that shifts every target at once, which makes it a quick way to test a change without touching the tables.

Does it work?

Status: Observed

Spooled by 3,400 rpm. On target by 4,200. And from there it pulls, hard, all the way to 8,400.

That lines up with the table. The 100 percent hold ends at 3,500, the duty drops to 32.5 at 4,000, and the car is on target 200 rpm later.

The principle

Get the feedforward right and the PID has almost nothing to do. Then let the logs tell you where it isn’t right: wherever the closed loop is consistently correcting, the initial position is wrong by that much.

Every number here is specific to this turbo, this wastegate, this spring and this fuel. The data is not transferable, but the principle is.

How the torque model decides how much of this boost is actually used is in Traction Control on 1,114 whp. Why the top gears lose boost is in Where the Stock ZF 8HP70 Gives Up. The fuel system feeding all of it is in Staged Injection on the Emtron KV12. Full specification is on the Supra project page.

The post Boost Control on the Emtron KV12: Where the Target Really Comes From first appeared on BlownByTwins.

The post Boost Control on the Emtron KV12: Where the Target Really Comes From appeared first on BlownByTwins.

This is how I worked outwards from the symptom until the log told me where to look, and what the arithmetic said once I got there.

Ruling things out

Status: Verified

I expanded the log window out and walked the closed loop items one at a time. First question: was idle control intervening during the downshift? It was not. Verified and set aside.

The next thing I noticed was that air mass was going erratic, and that is worth being precise about, because the air mass model on this car is a blend. Below 100 kPa it runs the throttle mass flow model exclusively and blends towards speed density above that. In the region where this fault appears the air mass estimate is therefore a function of throttle effective area and pressure ratio and nothing else. No speed density term diluting it, no trapped mass term in the estimate.

So erratic air mass in that region means the blade, or the area characterisation, or both. It cannot mean much else.

Pedal throttle demand translation was smooth through the whole event. The driver demand table was not doing this. That left the DBW loop, and the DBW PID was the gold seam.

What the loop was doing

Status: Verified

Three things stand out.

Proportional output is saturating at minus 100 percent repeatedly, and topping out near plus 63. That asymmetry is not the axis autoscaling being unhelpful. It is the loop reaching its closing clamp over and over while never reaching the opening one.

Integral output is sitting around plus 24 percent and climbing slowly across the window. An integrator that keeps accumulating while the proportional term is pinned at its clamp is not doing the job an integrator is for.

The motor command is swinging roughly minus 65 to plus 100 percent while the measured blade position only moves a few percent either side of 15. The blade is inertially filtered. It physically cannot follow a command oscillating at that rate, so the engine never sees the full excursion.

That last point is the one that connects back to the shift. The engine does not see it, but the model does. Torque estimate comes from air mass, air mass in this region comes from the throttle mass flow model, and that model reads blade position directly. Every percent of blade wobble goes into the torque estimate whether or not the engine produced any of it.

The gearbox was reacting to torque noise that did not exist at the crankshaft.

The arithmetic

Status: Verified

This is where the log stops being suggestive and starts being conclusive. At the cursor, 38.138s in the screenshot above:

• Servo Position Main: 3.7 percent
• Proportional output: 0.9 percent
• Integral output: 24.3 percent
• Derivative output: 0.0 percent
• Motor command: 6.2 percent

My feed-forward table runs minus 30 at 0 percent and minus 15 at 5 percent. Interpolated linearly, feed-forward at 3.7 percent is minus 18.9.

Two things fall out of a match that close. Motor command is the summed controller output rather than a measured position, and feed-forward interpolates linearly between breakpoints.

But the finding is the third thing. At a near steady 3.7 percent blade position, the integral had wound to plus 24.3 for no purpose other than to cancel a feed-forward of minus 18.9.

The feed-forward in the 0 to 5 percent band is asking for roughly 25 points of closing duty that the throttle body does not need. The integral is spending its entire authority undoing it. That is a large stored state sitting permanently in the loop, and every time the proportional term saturates and the target moves, that state has to unwind before anything else can settle.

It is a far better explanation for a sustained oscillation than any single gain cell.

The feed-forward step, and what it actually is

Status: Provisional

There is a 25 point change in motor duty for a 1 percent movement in target between 5 and 6 percent, and the log crosses that region immediately before one of the instabilities. My first instinct was that this was simply wrong. It is not, and this is the part most likely to be copied badly, so it is worth saying plainly.

The return spring on a DBW body pulls the blade towards its limp home position from both directions. Below limp home you need negative duty to hold the blade down against the spring. Above it you need positive duty to hold it open. A feed-forward table that changes sign between two cells is not a tuning error. It is the table telling you where limp home sits.

Delete the step and you have not removed the discontinuity. You have removed the compensation for it, and handed the spring preload to the integrator.

The real problems are different. First, the magnitude of the low band values, which the arithmetic above says are too negative. Second, a 25 point change interpolated across 1 percent of travel behaves like a gain of 25 through a region the blade is oscillating in.

The proportional gain table

Status: Provisional

The low position P gains are aggressive, and lopsided towards the negative error side.

Reading negative error as blade above target, the closing correction gets close to twice the gain available for an equivalent opening error, at every row.

The spring makes this more interesting than a simple symmetry argument, because the asymmetry it creates flips across limp home. Above limp home the spring already assists closing, so the loop needs more authority to open and less to close. Below limp home it reverses.

A table that favours the closing side at every row is therefore directionally right in the 5 percent row and wrong in the 15 and 25 percent rows. The blade sits at 15 to 17 percent through this event.

One caveat that anyone copying this needs to take seriously. The whole reading above depends on the error channel being target minus actual. If your ECU signs it the other way, the argument inverts and so does the revision. Confirm it on your own log before you touch a cell: find a step where the blade visibly lags a rising target, and read the sign.

What I have not proved yet

I changed two tables at once. Until they are separated, no outcome can be attributed to either.

I have not measured the true limp home position. The right way is to unpower the driver and read the TPS, then check whether the feed-forward breakpoints actually straddle it. If limp home sits at 6.5 percent rather than between 5 and 6, the compensation is being applied in the wrong place, and that alone would explain the instability without a single gain change.

I have not confirmed the error sign convention from a step.

And I left the 0 and 5 percent feed-forward cells alone, which are the two cells the arithmetic actually points at.

I’m not declaring this as “fixed” yet. However, the gear change is smoother, particularly the upshift. The lower speed acceleration is cleaner and everything just feels much more refined. Always remember the first few percent of opening on a throttle blade are extremely non-linear, and even more so on a 82mm throttle body.

The test that closes it

With the loop stable, park the blade at steady positions across 0 to 25 percent, in 2 percent steps through the 0 to 8 percent band, and log feed-forward and integral at each point.

Wherever the integral is non-zero at steady state, the feed-forward is wrong by exactly that amount. That lets the whole low band feed-forward table be built by subtraction rather than by iteration. The position at which feed-forward crosses zero and the integral stays at zero is the true limp home. Any step within the sweep settles the sign convention.

Run it on the same road and the same coast down and you also get a genuinely matched before and after, rather than two logs taken a week apart under different load.

The principle

The data is not transferable, but the principle is.

A feed-forward table and an integrator are solving the same problem from opposite ends. If the integrator is carrying a large standing value at a steady operating point, the feed-forward is wrong by that amount, and you can read the correction straight off the log instead of iterating towards it.

The throttle area table that the whole torque model sits on is covered in Throttle Body Effective Flow Area, and the same feed-forward versus PID argument applied to traction control is in Traction Control on 1,114 whp. Full specification is on the Supra project page.

If you run a DBW loop and have taken a different view on any of this, particularly the limp home reasoning or the gain asymmetry, I would like to hear it.

The post Erratic Shifts and Idle Overfuelling on the 2JZ: Finding a DBW Feed-Forward Fault first appeared on BlownByTwins.

The post Erratic Shifts and Idle Overfuelling on the 2JZ: Finding a DBW Feed-Forward Fault appeared first on BlownByTwins.

Most discussion of traction control stops at “it cuts power when the wheels spin”. That describes about a third of what is actually happening, and it is the least interesting third. The system on this car has a predictive half that tries to never need the reactive half, and the whole design is aimed at keeping the reactive half quiet.

This is how it is set up, and why. Every table is reproduced in full.

Configuration

Status: Verified

• Emtron KV12, torque based traction control
• 3.4 litre 2JZ-GTE VVTi, 1,114 whp on E85, torque limited to 880 lb ft
• ZF 8HP70, 2.93 final drive, OS Giken LSD
• Continental SportContact 7, 265/30/19 front and 295/30/19 rear
• Four individual wheel speeds, three axis internal accelerometer
• Eight position rotary on the steering wheel, over CAN

Everything below is my own work. The base calibration on this car came from SRD Tuning, but the traction control strategy is mine start to finish, which is the only reason I can show you the tables.

The predictive half: torque feedforward

The core of the system is a table that answers one question: at what engine torque does this car lose traction?

It is indexed on engine torque with no reduction applied, against slip target error. The ECU looks up that number and feeds it forward as the torque target before any measurement of actual slip has influenced anything.

That is the whole idea of feedforward. If the model is right, the engine never makes more torque than the tyres can take, the slip never happens, and the closed loop has nothing to correct.

Look at the first two columns before anything else. At 50 Nm of engine torque the table returns 50, and at 150 it returns 150. Below about 150 Nm it is a pass through: the feedforward is not limiting anything, because at those loads there is nothing to limit.

And this is where the normalisation matters

Read along the zero slip error row and the values climb: 245.3, 340.5, 430.9, 478.9, 527.0, 575.0. And then they stop. Flat at 575 Nm from 750 Nm of engine torque all the way to 1,250.

That plateau is deliberate and it is the single most important thing in the setup.

Extend the slope before the plateau and an unclamped table would be asking for roughly 815 Nm at the top of the range. The engine makes 1,193 Nm. So without the clamp, the feedforward would be handing the PID a target the tyres cannot deliver, and the PID would spend its entire life trying to close a gap that physics will not close.

A saturated PID is not a controller. It is an actuator held wide open. You lose all the proportionality that makes traction control feel like assistance rather than interference.

Clamping the feedforward at something the tyres can actually deliver means the PID always has authority in reserve. That is what “normalised” means here, and it is why the system feels like it is helping rather than fighting.

Normalised against third

The feedforward table is written for third gear. Everything else is scaled off it by two correction tables.

Correction Table 1 is indexed on gear against rate of change of engine speed. In first at low dRPM the correction is zero. By eighth at 4,000 dRPM it is minus 32 percent.

Which makes sense once you think about what dRPM means in each gear. Engine speed rising at 4,000 rpm per second in first is normal acceleration. The same rate in eighth means the driven wheels are going somewhere the car is not. The correction is reading the rate of change as evidence of impending slip, and pulling the target down before the slip calculation has caught up.

Correction Table 2 does the same job against slip target error directly, from minus 40 percent at large negative error up to plus 10 at zero. That positive 10 at zero error is worth noticing: when the car is exactly on target, the feedforward is allowed to ask for slightly more than the base table says.

The slip target, and what the rotary actually does

Status: Verified

Here is the part I had not seen anyone else do.

The target slip table is indexed on lateral G, from minus 1.5 to plus 1.5, against the rotary position from the steering wheel.

Almost every row is a dome. Maximum permitted slip in a straight line, tapering symmetrically as lateral load builds in either direction. At the loosest setting the car allows 28 percent slip straight ahead, falling to 25 at 1.5 G. At the tightest, 2 percent straight ahead and 1 percent once the car is properly loaded up.

Setting 1 is the exception, and I would rather point at it than pretend it fits. It permits 2 percent straight ahead, rises to 3 percent at around 0.75 G in either direction, and comes back to 2.5 at full lateral load. It is the only row in the table that allows more slip while cornering than it does in a straight line.

So the rotary is not a gain switch and it is not an on/off. It selects how much slip you are allowed as a function of how hard you are cornering, and the system tightens automatically as lateral load increases without the driver doing anything.

And then speed offsets all of it

Lateral G is not the only input to the slip target. A second table offsets it by road speed, and it does a lot of work at both ends.

Below 25 kph every setting adds nine percentage points of slip, and the loosest adds twenty five. That is the launch allowance. You cannot get a car like this moving from rest on a target of 2 percent, and without that offset the system would strangle it off the line.

Between 45 and 160 kph the offset is zero and the lateral G table stands on its own. Above 180 it goes negative, and by 330 kph it is pulling back between 2 and 9.4 points depending on the setting.

Which is the right way round. Wheel slip at 40 kph costs you a bit of time. Wheel slip at 300 kph costs you rather more than that.

The reactive half: a deliberately soft PID

Status: Verified

When the feedforward is not enough, the PID takes over. And the gains are the opposite shape to what most people would write. All three share exactly the same breakpoints, so they go in one table.

Proportional gain at zero slip error is 0.20. At minus 25 percent error it is 3.00. Derivative runs the same way, 0.10 at zero, and it saturates at 3.00 from minus 20 onwards.

Both are smallest near target and largest far from it.

That is a controller designed to be felt as little as possible. Around the target, where you spend almost all of your time, the loop barely reacts and the feedforward carries the car. Only when things run properly away does it bite hard.

Tune it the conventional way round, with high gain near target for tight regulation, and you get a car that nibbles at the throttle constantly and feels like it is arguing with you.

Integral is almost switched off, on purpose

Look at the integral row against the other two. Peak gain is 0.020, near target. At minus 25 it is zero.

Zeroing the integral term exactly where the error is worst is anti windup by design. When the car is genuinely out of shape, the integrator stops accumulating instead of building up a correction you then have to unwind on the way out. An integrator that has wound up during a slide gives you a second event when it releases, and the second one is usually the one that catches people out.

The rest of the PID setup backs that up:

• Integral control rate: 200 Hz
• Integral positive clamp: 50.0 Nm
• Integral negative clamp: -50.0 Nm
• Minimum torque clamp: 50.0 Nm
• Slip target filter: 4

Fifty Nm either side is a narrow band on an engine making 1,193. The integrator is there to trim, not to intervene.

And the PID does not always run

Below 300 Nm of driver demand it is zero across the whole row. The closed loop simply does not run.

Above that it opens up as a staircase. At 300 Nm the loop only runs once slip error is worse than minus 3 percent. Every additional 100 Nm of driver demand brings one more column into play, until at 1,000 Nm it is active everywhere except the far positive corner.

So the amount of authority the closed loop has is itself a function of how much the driver is asking for. At low demand, feedforward handles everything alone, which means the PID cannot introduce noise into normal driving, because at normal driving loads it is not switched on.

What it is allowed to do about it

Emtron gives you three actuators for torque reduction, in a priority order. Mine reads throttle area, then ignition retard clamped at 11 degrees, then OFF.

Cutting is disabled. On a car making 1,114 whp, the harshest tool in the box is not in the box.

The throttle area minimum clamp bottoms out at 10 percent, so it never closes the throttle fully either. Torque reduction happens by moving the plate and pulling timing, and nothing else.

That is a road car decision. Fuel or ignition cutting is fast and effective and it feels like being kicked. On a car that has to be pleasant on a motorway and predictable in the wet, an intervention that arrives as a smooth reduction rather than a hammer blow is worth more than the extra tenth of response.

Does it work?

One number from a road log, second gear, full throttle:

Torque reduction by retard: 8.1 percent.

Eight percent, in retard, on the second priority, with cutting unavailable and throttle intervention having already done its part. That is the system working gently in the conditions where a badly normalised setup would be reaching for everything it had.

It is one data point from one log, so treat it as an illustration rather than proof. But it is the shape of result the whole design is aimed at.

The principle, if you take nothing else

A PID is not there to make your feedforward work. It is there to handle what the feedforward could not have known about: a damp patch, a change in surface, a mid corner bump.

If your feedforward target is unrealistic, the PID spends its authority correcting your model instead of correcting the road. It saturates, it escalates through the actuator list, and the car feels like it is fighting you.

Normalise the target to something the tyres can actually deliver, gate the loop so it only runs when it is needed, keep the gains soft near target, and the reactive half stays quiet almost all the time.

Which is the point. The best traction control is the one you do not notice.

One thing to be clear about

Every number above is specific to this car: this power, these tyres, this gearbox, this weight distribution. The data is not transferable, but the principle is.

I have published the tables in full because seeing how something is structured teaches you far more than reading a description of it. Copy the structure. Do not copy the values.

None of this works without trustworthy wheel speeds, which on a staggered setup is less automatic than it sounds. That is covered in Staggered Tyres and Traction Control. The throttle area table that the whole torque model sits on is covered in Throttle Body Effective Flow Area. Full specification is on the Supra project page.

If you run torque based traction control and have taken a different view on any of this, particularly the gain shape, the setting 1 anomaly or disabling cut, I would like to hear it. This is the part of the calibration I have changed my mind about most.

The post Traction Control on 1,114 whp: Feedforward, PID, and Why It Never Cuts first appeared on BlownByTwins.

The post Traction Control on 1,114 whp: Feedforward, PID, and Why It Never Cuts appeared first on BlownByTwins.