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 the follow up. How the Emtron KV12 actually stages twelve injectors, every table that controls it, and one thing I had described wrongly.

Each section is marked. Verified means it comes straight from the calibration or the logs. Theory means it is my reasoning or arithmetic, not something I have measured.

Configuration

Status: Verified

• 2JZ-GTE VVTi, 3,353 cc, flex fuel
• Plazmaman intake manifold, twin fuel rails mounted on the runners
• Twelve CP1000 injectors, rated 1,000 cc/min at 3 bar, high impedance
• 1:1 rising rate regulator, fuel pressure sensor fitted
• Three Walbro 485 pumps
• Emtron KV12, every injector on its own channel

How Emtron does it

Status: Verified

Staging is an injection mode, not an add on. The KV12 offers seven:

• 0: Off
• 1: Sequential
• 2: Sequential/Staged Sequential (this car)
• 3: Sequential/Staged Group
• 4: Non Sequential
• 5: GDI Sequential
• 6: GDI Sequential/Staged, primary GDI and secondary port

Mode 2 fires the secondaries sequentially as well, each one timed to its own cylinder. Mode 3 groups them, which is what you would use on an ECU without enough channels. With twelve dedicated outputs there is no reason to group anything.

Once staging is enabled, the secondaries get their own setup page, and it mirrors the primary one line for line:

Fuel pressure correction being on with a sensor fitted matters more than it looks. The ECU is not trusting the regulator to hold 400 kPa across the injector. It measures the differential and corrects flow for it. A 1:1 regulator gets you close, but close is not the same as measured.

The channel map

Channels 7 to 12 do not run 1 to 6. That is fine, as long as the map matches the wiring. Get one wrong and a secondary fires on the wrong cylinder’s timing. You will not see that on a single wideband, because the total fuel is still right. The only proper check is firing each channel individually.

Characterising the injector

Status: Verified

The injectors are CP1000s, rated 1,000 cc/min at 3 bar. Scaled to the 400 kPa this car runs across the injector, that is about 1,155 cc/min each, roughly 13,860 cc/min across all twelve, the equivalent of six 2,310 cc injectors.

The calibration doesn’t use 1,155. Its reference size is 1,190 cc/min at 400 kPa, taken from CP Fuel and Race data rather than scaled from the headline rating. The square root rule is a good approximation, not a measurement. Where the manufacturer has measured the injector at your pressure, use their number.

The dead time table is identical for both banks, which is correct for identical injectors:

Dead time rises with pressure and falls with voltage. The solenoid has to pull the pintle open against the fuel pressure, and a higher supply voltage builds current in the coil faster. On a running car at 14 V and 400 kPa, the first 1.057 ms of every pulse is dead time: the injector is energised but not yet delivering its rated flow.

Both banks run saturated drive, which is right for a high impedance injector. Peak and hold is for low impedance injectors that need a current limit.

Flex fuel is handled underneath

The fuel model works in mass, so the ECU needs to know two things about whatever is in the tank: how much air it needs to burn completely, and how dense it is.

The table is a straight line between petrol and ethanol, by volume. Strictly, stoichiometry blends by mass, not volume, so I checked it. At E85, weighting by mass gives 9.81. The table interpolates to 9.86. Half a percent, well inside what the closed loop trims absorb. Not worth correcting.

One small oddity: the step from 80 to 90 °C is steeper than every other step in the table, and the 90 °C column is rounded to two decimal places. It doesn’t matter here, because the fuel in this rail never gets near 90 °C. If yours does, that column is worth a second look.

The balance table: a blend, not a switch

Status: Verified

This is the table that decides who does the work. The value is the secondary bank’s share of total fuel. Zero means primaries only. Fifty means an even split.

Read the top row. At 1,500 rpm in vacuum, the secondaries supply 15 percent. By 2,000 it is 20. The share climbs 5 points every 500 rpm until it reaches an even split at 5,000.

Add boost and the ramp gets steeper. At 140 kPa the secondaries are already at 38.5 percent by 1,500 rpm, and from 160 kPa upwards it is an even split everywhere above 1,000.

Which means I described this wrongly. In Twelve Small Injectors I wrote that at idle, around town, and at any low load, only the primaries fire. The table says otherwise. Around town at 2,000 rpm, a fifth of the fuel is coming from the secondaries. Only idle runs on primaries alone.

