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.

This is not a list of gains to copy. Gearing, tyre size and mass change every number below. What carries over is the method: take one sample log, and derive from it what each part of the controller is actually doing. Each check comes with the formula to redo it on your own car.

The control path

Emtron is not commanding throttle position from speed error. The chain is:

Speed error → Cruise PID → torque correction
Torque Target Base + correction → Torque Target Final
Torque Target Final → TMF → throttle-area demand → DBW → engine torque

That ordering matters. Cruise PID behaviour is only meaningful once the layers below it are stable, because any error in the throttle-area model or the DBW loop arrives at the cruise controller looking like road load. On this car the throttle-area table and DBW PID were both reworked first.

How Emtron scales the gains

Emtron’s cruise gains map directly to torque:

• P = 1.00 gives ±10 Nm for every 1 km/h of speed error.
• I = 0.010 gives ±10 Nm/s for every 1 km/h of sustained speed error.

So P = 1.20 should give 12 Nm per km/h immediately, and I = 0.003 should add 3 Nm every second per km/h for as long as the error lasts. Those two numbers are what the log gets checked against.

The sample log

The sample is one drive with cruise set three times, all in eighth gear at around 120 km/h, about four minutes of cruise in total. The longest engagement ran for just over three minutes on an ordinary undulating road.

Summary of the three engagements, ignoring the first five seconds after each set:

Deviations of up to about ±3 mph, slow rather than fast. The checks below work out why.

What to look for

1. Is cruise using the speed you think it is?

Log Cruise - Speed Input alongside whichever channel you selected as the source. Here the source is Front Axle Speed (Avg), and the two match sample for sample. On a rear-wheel-drive car that is the right source: the front wheels are undriven, so their speed is road speed, not road speed plus whatever slip the rear tyres are carrying.

If the two channels disagree on your car, stop there. Nothing else in the analysis means anything until the controller and the log are looking at the same speed.

2. What is base torque actually doing?

It is tempting to read Cruise - Torque Target Base as a live road-load estimate. In this log it isn’t. It is captured when SET is pressed (189, 190 and 215 Nm on the three runs) and then stays flat for the whole engagement. Every newton-metre of movement in Final is closed-loop correction.

That makes the moment you press SET part of the calibration. Run 3 was set at 215 Nm, more than the car needed to hold 119 km/h, and it spent the whole run about 2 km/h over target with the controller holding a negative correction the entire time. The base is a starting point. Whatever it gets wrong, the closed loop has to carry.

3. Does P match the setting?

Make a derived channel for the correction and plot it against speed error:

Speed Error = Cruise - Speed Target − Cruise - Speed Input
Correction  = Cruise - Torque Target Final − Cruise - Torque Target Base

A straight-line fit gives 11.1 Nm per km/h, which looks slightly low against the 12 expected from P = 1.20. Look closely at the middle of the plot, though: the samples step flat across zero. That is the ±0.2 km/h deadband, and Emtron does not just zero the error inside it. It subtracts the deadband from the error everywhere:

P term = 10 × P × (|Speed Error| − deadband) × sign(Speed Error)

Fit against that instead and the slope comes out at 12.0 Nm per km/h, with every sample within 1 Nm of the line, which is the resolution of the logged torque channels. P is doing exactly what its setting says.

4. Is the integral doing anything?

This is the check that matters most, and it falls straight out of check 3. Subtract the P term from the correction. Whatever is left is the integral and derivative:

Residual = Correction − P term

Then work out what the integral should have contributed. Accumulate the deadbanded speed error over the run and multiply by 1000 × I. For the long run in the sample, the error integrates to about −200 km/h·s. At I = 0.003 that is roughly −600 Nm of integral action, enough to pin the correction against the −50 Nm clamp for the second half of the run.

In the sample log the residual is zero to within the 1 Nm logging resolution. The correction is proportional only. You can see the consequence on the road too: between about 85 and 110 seconds into the long run, the car sat 3 to 5 km/h over target while the correction barely moved. A working integrator would have kept pulling torque off for the whole of that period.

When this check comes back empty, adjusting the integral gain is the wrong next move. Find out why the integrator is not contributing first: whether it is gated by a condition, scaled differently from what you expect, or whether the calibration in the car is not the one you think you loaded. If your firmware can log the individual cruise P, I and D outputs, log them.

5. Translate the error into your own car

A proportional-only cruise controller always leaves a steady error when the load changes, because it needs an error to make torque. The size of that error is set by P and by your gearing, which is why nobody else’s numbers transfer.

The extra engine torque a gradient demands:

ΔT_engine = (m × g × sin θ × r_tyre) / (gear ratio × final drive)

And the speed error a P-only controller settles at to deliver it:

Δv ≈ ΔT_engine / (10 × P) + deadband

For the Supra in eighth (about 0.67) with the 2.93 final drive, a 0.33 m tyre and roughly 1650 kg, a 2% gradient needs about 55 Nm more at the engine. At 12 Nm per km/h that is about 4.8 km/h of steady error, almost exactly the ±3 mph drift in the sample log.

Put your own mass, tyre and gearing in and you will get a different number. A car cruising in a lower gear, or on a shorter final drive, sees less engine torque per percent of gradient and a smaller error for the same P.

6. Is D visible?

Not at D = 0.10 in this sample. Once the P term is removed there is nothing left above the logging resolution, so nothing can be attributed to D either. At cruise the rate of change of speed error is small, and so is anything a derivative term makes from it.

Changes since the sample

Integral Gain has since gone from 0.003 to 0.005 and then to 0.007, one step at a time, with P held at 1.20, D at 0.10 and the deadband and clamps unchanged.

Each step gets judged by check 4 before anything else. A road test on its own cannot separate a better controller from a flatter road. If the residual is still flat at 0.007, the gain was never the problem.

When the integral is working: what to expect

From torque to road speed, a car is close to a pure integrator: net torque sets acceleration, and speed is acceleration accumulated. Wrap a PI controller around that and you get a second-order loop whose damping depends on the ratio of the two gains:

k  = (gear ratio × final drive) / (r_tyre × m) × 3.6     km/h per second, per engine Nm
ζ ≈ (k × 10 × P) / (2 × √(k × 1000 × I))

Raise I with P fixed and the loop recovers faster but with less damping. For the Supra’s numbers, damping falls from about 0.39 at I = 0.003 to 0.26 at I = 0.007, and P would need to be around 1.8 to 1.9 to hold the original damping. Your k is different, so your numbers will be too.

Each tuning error then has its own signature in the speed trace:

• Too little P: weak immediate correction. The car sags at the start of every disturbance.
• Too much P: fast oscillation around target, set by the delay in the torque path.
• Too little or no I: a steady offset that follows the gradient, which is what the sample log shows.
• Too much I: slow overshoot and repeated crossing of target.
• D: works on acceleration, which is small and noisy at cruise. If overshoot appears, P is usually the stronger lever.

Log layout

Everything above comes from four panels and three derived channels.

Gear and shift state are there to exclude kickdowns and upshifts. They change the torque-to-speed relationship mid-run and will look like controller misbehaviour if left in.

Current configuration

The broader point

On a torque-managed standalone, cruise depends on the ECU understanding throttle area, airflow, engine torque, DBW response, road speed and transmission state. Get any of those wrong and cruise will find it.

The sample log is a good example of why gains should be derived from the log rather than from how the car feels. The drift looked like a weak integral. The log showed P working exactly as set, a base torque frozen at the moment SET was pressed, and an integral contributing nothing at all. Three different facts, and only one of them is about the integral gain.

Run the same six checks on your own log before you change a number.

Part of the Emtron KV12 series on a 3.4 litre 2JZ. Cruise leans on the same torque model as the traction control strategy and the throttle-area table underneath both. Full specification is on the Supra project page.

The post Tuning Cruise Control on a 1,000+ bhp Toyota Supra first appeared on BlownByTwins.

The post Tuning Cruise Control on a 1,000+ bhp Toyota Supra appeared first on BlownByTwins.

Not for speedometer calibration. For whether your traction control knows the difference between wheelspin and a rear tyre that is simply a different size to the front one.

The problem, in one number

My car runs 265/30/19 at the front and 295/30/19 at the rear. Work the rolling diameters out:

• Front: 482.6 mm rim + (2 × 79.5 mm sidewall) = 641.6 mm
• Rear: 482.6 mm rim + (2 × 88.5 mm sidewall) = 659.6 mm

The rear is 2.8 percent larger, so for any given road speed it turns about 2.7 percent slower than the front. Put the other way round, the front turns 2.8 percent faster than the rear, which is the figure you will see between the raw channels.