This isn’t staging in the on/off sense. It’s a blend with a floor.

Where the switch actually is

Two settings decide when the secondaries are allowed to fire at all.

The staging rpm lockout holds them off below 1,000 rpm, whatever the table says. Above that, staging comes on when the interpolated balance value rises above 5.0 and goes off when it falls below 5.0.

The table goes from 0 at 1,000 rpm to 15 at 1,500. Interpolating between them, it crosses 5 at about 1,170 rpm, at every MAP up to 100 kPa. That is the real staging point for normal driving.

And because ON and OFF are both 5.0, there is no hysteresis. The same threshold switches the bank in and out. Sitting at 1,170 rpm, the secondaries could in principle toggle on every fluctuation of engine speed.

What keeps idle clean is the idle target. I moved it to 950 rpm, under the lockout, so at idle the secondaries are never asked to fire.

What the secondaries are being asked to do

Status: Verified

The whole reason for twelve injectors is to keep pulse widths out of the region where an injector stops being predictable. So it’s worth asking what pulse width the secondaries actually see at light load.

I haven’t measured this directly. This is arithmetic from the fuel model, assuming 80 percent volumetric efficiency, 30 °C charge and lambda 1:

At 1,500 rpm in light cruise, the secondaries sit right on the 0.200 ms minimum on E85 and below it on petrol. At the moment staging switches on, with the balance at 5 percent, they are being asked for something like a third of the minimum.

That is exactly the region Twelve Small Injectors says staging exists to avoid. The primaries are comfortable. The secondaries are not.

The calibration has no short pulse correction either. For very short pulses, the ECU is converting fuel mass to time using dead time and a straight line slope, and a straight line is exactly what an injector stops being down there.

What the KV12 does with a request below its own minimum, whether it clamps up to 0.200 ms or drops the pulse, I don’t know. Either way, the secondary delivery in that window is not what the model thinks it is.

What the logs say

Status: Verified

Lambda control is good through the staging region. On the road the handover is transparent. I can’t feel it, and the wideband doesn’t show a step.

Which looks like it contradicts the section above. I don’t think it does. Maybe we can refine this in the future.

Why it holds up anyway

Status: Theory

Two reasons, and I suspect both apply.

First, the error is a percentage of a small number. If a secondary at 15 percent share delivers 20 percent more or less than asked, the cylinder sees a 3 percent error in total fuel. That is inside what closed loop trims correct without anyone noticing.

Second, the closed loop may be doing exactly that. Good lambda control in a region where the open loop model is weakest doesn’t prove the model is right. It may only prove the trims are working. The way to tell the difference is to log the trims, not lambda, through the 1,170 to 2,500 rpm band. Emtron logs the effective and actual pulse width of both banks separately, so the secondary pulse widths can be checked against the estimates above.

Where the injectors are, and why it barely shows

Status: Theory

Both rails sit on the runners, one row close to the head and the other further out along the runner. So the two banks do not take quite the same path to the valve. Fuel from the outer row travels further, wets more runner wall, and arrives slightly later. Calibrating a handover between two injector positions means accounting for two transport paths.

On this manifold the gap between the two rows is short, far shorter than on layouts that put the secondaries up in the plenum or the intake tract. I’d expect the difference in transport and wall wetting to be small. It also matters least where the secondaries carry the smallest share of the fuel, which is exactly the light load region above. That is probably part of why the handover is transparent, but I haven’t measured it.

What I’d change

Status: Working conclusion

Nothing is broken, so none of this is urgent. But the calibration is relying on the trims in a region where it doesn’t need to.

• Bring the secondaries in later and bigger. Six 1,000 cc primaries have far more than enough capacity to carry light cruise on their own. Holding the secondaries at zero through light load, and bringing them in where their share gives a pulse width comfortably clear of the minimum, means they never operate in the bottom of their range.
• Split ON and OFF. Identical thresholds mean no hysteresis. A gap between them stops the bank chattering at the switch point.
• Mind the margin at idle. 950 rpm against a 1,000 rpm lockout is 50 rpm of margin. Anything that lifts the idle above 1,000, such as a higher cold idle target, an idle flare or load compensation, brings the secondaries in at the smallest pulse widths in the table.
• Add short pulse data if the ECU will take it. It is the one piece of the injector model the calibration doesn’t have, and it matters most in exactly the light load region above.

The principle

Staging solves a pulse width problem. The balance table can quietly give it straight back by handing the secondaries a sliver of fuel at light load.

So when you set one up, don’t only check that lambda is clean through the transition. Work out the secondary pulse width at the first non zero cell in the table, and check it against the injector’s minimum. If it is below, the ECU is guessing and the closed loop is covering for it.

Every number here is specific to this car, these injectors and this manifold. The data is not transferable, but the principle is.

Why the car has twelve injectors in the first place, and the flow arithmetic behind them, is in Twelve Small Injectors Instead of Six Big Ones. What the fuel system makes possible on E85 is in What E85 Actually Buys. Full specification is on the Supra project page.

If you run a staged setup on an Emtron and know what the KV12 does with a request below the minimum effective pulse width, I’d like to hear it.

The post Staged Injection on the Emtron KV12: A Blend, Not a Switch first appeared on BlownByTwins.

The post Staged Injection on the Emtron KV12: A Blend, Not a Switch 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.

Then I logged it properly. The logs showed that the tyre produced its best acceleration at less slip than some of my more permissive modes allowed, the speed offsets could drive the final target below zero, and the integral term was storing positive torque while the car was below target. When wheelspin arrived, part of the PID was briefly helping it.

This is the latest iteration: what changed, what the evidence actually supports, and what still needs a warm, dry road before I call it finished.

The starting point

Status: Verified – Rear tyres are 295/30/19 Continental SportContact 7s.

The strategy has always had two halves. Feedforward predicts the engine torque the tyre should accept. Closed loop PID then corrects whatever the prediction could not know about: temperature, damp patches, surface changes, load transfer and bumps.

The torque model is normalised to third gear. The traction strategy itself is not normalised until the final gear scaler is applied. That distinction matters because a torque value in the base table is not the engine torque the car will necessarily receive in second, fourth or fifth.

The tyre peak moved the targets

Status: Working conclusion

The useful result from the earlier dry data was a tractive force peak around 9,500 to 9,800 N at roughly 5 to 6 percent slip. Once slip moved into the 6 to 8 percent band, median tractive force fell to about 8,860 N. More wheelspin felt more dramatic, but it accelerated the car less.

That immediately made two settings look wrong. Mode 7 allowed 7.9 percent straight line slip and Mode 9 allowed 12 percent. Both sat beyond the measured force peak. They were permissive, but they were not the fastest settings.

The later road test complicated the picture. It was cooler and the road was not completely dry. Maximum logged tractive force was about 7,982 N rather than 9,500 N. The road rose by only about 0.17 percent over the measured section, worth roughly 30 N on a 1,750 kg car, so gradient could not explain the difference. Tyre and road condition could.

That means 9,500 N remains a dry baseline, not a universal grip limit. The system still needs slip feedback because no fixed torque table can know whether the tyre is warm, cold, dry or sitting on a damp seam.

Rebuilding the rotary modes

Status Calibration loaded for validation

The rotary still selects the character of the car, but the straight line targets now have a cleaner progression. Mode 3 remains the chilled setting. Mode 4 is the normal fast road setting. Mode 5 is for a known dry road on warm tyres. Mode 6 allows movement, but no longer asks the SC7 to live well beyond its measured force peak.

The lateral G shapes were rebuilt at the same time. Both sides are now symmetrical because there was no evidence supporting different left and right targets. Every active road mode tapers as lateral acceleration increases, because the tyre has less longitudinal capacity available while it is also producing cornering force.

The speed offset was doing too much

Status: Calibration loaded for validation

The final target is the lateral G table plus a speed offset. The old high speed offsets were large enough to make the combined target negative in the conservative modes. Unless that is correcting a measured wheel speed bias, a negative slip target has no useful meaning.

The revised table keeps the low speed launch allowance, but reduces the 25 km/h addition from nine percentage points to five. The target now blends down towards the normal table by 45 km/h instead of falling off a cliff. Above 180 km/h the negative offsets remain, but they are smaller and cannot erase the underlying target.

That gives the same rotary a consistent meaning at every speed. Mode 3 remains conservative rather than becoming impossible at high speed, and Mode 7 remains the quickest dry road target rather than turning into an arbitrary number once the car passes 180 km/h.

A feedforward table built around tractive force

Status Current baseline