A traction control strategy that compares driven wheel speed against undriven wheel speed and calls the difference slip would therefore see a permanent 2.8 percent slip. At a steady 50 mph on a flat road, doing nothing. Every slip target you set would be sitting on top of an offset that has nothing to do with grip.

What the ECU does about it

Status: Verified

On the Emtron you give it two things per axle: the number of teeth on the ABS reluctor, and the tyre size.

In my case that is 48 teeth on the Toyota hubs at both ends, and the two tyre sizes above. The ECU converts each tyre size string into a rolling diameter, combines it with the tooth count, and derives a scalar that normalises one axle against the other.

The tooth count cancels here because both ends are 48. On a car with different reluctors front and rear it would not, which is exactly why the ECU asks for both rather than just the tyre size.

You can watch it work. At a steady cruise on a flat road, in the same log, at the same moment:

• Raw wheel speed channels: 2.8 percent apart. Exactly the geometry, uncorrected.
• Drive Slip: 0 percent. Corrected, and reading the truth.

That pair is worth knowing about, because if you go looking at raw wheel speed channels and find them 2.8 percent apart, nothing is wrong. Those are sensor channels. The correction is applied downstream, inside the slip calculation, and the corrected channel is the one that tells you whether it is working.

The failure mode nobody warns you about

The correction is derived from a tyre size you typed in. It has no way of knowing what is actually bolted to the car.

This car has been through 18 inch wheels on Yokohama A052, and is now on 19 inch Rays G025 with a staggered Continental SportContact 7 setup. If the configuration still held the old sizes, every wheel speed on the car would be wrong, road speed would be wrong, and the slip calculation would be wrong.

And none of it would look broken. The ECU would be doing correct arithmetic on stale inputs, confidently, forever.

So: change your wheels or tyres, change the configuration. It belongs on the same checklist as the alignment.

What geometry cannot reach

Status: Working conclusion

The scalar is calculated from the free rolling diameter, meaning the tyre’s size when nothing is pushing on it. What the wheel actually rolls on is the loaded radius, which is smaller, because the sidewall deflects under the weight of the car.

That deflection is not the same front to rear. My rear sidewall is 88.5 mm against 79.5 mm at the front, and it carries more load. So the real ratio between the two axles is not quite the ratio the ECU calculated.

Worse, it moves. Under hard acceleration weight transfers rearward, the rear sidewall squashes further, the rear rolling radius shrinks, and the rear wheels read faster for the same road speed. The system sees slip that is partly just the tyre changing shape.

Which means the residual error is largest exactly when traction control is working hardest, and it errs in the direction of over-reading slip.

Add the slower drifts on top: cold pressure against hot, a fresh tyre against a half worn one, a summer session against a winter one. All of them change rolling radius. None of them change the number in the configuration.

I have not quantified any of that on this car. It is reasoning from geometry rather than measurement, and it stays a working conclusion until there is a number behind it.

The check that takes two minutes

Flat road, steady 50, constant throttle, no load transfer. Log all four wheel speeds and your corrected slip channel.

If corrected slip reads zero, your static correction is right. If it reads a consistent offset, either your configured tyre sizes do not match the car, or your tyres have worn far enough to matter.

Do it after every tyre change, and once mid-season. It costs nothing and it is the only way to know whether the number your traction control is acting on means anything.

Why this matters more than it sounds. Everything the traction control does downstream, the slip target, the feedforward torque model, the PID that corrects what the model missed, is built on the assumption that slip is being measured correctly. Get this wrong and every one of those tables is being tuned against a number that has an offset baked into it. The strategy that sits on top of these wheel speeds is covered in Traction Control on 1,114 whp.

Full specification and the wheel and tyre setup are on the Supra project page.

If you run staggered tyres and have measured your loaded radius rather than assuming the free one, I would like to know how far apart they were. That is the number this article is missing.

The post Staggered Tyres and Traction Control: What the ECU Corrects, and What It Can’t first appeared on BlownByTwins.

The post Staggered Tyres and Traction Control: What the ECU Corrects, and What It Can’t appeared first on BlownByTwins.

A straight line is the one shape the table physically cannot be.