The largest architectural change is the main feedforward surface. Instead of treating slip error as the only description of available grip, the new table is indexed by modelled tractive force and engine torque before reductions.

The surface rises towards 9,500 N, then deliberately falls away. At a 950 Nm unrestricted torque input, the table returns 594.9 Nm at 8,000 N, 652.7 Nm at 9,500 N and 597.1 Nm at 10,500 N.

Apply the fourth gear normalisation factor of 1.263 and those become approximately 751, 825 and 754 Nm at the engine. The peak is therefore almost exactly where the warm, dry SC7 data said it should be. Above the peak, the table asks for less torque because the tyre has already moved onto the wrong side of its force curve.

This is still a model. Emtron tractive force is largely derived from engine torque and gearing; it is not a strain gauge measuring the contact patch. The table provides a gear aware first estimate. Slip feedback remains the part that discovers the road is wet.

The integrator was adding torque

Status: Verified defect

The most important log finding was not a lack of negative integral authority. It was positive windup.

With slip below target, the original controller allowed the integral output to climb to its positive 50 Nm clamp. One run held it there for about 1.3 seconds. Another retained the full 50 Nm across approximately 2.75 seconds. The tyre was not slipping too much, so the controller stored permission to add torque.

When overslip arrived, the proportional and derivative terms reacted immediately, but the integral term had to unwind before it could help. At the worst point in one event the contributions were minus 7.6 Nm proportional, plus 37.6 Nm integral and minus 0.9 Nm derivative. The combined PID contribution was still plus 29.1 Nm while the tyre was already beyond target.

The controller remained stable because the feedforward model, throttle reduction and ignition retard were doing the real work. That does not make the integral behaviour acceptable. A stable result can still contain two control terms fighting each other.

The fix was removing positive authority

Status: Changed awaiting full dry validation

The positive integral clamp is now zero. The negative clamp remains minus 50 Nm.

Below target slip, the integral term now sits at zero. Once the tyre exceeds target it can accumulate negative correction, up to 50 Nm. There is no positive value left to unwind and no stored torque waiting to oppose the first intervention.

I initially considered extending the negative clamp to minus 75 Nm. The logs killed that idea. In the later full throttle events the negative integrator reached only minus 4.3 Nm in one run and zero in the other. More negative authority would have solved a problem that was not happening while increasing the risk of a torque hole after the tyre recovered.

The proportional, integral gain and derivative tables therefore stay unchanged for the next test. Changing several control terms at once would make the result impossible to attribute. The positive clamp was the proven defect, so that is the change being isolated.

What the road logs now say

Status Verified for the logged conditions

Both runs used the conservative Mode 3 target. Neither needed ignition or fuel cuts. The car controlled the tyre with modest timing reduction and without the controller cycling torque up and down.

The lower 7,982 N tractive force result from the cooler, imperfectly dry run should not be used to rewrite the dry table. It is evidence that the available grip changed. That is exactly why the feedforward and feedback halves both exist.

The same session produced a roughly 4.8 second 100 to 200 km/h run without full boost at 100 km/h. The performance matters, but the cleaner result is the behaviour: a 914 whp pump fuel car remained controlled on a cool road without cuts or abrupt throttle closure.

Power mode and traction mode are separate decisions

Status: Verified

The torque request rotary decides how much engine performance is available. The traction rotary decides how much of that performance the tyre may use. Treating them as one setting hides useful control.

The high torque modes already allow enough demand to exceed the rear tyre in second and third, while effectively releasing full engine output from fourth upwards. Increasing those torque tables would not make the car faster. It would only give the traction strategy a larger error to remove.

For a dry road the useful combination is a high torque request with Mode 5 or Mode 6 traction control. Mode 3 is deliberately conservative. Mode 7 is now a permissive track setting rather than a 12 percent wheelspin setting dressed up as performance.

The current configuration (Emtron specific)

What still needs proving

The next valid test is on the same dry road, in both directions, with warm tyres. Running in both directions removes most of the gradient and steady wind error. Mode 4 should be tested first, followed by Mode 5, with full pedal held through the shift long enough to see the integrator unwind and torque recover.

The stop condition is simple. If slip rises beyond about 6.5 percent and tractive force does not increase, the tyre has crossed the peak. If force continues to rise at 5.5 percent slip, Mode 6 is doing its job. If the controller oscillates or leaves a torque hole after intervention, the PID still needs work.