This isn’t a precision quibble. In the operating band where the engine spends most of its life, meaning idle, overrun, light cruise and the first few percent of tip-in, a linear table over-states flow area by a factor of two to four. Every downstream calculation inherits that error: fuel mass, torque estimation, pedal mapping, and on a drive-by-wire car, the inverse map the controller uses to decide where to put the plate.

This article covers the geometry of why, the compressible flow equations that turn area into mass, what a throttle mass flow (TMF) model does with the result, and a repeatable method for building a table that’s correct rather than convenient.

Part 1: The geometry

The projection

A butterfly valve is a disc on a shaft in a cylindrical bore. Air gets past it through whatever cross-section the disc doesn’t block, viewed along the bore axis.

Set up coordinates: the bore axis is z, the shaft runs along x, and the plate rotates about the shaft. Call the plate’s angle from the bore-normal plane α, and the angle it sits at when hard against the closed stop α₀.

For the plate to seal in a cylindrical bore at angle α₀, it can’t be a circle. The intersection of a cylinder of radius R with a plane tilted at α₀ is an ellipse with semi-axes R and R/cos α₀. So the plate is elliptical, with the long axis running across the shaft.

Project that plate onto the plane normal to the flow at an arbitrary angle α, and you get an ellipse with semi-axes:

• R along the shaft
• R · cos α / cos α₀ across it

Which gives the blocked area directly:

A_blocked = πR² · (cos α / cos α₀)

And therefore:

A_open = πR² · (1 − cos α / cos α₀)

Two sanity checks. At α = α₀ the cosine ratio is 1 and open area is zero, because the plate fills the bore. At α = 90° the ratio is zero, open area equals bore area, and the plate is edge-on. Both correct.

Why it can’t be linear

Differentiate the open area with respect to α:

dA/dα = πR² · sin α / cos α₀

Near the closed position, sin α is small. The area barely moves. Expand the cosine for small openings and you get area growing with the square of the angle, not the first power:

1 − cos α ≈ α² / 2

A quadratic. That’s the whole argument. The throttle plate has to swing through a meaningful angle before it uncovers meaningful area, because at small angles you’re only exposing the thin crescent at the edge of a tilted ellipse.

Put numbers on it. Take an 82 mm bore, a closed angle of 9°, an open stop at 83°, and a throttle position axis that runs 0 to 100% of mechanical travel:

(Bore area 5281 mm². Shaft blockage included, see below. Linear column assumes full scale = bore area.)

The error is worst exactly where it hurts most. A big throttle on a big engine cruises at single-digit TPS. That’s the region where a linear table is out by a factor of four.

The shaft

The shaft blocks area too, but not in the way most people assume. Its projected area is roughly shaft diameter × bore diameter, so call it 8 mm × 82 mm ≈ 656 mm², over 12% of the bore.

But at small openings the shaft is hidden behind the plate’s projection. The plate’s projected ellipse is nearly as wide as the bore, and the shaft sits along its centreline. Shaft blockage only becomes real once the plate has swung far enough that its projection narrows past the shaft width, which on typical geometry is somewhere past 60 to 70°.

So the shaft is irrelevant at idle and dominant at wide-open throttle. If you’ve ever wondered why a throttle body flows meaningfully less than its nominal bore area suggests at WOT, that’s most of the answer.

What the closed-form misses

The clean equation above is a thin-plate, sharp-edged idealisation. Real hardware has:

• Plate thickness. A 2 mm plate at 15° presents a real edge to the flow, not a mathematical line.
• A seal taper or step in the bore at the closed position, common on OEM bodies to control leakage and stop the plate binding.
• A relieved or chamfered plate edge, which changes the effective flow path at small angles specifically.
• Screw heads on the plate face where it’s fastened to the shaft.
• Non-concentricity between the plate’s rotation axis and the bore centreline on some designs.

None of these are worth modelling analytically. Integrate the geometry numerically and stop pretending you have a closed form. The code is fifteen lines and it handles the shaft correctly for free.

import numpy as np