Until that test is complete, the new force peak and the revised permissive modes remain evidence based working settings rather than finished calibration.

The lesson from this iteration

The first version was designed to prevent wheelspin. This version is being calibrated to maximise acceleration without making the car unpleasant.

That distinction changed the questions. How much slip is allowed is less useful than where the tyre produces maximum force. A larger integral clamp is less useful than checking whether the integrator is acting in the correct direction. More available engine torque is irrelevant when the tyre is already the limit.

The car already had enough power. The latest changes are about making the control system stop wasting it, whether that waste comes from excessive wheelspin, an over-conservative target or two parts of the PID fighting each other.

That is the point of logging it properly. The calibration stops being a table that looks sensible and becomes a system that can explain what the car actually did.

Huge thanks to Adrian at Emtron Australia for the pointers in this. It’s been invaluable.

The post What the Logs Changed in My Supra Traction Control first appeared on BlownByTwins.

The post What the Logs Changed in My Supra Traction Control 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.

The usual answer is to accept it. Fit the 2000cc units, put up with a lumpy idle and a car that hunts in traffic, and tell yourself it’s the price of the power.

It isn’t. Here’s what I did instead, and the arithmetic behind it.

Configuration

Status: Verified

• 2JZ-GTE VVTi, 3,353 cc, 1,114 whp on E85
• Plazmaman intake manifold, twelve injector provision
• Twelve CP1000 injectors, rated 1,000 cc at 3 bar
• Aeromotive regulator, 4 bar static, 1:1 rising rate
• Three Walbro 485 pumps, -10 feed lines
• Emtron KV12, twelve dedicated injection channels, flex fuel

The problem is minimum pulse width, not flow

An injector is a solenoid valve. It takes a finite time to open and a finite time to close, and during those transitions the flow through it is neither zero nor fully open. It is somewhere in between, and it is not linear.

Above a certain pulse width, the opening and closing transitions are a small fraction of the total and the injector behaves predictably. Below it, the transitions dominate. Two commands a fraction of a millisecond apart can deliver very different amounts of fuel, and the relationship stops being something you can characterise reliably.

That’s the minimum controllable pulse width, and it’s roughly a property of the injector rather than of how much fuel you’re asking for. A big injector doesn’t take proportionally longer to open. It just moves more fuel while it does.

Which is why big injectors idle badly. At idle you need a very small mass of fuel. With a big injector, that mass corresponds to a pulse width down in the region where the injector is unpredictable. The ECU asks for the same thing twice and gets two different answers. That’s your lumpy idle, and no amount of tuning fixes it, because the hardware isn’t repeatable down there.

Twelve small ones instead of six big ones

The Plazmaman manifold takes twelve injectors, two per cylinder. Six primaries and six secondaries, each addressed individually on its own channel by the KV12.

At idle, around town, and at any low load, only the primaries fire. Six injectors, each a 1000cc unit, sharing the same small fuel demand a set of six would normally handle. Pulse widths sit in the region where a 1000cc injector is well behaved.

When load arrives, the secondaries stage in and the full twelve are working.

So you get the idle characteristics of a 1000cc injector and the flow of something more than twice the size. That’s the whole idea, and it costs you nothing except a manifold that takes twelve injectors and an ECU with twelve output channels.

The arithmetic, including the bit people get wrong

The injectors are rated 1,000 cc. They are not flowing 1,000 cc.

Injector flow scales with the square root of the pressure differential across it. Rated at 3 bar, run at 4 bar:

flow = rated_flow × √(actual_pressure / rated_pressure)
     = 1000 × √(4 / 3)
     = 1000 × 1.1547
     = 1,155 cc

Twelve of those is roughly 13,900 cc/min installed, which is the equivalent of six 2,300 cc injectors.

That square root matters more than it looks. It cuts both ways: raising fuel pressure buys you less flow than you’d expect, and dropping it costs you less than you’d fear. A 33 percent pressure increase gave 15 percent more flow.

It also means anyone sizing injectors off the rated figure without checking their base pressure is working from the wrong number.

Why the regulator has to be rising rate

What actually drives flow is the pressure differential across the injector: rail pressure minus manifold pressure.

With a fixed 4 bar rail and 2.8 bar of boost in the manifold, that differential collapses to 1.2 bar at peak. Flow would fall to roughly 55 percent of what the ECU thinks it’s getting, at exactly the moment the engine needs the most fuel.