def open_area(alpha_deg, alpha0_deg, bore_d, shaft_d, n=2000):
    """
    Geometric open area of a butterfly valve, by numerical integration.

    alpha_deg  : plate angle from the bore-normal plane (deg); ~90 = fully open
    alpha0_deg : plate angle at the closed stop (deg)
    bore_d     : bore diameter (mm)
    shaft_d    : shaft diameter (mm)

    Returns (area_mm2, fraction_of_bore_area)
    """
    R  = bore_d / 2.0
    a  = np.deg2rad(alpha_deg)
    a0 = np.deg2rad(alpha0_deg)

    # projected plate ellipse: semi-axis R along shaft, R*cos(a)/cos(a0) across
    sx = R
    sy = max(R * np.cos(a) / np.cos(a0), 1e-12)

    g = np.linspace(-R, R, n)
    X, Y = np.meshgrid(g, g)

    in_bore  = (X**2 + Y**2) <= R**2
    in_plate = ((X / sx)**2 + (Y / sy)**2) <= 1.0
    in_shaft = np.abs(Y) <= shaft_d / 2.0

    cell = (2 * R / (n - 1))**2
    area = np.count_nonzero(in_bore & ~in_plate & ~in_shaft) * cell
    return area, area / (np.pi * R**2)


def servo_to_angle(tps_pct, alpha0_deg, alpha_max_deg):
    """Linear travel-to-angle map. Verify this on your own hardware."""
    return alpha0_deg + (tps_pct / 100.0) * (alpha_max_deg - alpha0_deg)


for tps in [0, 1, 2, 3, 5, 8, 12, 20, 30, 45, 60, 80, 100]:
    ang = servo_to_angle(tps, 9.0, 83.0)
    a, f = open_area(ang, 9.0, 82.0, 8.0)
    print(f"{tps:5.1f}%  {ang:5.1f}°  {a:8.1f} mm²  {f*100:5.2f}%")

Servo position is not plate angle

The table’s axis is usually servo or throttle position in percent. That is a percentage of mechanical travel, mapped through the sensor calibration. It is not plate angle, and it is not flow area.

Two things break here routinely:

The zero point. TPS 0% is wherever the sensor was zeroed, which is typically the closed stop. But the closed stop is often set slightly below the sealing angle so the plate loads against it, or slightly above so it doesn’t jam. If your assumed α₀ is a degree out, your area predictions at low TPS are out by a large multiple, because you’re on the steepest part of a quadratic.

The full-scale point. Plates rarely reach 90°. Mechanical stops usually land somewhere between 80° and 86°, and the linkage may not be perfectly linear across the range. On a DBW body with a direct gear train it’s close enough to linear to be usable. Verify rather than assume.

Measure both. Command the throttle to a known position, remove the intake pipe, and measure the plate angle directly. A digital angle gauge against the plate face is good to a few tenths of a degree, which is plenty. Do it at 0%, 100%, and three or four points in between to confirm linearity. This is twenty minutes of work that determines whether everything downstream is right or wrong.

The scaling trap

If a table has been carried over from a different throttle body, check what it was scaled by.

Area scales with the square of diameter. Going from 68 mm to 82 mm:

• Diameter ratio: 82 / 68 = 1.206
• Area ratio: 82² / 68² = 1.454

Scale by diameter instead of area and every entry is 17% low. That’s the obvious error.

The subtler one: even a correctly area-scaled table has the wrong shape. Closed angle, open stop angle, and shaft-to-bore ratio all differ between bodies, and none of them scale with diameter. The same shaft in a smaller bore blocks a larger fraction of it. A table lifted from another throttle body and multiplied by a constant is wrong in a way no single multiplier can fix.

Part 2: From area to mass flow

Geometric area isn’t flow area. Two corrections stand between them.

Discharge coefficient

Real flow through an orifice separates at the edge and forms a vena contracta narrower than the geometric opening. The ratio of actual to ideal flow is the discharge coefficient, Cd.

For a butterfly valve, Cd is a function of plate angle, and to a lesser extent of Reynolds number and pressure ratio. Typical values sit somewhere in the 0.6 to 0.8 range across most of the travel, though published data varies considerably with plate profile and bore geometry. The behaviour at very small openings, where the flow is a thin slot jet past a tilted edge, is the least consistent across sources.

If your ECU exposes a separate Cd or flow-correction table against angle, keep the geometric table geometric and put the empirical correction in the Cd table. Two tables, two jobs, and you can reason about each independently. If it only exposes one “effective area” table, you’re folding Cd into it, which works, but means the table is no longer verifiable against geometry, and you lose the ability to sanity-check it with a ruler and a protractor.

The compressible flow equation

Air through a restriction is compressible. The standard isentropic nozzle relation:

ṁ = Cd · A · (P_up / √(R_s · T_up)) · Ψ(PR)

where PR = P_down / P_up, R_s = 287 J/kg·K, and Ψ depends on whether the flow is choked.

Critical pressure ratio for air (γ = 1.4):

PR_crit = (2 / (γ+1))^(γ/(γ-1)) = 0.528

Subsonic (PR > 0.528):

Ψ = √( (2γ/(γ-1)) · ( PR^(2/γ) − PR^((γ+1)/γ) ) )

Choked (PR ≤ 0.528):

Ψ = √γ · (2/(γ+1))^((γ+1)/(2(γ-1))) = 0.6847

Both expressions agree at PR = 0.528, as they must.

The consequence nobody expects: your throttle is choked at idle

Idle manifold pressure on a healthy engine might be 35 kPa absolute, against roughly 101 kPa ambient upstream. That’s a pressure ratio of 0.35, well below critical.

The throttle is sonic. Flow is at the speed of sound in the gap between plate and bore.

That has a specific and useful consequence: when choked, mass flow depends only on Cd, area, upstream pressure and upstream temperature. Manifold pressure has no influence whatsoever. Ψ is pinned at 0.6847 and stays there.

Which means at idle, the model reduces to:

ṁ = Cd · A · P_ambient / √(R_s · T_up) · 0.6847

Every percent of error in your area table becomes a percent of error in calculated air mass, with nothing to absorb it. There is no MAP feedback, no VE term, no second path. Area is the model.

Work out where choking ends: PR = 0.528 against 101 kPa ambient means MAP = 53 kPa. Anything below that is choked, which covers idle, overrun, and most light-load cruise on a large-displacement engine. A big proportion of normal driving sits in the region where the area table is the sole determinant of calculated airflow.

This is the single strongest reason to get the table right, and the reason area errors show up as idle and cruise fuelling problems specifically.

The boosted case, and why pre-throttle pressure matters

Now put the throttle under boost. Upstream is charge pipe pressure, say 200 kPa absolute; downstream is plenum, say 190 kPa. PR = 0.95. Deeply subsonic, and this is where Ψ gets vicious.

Run the numbers:

A 1% change in pressure ratio produces roughly a 9% change in mass flow. The function is nearly vertical up here.

Which brings us to the thing that decides whether a throttle model can work in boost at all: you must know the pressure upstream of the throttle plate.

Without a pre-throttle sensor, the ECU has to infer it, usually from a modelled pressure drop across the intercooler and pipework, or from a boost target, or by assuming it equals MAP plus some offset. All of those are estimates, and the sensitivity above means a 2 kPa estimation error at part throttle in boost produces a double-digit percentage error in calculated air mass.

Fit the sensor. On a naturally aspirated engine you can argue that ambient is close enough. On a boosted engine running a throttle-based air model, a pre-throttle pressure sensor is not an optional refinement. It’s the difference between a model and a guess.

My own car runs both sides: pre-throttle and post-throttle pressure are each measured, not inferred. On a throttle mass flow model those two sensors are not instrumentation, they are part of the model, and the pressure ratio between them is the term the whole calculation hinges on. Full sensing list is on the specification page.

Note also that the sign of the problem inverts across the throttle range. At small openings the pressure ratio is low, the flow is choked or near-choked, and the model is insensitive to downstream pressure but exquisitely sensitive to area. At large openings in boost the pressure ratio approaches unity, area error matters less, and pressure error dominates. Different regions of the same table fail for different reasons.

Part 3: What the ECU does with it

The throttle mass flow model

A throttle mass flow model, TMF in Emtron’s vocabulary, with equivalents under different names across most modern standalone platforms, computes cylinder air mass from the throttle rather than from the manifold.

Broadly:

1. Throttle position → plate angle (via the servo map)
2. Plate angle → geometric area (via the area table)
3. Area × Cd → effective area
4. Effective area + upstream pressure + upstream temperature + pressure ratio → mass flow through the throttle
5. Mass flow → cylinder filling → fuel

Contrast that with speed density, which computes cylinder air mass from manifold pressure, air temperature, engine speed and a volumetric efficiency table. I first wrote about why that distinction mattered in 2023, when choosing an ECU for the R34, long before I understood how much sat underneath it.

The two models fail in opposite ways, which is precisely why good ECUs run both:

Speed density is accurate in steady state because MAP is a direct measurement of what’s actually in the manifold. It’s late in transients, because the manifold takes time to fill and the sensor reports the result rather than the intent. Stab the throttle and the MAP sensor tells you what happened a few tens of milliseconds ago.

Throttle mass flow is immediate, because the plate moves before the manifold responds, so the model sees the demand as it happens. But it’s an inference stacked on a chain of assumptions: area table, Cd, servo map, upstream pressure. Every one of those is a place to be wrong.

So the ECU blends them: TMF-weighted during transients where response matters, SD-weighted in steady state where accuracy matters, with a handover region between.

Diagnosing the handover

The handover is where calibration errors become visible, and it’s diagnostically valuable for exactly that reason. If your two models disagree, the blend region will show a fuelling discontinuity that tracks the blend weighting rather than any physical parameter.

Log fuel trim, or measured lambda error, against whatever variable drives the blend. Three patterns:

A step at the handover. The two models disagree at that operating point. One is wrong; the trim jumps as authority transfers.

A ramp through the handover. The models disagree by a growing margin across the region. Usually indicates a slope error in one of them, either a VE table with the wrong shape, or an area table with the wrong curvature.

Clean through the handover, but offset either side. Both models share a common error downstream of the blend, such as injector characterisation, a global trim, or fuel pressure.

That third case is where things get interesting, because a common error can hide the first two. Which leads to the diagnostic fork.

The fork: when the symptom contradicts the geometry

Here’s a scenario worth walking through, because it’s a trap.

Suppose you determine your area table over-states area by roughly 3× in the idle band, established from geometry, exactly as above. The model is being told there’s three times as much air going past the plate as there really is.

You’d expect the engine to run rich at idle, and the fuel model to read high.

Now suppose your logs show the opposite: TMF reading around 9% low at idle, with a positive fuel correction propping it up.

Both observations can’t be direct consequences of the same cause. Something else is in the chain. Three branches, all testable:

Branch 1: a global trim is masking the shape error. Somewhere there’s a multiplier, a fuel scaling constant, or a Cd table that was adjusted until mid-range worked. That adjustment is fighting the area error, and the residual at idle is what’s left after the fight. Test: remove or neutralise the compensating term and see whether idle error grows in the direction the geometry predicts. If it does, the geometry diagnosis stands and the trim was a bandage.

Branch 2: the Cd table is pulling the other way. If Cd is populated with values that fall sharply at small openings, it may be cancelling much of the geometric over-statement. Test: multiply the area and Cd tables together and plot the product against angle. That product is what the model actually uses. If the product is close to geometrically correct, the individual tables are wrong but the model isn’t, which means fixing the area table alone will break it.

Branch 3: the axis doesn’t mean what you think. The table may be indexed on plate angle rather than percentage travel; or on a normalised area rather than absolute; or the “servo position” channel may be the commanded target rather than the measured position, which differ during any transient and can differ statically if there’s a calibration offset. Test: command a known position, measure the actual plate angle, and confirm which number the table is being indexed on.

Resolve the fork before changing anything. The failure mode here is correcting the area table on sound geometric grounds, discovering the engine now runs badly, and concluding the geometry was wrong. The geometry isn’t wrong. Something else in the chain was compensating for it, and you’ve now removed one half of a matched pair.

Which is the general rule: compensating errors must be corrected together or not at all. If a wrong area table and a wrong global trim have been co-calibrated to produce acceptable fuelling, fixing either one alone makes the car worse. Identify both, correct both, revalidate.

Part 4: The dual-use trap

On a drive-by-wire car, the throttle area table is usually consumed in two directions.

Forward, for the air model: position → area → mass flow → fuel.

Inverse, for torque-based control: torque demand → required mass flow → required area → target throttle position.

The same table. Read backwards.

That inverse map is not an edge case. It is what every torque-based system on the car leans on. When traction control decides to pull torque and reaches for throttle area as its first actuator, this table is what turns a torque request into a plate position. An area table that is wrong at small openings makes every one of those interventions wrong too.

Three consequences.

Fixing the fuel model changes the pedal

If the table over-states area at small openings, the inverse map under-commands position for a given torque request, because the controller thinks a tiny opening delivers a lot of air, so it asks for a tiny opening. Correct the table and the same pedal input now produces a larger commanded opening.