A 1:1 rising rate regulator references manifold pressure and raises rail pressure to match, so the differential stays at 4 bar whatever the boost is doing. At 2.8 bar of boost that means roughly 6.8 bar of absolute rail pressure.

Which is what the three pumps are for. Walbro 485s at 6.8 bar are working considerably harder than the same pumps at 3 bar, and their flow falls off as pressure rises. Fuel pressure has been confirmed to hold through full load E85 pulls, and the third pump exists for exactly that margin.

A headroom check

Status: Working conclusion

Rough demand at 1,114 whp on E85, assuming a brake specific fuel consumption around 0.66 lb/hp/hr and a nominal drivetrain loss, lands somewhere near 8,400 cc/min.

Against 13,900 cc/min installed, that’s roughly 60 percent duty at peak power.

Both of those assumptions are mine rather than measured, so treat it as a sanity check rather than a specification. But the shape of the answer is right: there is real headroom, which is what you want on a car that has to survive being driven rather than just surviving a dyno pull.

What this costs

It isn’t free.

Twelve injectors means twelve to buy, twelve to wire, and twelve output channels on the ECU. Not every standalone has them, and a manifold with secondary injector provision is a specific purchase rather than a generic one.

There is also a calibration cost. The handover between primary only and both sets firing has to be blended properly, or you get a step in fuelling at the transition. That is real work and it is work a single stage setup doesn’t need.

Whether it’s worth it depends entirely on what the car is for. If it lives on a dyno and does quarter miles, fit six big ones and don’t think about it. If it has to sit in traffic on the way to Scotland and then do something violent when it gets there, the staging is the difference between a car you drive and a car you tolerate.

This fuel system is what makes 2.8 bar on E85 possible in the first place. What that boost is actually worth, and how much of it is the fuel rather than the pressure, is covered in What E85 Actually Buys. Full specification is on the Supra project page, and the build itself is in The 3.4 Stroker Build.

If you’ve run a staged setup and measured where the handover actually lands in your fuel trims, I’d be interested. That transition is the part I know least about and it’s where I’d expect the problems to live.

The post Twelve Small Injectors Instead of Six Big Ones first appeared on BlownByTwins.

The post Twelve Small Injectors Instead of Six Big Ones 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.

On my car the honest answer turned out to be more interesting than either, and it took two ignition tables and a dyno sheet to see it. The short version: E85 buys boost and it buys ignition timing, and depending on where you look in the rev range you can measure both, one, or neither.

Configuration

Status: Verified

• 2JZ-GTE VVTi, 3,353 cc, 9.5:1 static compression
• Kelford T202-D camshafts, 272°/278° advertised
• Pulsar G42-1200, 73 mm compressor, T4 divided 1.15 A/R
• Emtron KV12, firmware 2.20.22, flex fuel with an ethanol content sensor
• Twelve CP1000 injectors, staged, on a 4 bar 1:1 rising rate regulator. That fuel system is what makes 2.8 bar possible at all, and it is covered separately in Twelve Small Injectors Instead of Six Big Ones
• ZF 8HP70, 5th gear, 1.285:1
• Dynojet, WinPEP 8, uncorrected, 6 March 2026 at SRD Tuning
• Both runs: same session, same equipment, no atmospheric correction applied to either

The two runs

200 whp apart. The obvious reading is that E85 is worth 200 whp. It isn’t, and the two runs weren’t at the same boost, so any straight comparison between them is measuring two things at once.

What the ignition tables say

Two main ignition tables, same axes, one for each fuel. Comparing them cell by cell gives a much cleaner answer than the dyno does.

Below 100 kPa, the two tables are identical. Not similar. The same numbers in every cell.

That is deliberate. Off boost the car runs the same timing regardless of what is in the tank, so it idles the same, pulls away the same and behaves the same in traffic on either fuel. A car that drives differently depending on what you last filled it with is a car you have to think about, and this build is meant to be one you don’t.

Above 100 kPa they separate, and they separate by a remarkably consistent amount:

Four to five degrees, right across the boosted region, holding all the way to the limiter. That is what E85 actually bought in this calibration, and it is a separate thing from the extra boost.

Separating the two effects

To a first approximation, mass flow through an engine scales with manifold pressure. So if you know the pressure ratio between two runs, you know roughly how much of the power difference is just boost.

381 kPa against 311 kPa is a pressure ratio of 1.225. Anything above that is coming from somewhere other than pressure.

At peak torque, 881.0 against 688.6 lb ft is a ratio of 1.279. That is roughly four percent more than pressure alone explains. That four percent is the timing.

At peak power, 1,113.9 against 914.2 whp is a ratio of 1.219. Slightly below the pressure ratio. The timing advantage is still sitting in the table, four to five degrees of it, but it has stopped turning into power.

Why the advantage disappears at the top

Status: Working conclusion

The working explanation is the turbo. At 2.8 bar the G42-1200 is at or near the limit of what it can flow, so the E85 run stops gaining before the engine does. The pump run at 2.1 bar still has compressor headroom, which is why it makes its peak power 720 rpm further up the rev range, at 7,940 against 7,220.

That looks backwards until you think about it. The lower boost run revs out further because it hasn’t run out of compressor yet.

I can’t prove it. Turbo shaft speed isn’t logged on this car and there is no exhaust manifold pressure sensor, so I can distinguish neither the compressor side nor the turbine side from the data I have. It is a working conclusion, and it stays one until there is a sensor behind it.

What this means if you’re deciding on flex fuel

The useful conclusion isn’t the 200 whp. It’s where the 200 whp comes from and where it doesn’t.

If you are already boost limited by your turbo, E85’s timing advantage will show up as mid range torque and very little else at the top. You will feel it on the road far more than you will see it on a dyno sheet, because the road is where mid range lives.

If you have compressor headroom left, E85 lets you use it, and then you get both.

And if somebody quotes you a fuel-to-fuel power comparison without telling you the boost on each run, the number means nothing. Two runs at different pressures measure two variables. You cannot attribute the difference to the fuel unless you hold the pressure constant, or do what I have done here and work out how much of it pressure alone would explain.

The experiment I haven’t run

The clean version of this test is both fuels at the same boost. Set 2.1 bar, run pump, run E85, and the entire difference is the timing with nothing else in the way.

That’s a dyno session I haven’t had, and until I do, the four percent figure above is arithmetic rather than a direct measurement. When it happens it goes on this page and if the number is different I will say so.

The 881 lb ft in the table above is not the highest figure from that session. A fourth run reached 901 lb ft and found the limit of the gearbox instead: Where the Stock ZF 8HP70 Gives Up. Engine torque has been capped at 880 lb ft ever since, which is why the E85 figure is where it is.

Full specification, both dyno sheets and the measurement conditions are on the Supra project page.

If you have run the same engine on both fuels at matched boost and have the numbers, I would like to see them. Same boost, same dyno, same session. It is a surprisingly rare test.

The post What E85 Actually Buys: Boost, Timing, and Where the Advantage Vanishes first appeared on BlownByTwins.

The post What E85 Actually Buys: Boost, Timing, and Where the Advantage Vanishes appeared first on BlownByTwins.

The answers you find are all secondhand. Someone knows someone whose car makes 900 and it’s fine. Someone else grenaded one at 700. Nobody publishes a number with a trace behind it.

Here’s one. On 6 March 2026 my 8HP70 let go at 901 lb ft, on a dyno, in front of witnesses, with the run on file.

Configuration

Status: Verified

• ZF 8HP70, stock internals, stock torque converter
• CANformance CAN TCU, release v1.1 beta 13
• Emtron KV12 engine management, firmware 2.20.22
• 3.4 litre 2JZ-GTE VVTi, Pulsar G42-1200, OS Giken LSD, 2.93 final drive
• Tyres: Continental SportContact 7, 295/30/19 rear
• Fuel: E85 at 2.8 bar gauge
• Dyno: Dynojet, WinPEP 8, uncorrected, at SRD Tuning
• Gear: 5th, 1.285:1
• Transmission oil temperature: approximately 95°C

Why 5th and not 6th

6th on an 8HP70 is direct drive, 1:1, and would have been the cleaner gear to measure in. It wasn’t available.

With a 2.93 final drive and a 659.6 mm rolling diameter on the 295/30/19, 8,200 rpm in 6th is roughly 216 mph at the roller. That is past the speed ceiling of the dyno. The same rpm in 5th is about 168 mph, which is comfortably inside it.