Which is correct, but it isn’t the same. Tip-in response, idle control authority, cruise position and any part-throttle torque limiter behaviour all shift. Expect to revalidate driveability alongside fuelling, and don’t do it on a road.

Non-monotonicity breaks the inverse map

A table with hand-entered noise, where area at 5% exceeds area at 6%, is merely inaccurate in the forward direction. It’s ill-posed in the inverse direction.

Inverting a non-monotonic function means that for some torque demands, more than one throttle position satisfies the request. Depending on how the solver is implemented, you get target jumps, hunting, or an oscillation whose frequency is set by the controller rather than by anything physical.

Where does hand-entry noise usually live? In the low-percentage cells, because that’s where people have been poking at values trying to fix an idle problem. Which is exactly where idle control and tip-in operate.

Check monotonicity explicitly. It takes one line:

assert np.all(np.diff(area_table) > 0), "Area table is non-monotonic"

If that fails, no amount of downstream tuning will produce stable control.

The table is not a tuning parameter

The strongest reason to build the area table from geometry rather than from fitting: it’s the only table in the chain that has a verifiable, physical, single correct answer.

VE is empirical. Cd is empirical. Injector characterisation is empirical. Geometric flow area is a solid modelling problem with one right answer, computable from four measurements, and it does not change as the engine ages.

Once it’s correct, it’s correct permanently, and every empirical table downstream is being fitted against a fixed truth rather than against another set of assumptions. That’s what makes the rest of the calibration converge instead of chasing itself.

Treating the area table as somewhere to dial in a fuelling problem throws away the one fixed reference point in the entire model.

Part 5: Method

1. Measure the hardware. Bore diameter, shaft diameter, plate thickness. Callipers.
2. Measure the closed angle. Digital angle gauge against the plate face at the closed stop. This number matters more than any other single measurement, because it sets where you sit on the quadratic.
3. Measure the open stop. Same method, throttle commanded to 100%.
4. Verify the servo map. Command 20%, 40%, 60%, 80%; measure the angle at each. Confirm the travel-to-angle relationship is linear before assuming it.
5. Compute the geometric table numerically. Use the code above, at the resolution your ECU’s table supports. Populate the low-percentage region densely, because that’s where the curvature is, and where linear interpolation between widely-spaced breakpoints does the most damage.
6. Check monotonicity. Every cell strictly greater than the one before.
7. Handle Cd deliberately. Separate table if the ECU allows it. If not, decide consciously what Cd assumption you’re folding in and write it down.
8. Identify existing compensating terms before you change anything. Global fuel multipliers, mass fuel corrections, Cd tables, anything that’s been trimmed to make the current calibration work. These come out or get re-derived in the same change.
9. Validate against logs. With the corrected table, TMF and SD should converge in steady state without a compensating pad. That convergence is your proof, not the smoothness of the fuel trim, which can be smooth for the wrong reasons.
10. Revalidate driveability, because you have just changed the inverse map that determines where the plate goes.

Summary

A butterfly valve’s open area grows with the square of plate angle near closed, not linearly. In the idle-to-light-cruise band, a linear table over-states area by two to four times.

Below roughly 53 kPa manifold pressure, the throttle is choked and manifold pressure has no effect on flow at all. Area and upstream pressure are the entire model. Above that, in boost, the flow function is so steep that a 1% pressure ratio error produces a 9% mass flow error, which is why pressure sensors either side of the plate are mandatory rather than optional on a boosted throttle-model car.

The area table is the only table in the air model with a single verifiable correct answer. Build it from geometry, keep the empirical corrections in the tables designed for them, and check it’s monotonic before wondering why the drive-by-wire target is hunting.

And if fixing it makes the engine worse, you’ve found a compensating error, not a mistake in the maths.

This is the first of a series on the Emtron KV12 running a 3.4 litre 2JZ. The torque model that sits on top of this table drives the traction control strategy, and it is also what caps engine torque at the measured limit of the gearbox. Full specification and measurement conditions are on the Supra project page.

If you have built one of these tables from geometry and found the Cd behaviour at very small openings differs from the published ranges, I would like to hear about it. That is the part of this I trust least.

The post Throttle Body Effective Flow Area: Building a Correct Area vs Position Table first appeared on BlownByTwins.

The post Throttle Body Effective Flow Area: Building a Correct Area vs Position Table appeared first on BlownByTwins.