So the run happened in a reduction gear. The box was not passing engine torque straight through; it was multiplying it by 1.285 on the way to the output shaft. Worth stating plainly, because it changes how the number generalises.

What it looked like

Revs rose. Torque dropped. Run aborted.

That’s the whole signature, and it’s worth sitting with because it is not subtle and it is not ambiguous. Engine speed climbing while measured torque falls means the input side is turning faster than the output side. Something between them is not holding. On a dyno in a fixed gear there is only one candidate.

SRD called it as clutch slip from the cell. No fault code, no warning, no drama. The trace simply diverges and the run stops being a measurement of the engine.

It is on the sheet as the blue line: 1,095.89 whp at 6,710 rpm, 901.33 lb ft at 5,700 rpm, and then a trace that stops climbing and ends early. Every other run on that sheet carries on to 8,200 rpm.

Why the temperature matters

Wet clutch capacity falls as fluid heats. Publish a slip figure from a box at 130°C after ten back to back pulls and you have measured heat soak, not capacity.

This was at roughly 95°C, comfortably inside the fluid’s operating range and nowhere near tMax. Normal hot running, not a cooked gearbox. That is what makes the number worth quoting.

The qualification nobody makes

Status: Working conclusion

Clutch capacity is clamp load. Clamp load is line pressure. Line pressure is commanded by the transmission controller.

So what I measured is not “the 8HP70 holds 901 lb ft”. It is “this 8HP70 held 901 lb ft of engine torque in 5th, at the line pressure this controller commanded, at this temperature.” Change the controller and the number can move.

That distinction is not academic. It is the reason a straight answer to “what will an 8HP hold” doesn’t exist, and it is why the forum numbers scatter so widely. Different controllers, different pressure strategies, different gears, different results, all reported as though the gearbox were the only variable.

Where the limit applies

Because the measurement came from a reduction gear, it does not transfer evenly across the box.

Below 5th the ratios multiply harder: 1.67, 2.11, 3.14, 4.71. For the same engine torque the internals see progressively more, so 1st through 4th are the exposed end. The torque model reduces demand there, which means those gears never see the full number. That is handled in calibration rather than hoped for.

Above 5th the ratios go the other way: 1.00, 0.84, 0.67. Less multiplication, and in the top two an overdrive. On paper the model would allow more engine torque in 6th, 7th and 8th than it does in 5th, and I have chosen not to take it.

880 lb ft is a global cap, not a per gear one. The only gear I have a measured failure point for is the one I broke it in, and I am not interested in discovering whether 890 slips in top at motorway speed.

A per gear torque map is the correct answer eventually. It needs a measured limit for each gear, and getting those means deliberately slipping the clutches seven more times. Until then, one number everywhere, set by the one gear I have evidence for.

What we settled on

Torque limited to 880 lb ft. The E85 run on the same sheet peaks at 880.98 lb ft and pulls cleanly to 8,200 rpm at 1,113.9 whp.

So the headline number on the car is not what the engine can make. It is what the gearbox will accept. The 3.4 stroker is torque limited by the transmission, not by the engine, the turbo or the fuel.

A 20 lb ft margin below a known failure point, on a road car that covers long distances, is a sensible trade. I would rather leave torque on the table than rebuild a gearbox on the hard shoulder.

The torque cap is not a blunt limiter. It runs through the same torque model that the traction control uses, reaching for throttle area first and ignition retard second. What that fuel and boost combination is actually worth is covered in What E85 Actually Buys.

What’s next

The 8HP75 and an Emtron TM16 controller, together, and both for the same reason: the car is currently limited by the weakest link in the driveline and that link is known.

The interesting part is that swapping the controller as well as the box separates the two variables. Same engine, same power, same driver, same roads, two different transmission controllers. That comparison does not exist anywhere that I can find, and when it does I will publish both sides of it.

Full specification and the dyno sheet are on the Supra project page. The gearbox installation itself is covered in The Big Single and 8 Speed.

If you have run an 8HP70 past 900 lb ft and it held, or lost one well below it, I would like to know the gear, the controller and the fluid temperature. Those are the three numbers everyone leaves out.

The post Where the Stock ZF 8HP70 Gives Up: 901 lb ft, Measured first appeared on BlownByTwins.

The post Where the Stock ZF 8HP70 Gives Up: 901 lb ft, Measured appeared first on BlownByTwins.