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.

This guide covers the countries UK drivers most often drive through on a continental trip. Every figure below was checked against 2026 sources on 1 October 2026. Fines change often, so check again before you travel. This is general information, not legal advice.

Will a camera fine follow you home?

Possibly, and the odds are rising. Do not plan a trip around the idea that it won’t.

Until the end of 2020 the UK was part of the EU’s cross-border enforcement scheme, which let any member state look up a UK car’s keeper and post the fine. Since 1 January 2021 that has not applied, so camera fines have mostly not reached UK addresses (Auto Express). Some still did: French fines have kept turning up in UK post, even though the DVLA had released no keeper data to France under the old rules by mid-2025 (Connexion).

Three things close that gap:

• Roadside stops. Brexit never changed these. If police pull you over, you pay there and then.
• Hire cars. The rental firm hands over your details and usually adds an admin fee on top of the fine.
• Data sharing is coming back. The May 2025 UK–EU summit agreed to finish setting up automated vehicle-registration data exchange. In mid-2026 UK police gained number-plate lookups through the EU’s Prüm system, with EU police able to request DVLA data in return (GOV.UK announcement). That system is framed around serious crime; whether it will be used for camera fines had not been announced when this was written.

Separately, the EU has tightened its own cross-border rules (Directive 2024/3237, in force across member states by 20 July 2027), adding cross-border help with collecting unpaid fines (European Parliament summary). That covers EU-registered cars, not UK ones, but it shows the direction of travel.

A foreign speeding fine does not normally put points on a UK licence. An unpaid one can still be demanded the next time you are stopped in that country.

Country by country

Germany and Spain are among the cheapest places to get a ticket; Norway and Switzerland are the dearest. Each row is one speed limit. It shows the fine at 20 km/h over, then the speed at which you risk your licence, then the speed at which it becomes a criminal case. All speeds are km/h, after the police measuring margin.

• A dash means no fixed threshold.
• Germany treats speeding as a crime only under its illegal-racing law.
• Spain uses penalty points rather than a set ban speed; bans come with a criminal conviction.
• The Netherlands has the “criminal” column is where the prosecutor, not a fixed tariff, sets the penalty.
• Norway’s jail thresholds were not verified for this guide.

Two caveats. Fines are in local currency and euro figures drift with inflation; the Netherlands has already published higher 2027 rates. And police subtract a measuring margin before working out the fine, 3 km/h below 100 km/h and 3% above it in Germany and the Netherlands, and 5 km/h or 5% in France and Italy, so the speed on the radar will be a little higher than the figures above.

Where it stops being a fine

In several countries, a big enough number means a criminal record, a court date or losing the car itself, and that applies to foreign drivers and to cars they don’t own.

• France, 50 km/h or more over (since 29 December 2025). Now a criminal offence on a first offence. Usually settled by a €300 fixed penalty (€250 if paid quickly, €600 if late), but a court can impose up to €3,750, three months in prison, a suspension of up to three years and confiscation of the vehicle (Beedriver).
• Austria, 60 over in town or 70 over outside (since 1 March 2024). Police can seize the car on the spot. At 80 over in town or 90 outside, or for repeat offenders, it can be confiscated for good and auctioned, even if it is hired or leased. Fines go up to €7,500 (Maut1). By the end of 2025, 438 cars had been provisionally seized (Vienna.at).
• Switzerland, 50 over in town, 60 outside or 80 on a motorway. Classed as reckless “Raser” driving, with prison of one to four years and very large fines (ch.ch).
• Spain, 60 over in town or 80 over elsewhere. Can be prosecuted as a crime under the Penal Code (Motorpasión).
• Denmark. Its “insane driving” rules allow the car to be confiscated for extreme speeding, including driving at more than double the limit (FDM).

If you get pulled over

Expect to pay before you drive away. Police in much of Europe ask non-resident drivers to pay the fine on the spot or leave a cash or card deposit, and can hold the car until you do.

• Carry a card that works abroad and some cash in local currency (francs in Switzerland, kroner in Norway).
• Ask for an official receipt or ticket for anything you pay.
• Paying quickly is often cheaper: Spain halves the fine if paid within 20 days, and France has a reduced rate for prompt payment.
• In a hire car, assume the fine will reach you through the rental company, with their admin charge added.

Radar detectors and camera apps

Leave the radar detector at home. A device that is legal in the UK is illegal to use in France and Germany (Confused.com), and in France and Switzerland one can be confiscated even if it is switched off (Tyremap). In Germany, a driver using a detector or a camera-warning app faces a €75 fine and a point (McParking).

Phone apps are a grey area that changes country by country. The simplest safe setup is to turn off camera alerts and keep the speed-limit display on.

Before you go

• Check the limits for every country on your route; Dutch motorways drop to 100 km/h by day, and much of Brussels is 30.
• Remove or switch off any radar detector, and turn off camera alerts in your sat-nav or phone.
• Pack a card that works abroad and some local cash for roadside fines.
• If you get a fine in the post, check it is genuine with the issuing authority before paying.

Figures were checked against the linked 2026 sources on 1 October 2026. Fine levels change, often every January, so treat anything older than a few months with caution.

The post Speeding in Europe 2026: What UK Drivers Actually Risk first appeared on BlownByTwins.

The post Speeding in Europe 2026: What UK Drivers Actually Risk appeared first on BlownByTwins.

The VVT-i control on the 3.4-litre 2JZ-GTE has been a good example.

The car wasn’t suffering from some catastrophic VVT-i failure. The cam moved, the ECU controlled it and, once everything was properly hot, it could track the requested position extremely accurately.

What caught my attention was that it wasn’t equally good all the time.

The further I dug into the logs, the clearer it became that oil temperature was having a significant effect on what the VVT-i controller needed to do.

This is the journey from a conventional PID setup, through feed-forward changes and temperature-dependent duty-cycle limits, to the new oil-temperature-compensated PID strategy we’re about to test.

The starting point

The VVT-i system is controlled by the Emtron KV12 using closed-loop PID control.

In simple terms, the ECU has a requested inlet cam position and an actual measured cam position. The difference between those two is the VVT Target Error.

The PID controller then uses three components to correct it:

• Proportional (P) reacts to the current error.
• Integral (I) reacts to error accumulated over time.
• Derivative (D) reacts to how quickly that error is changing.

There is also a Feed Forward duty cycle. Rather than asking the PID to generate the entire solenoid command itself, feed-forward provides a baseline duty cycle that should put the VVT mechanism somewhere close to where it needs to be. PID then deals with the remaining error.

That distinction became important.

The first clue: the Integral was doing too much work

The original VVT feed-forward was around 34% DC.

Looking through the logs, the VVT system would track the target, but the Integral controller was regularly having to add substantial duty cycle.

That tells you something.

If the controller repeatedly needs Integral to provide the same correction, Integral isn’t really correcting a transient disturbance any more. It’s compensating for an inaccurate baseline.

So I increased VVT feed-forward to 41% DC.

At the same time, I reduced the VVT deadband to ±0.4°.

The deadband is simply the region around the target where the ECU stops trying to correct tiny errors. There’s no benefit in constantly moving the VVT solenoid because the cam is 0.1° away from target. That can simply introduce unnecessary activity and oscillation.

The initial results with 41% were interesting.

When fully hot, they were excellent.

When cold, they weren’t.

Oil temperature was the missing variable

Once I started analysing the VVT logs against engine oil temperature, a very obvious pattern appeared.

With the fixed 41% feed-forward, the approximate Integral correction looked like this:

At approximately 96–100°C oil temperature, VVT control was exceptionally good.

One of the hot boost logs produced approximately:

That is basically where I wanted it.

The feed-forward gets the system very close, the PID makes small corrections, and the actual cam follows the requested position accurately.

But look at the other end of the temperature range.

Cold, the Integral controller was approaching its -8% DC clamp.

That immediately suggested the problem wasn’t fundamentally the PID gains.

The hydraulic system itself was changing.

VVT-i is an oil-pressure-operated system

This sounds obvious once you say it, but it matters enormously to the calibration.

The Toyota VVT-i mechanism is hydraulic.

Change the oil temperature and you change the viscosity of the oil. That changes the behaviour of the solenoid and cam phaser for a given electrical duty cycle.

So why should we expect one fixed solenoid feed-forward duty to be correct at 20°C oil temperature and still be correct at 100°C?

We shouldn’t.

The logs were effectively showing us that.

This also explained why I didn’t want to start aggressively changing the P, I and D gains simply because the cold behaviour looked different.

Once the oil was properly hot, the PID was already working extremely well.

Changing a good PID to compensate for an incorrect hydraulic baseline would have been fixing the wrong thing.

The feature request to Emtron

The obvious solution seemed to be a temperature-dependent VVT feed-forward table.

Rather than:

Feed Forward = 41% DC

I wanted something conceptually closer to:

Oil temperature → appropriate base VVT solenoid duty

Potentially, the ideal implementation could eventually become a two-dimensional table using both oil temperature and engine speed.

I submitted the calibration and logs to Emtron as a feature request.

Nick Pavloski from Emtron came back with a pragmatic answer.

The requested change was unlikely to happen at this stage of the firmware development, but he suggested using the existing Min/Max Duty Cycle tables and their flexible axes to achieve what I needed.

That sent the calibration in a slightly different direction.

Using the VVT duty limits properly

The existing calibration already had temperature-dependent minimum and maximum VVT solenoid duty tables.

Originally, the minimum was essentially fixed at 10%, while maximum duty jumped from around 40% when cold to 80% once warm.

Rather than treating these purely as broad safety limits, I could use oil temperature as the flexible axis and progressively release VVT actuator authority as the oil warmed.

This isn’t exactly the same thing as temperature-dependent feed-forward.

That’s important.

Feed-forward moves the controller’s baseline operating point.

A Max DC table limits how much duty the controller is allowed to command.

Those are fundamentally different control strategies.

But I had the facility available, Emtron had recommended using it, and most importantly I could test the result objectively.

So I did.

The revised limits worked

The first useful cold-to-warm log with the revised limits was considerably better than I expected.

That is extremely accurate tracking.

So this wasn’t a tiny change visible only because we’d tortured the data sufficiently.

The improvement was substantial.

It also gave some useful validation to another calibration decision on the car.

I already have a warning light that remains active until engine oil exceeds 70°C. I don’t start using the car hard until that light goes out, and I also require the ZF 8HP gearbox to be above 40°C.

Previously I’d considered 90–95°C oil the point where VVT behaviour really became trustworthy.

With the revised VVT control, that changed.

By 60–70°C, the cam tracking was already extremely good.

The 70°C threshold now corresponds quite nicely with the point where the VVT system has demonstrated that it is properly under control.

But the Integral still told us something

Although actual cam tracking had improved dramatically, one thing hadn’t disappeared.

The Integral remained substantially negative during warm-up.

That means the underlying issue hasn’t magically vanished. The controller is still compensating for the relationship between fixed feed-forward duty and changing hydraulic behaviour.

The duty limits have given us a very effective workaround, but they haven’t fundamentally turned the fixed 41% feed-forward into a temperature-dependent feed-forward model.

Then I found another useful capability in EMtune.

The PID tables themselves can have a second axis.

And that axis can be Engine Oil Temperature.

That gives us another tool.

Moving from 2D to 3D PID control

Previously, each PID gain was effectively a one-dimensional table.

For example, proportional gain changed according to VVT Target Error.

Now I can retain Target Error on the X-axis and add Engine Oil Temperature on the Y-axis.

That means the controller can behave differently at 20°C oil temperature than it does at 100°C.

But there was an obvious trap here.

Just because the software gives you another axis doesn’t mean you should use it aggressively.

The hot VVT calibration was already excellent.

So the new strategy deliberately leaves the hot calibration alone.

The oil-temperature breakpoints are: 20 / 40 / 60 / 70 / 80 / 100°C

• From 80°C upwards, the original proven PID values remain unchanged.
• Below 80°C, P and I are progressively softened.
• Derivative remains unchanged across the entire temperature range.

The new Proportional table

The original hot P calibration is retained at 80°C and above. Columns are VVT Target Error; rows are engine oil temperature.

This isn’t a radical change.

That’s deliberate.

The proportional controller wasn’t broken.

Integral gets the bigger change

Integral is where temperature compensation potentially has more value.

The new table progressively reduces Integral gain as oil temperature falls:

Again, above 80°C nothing changes.

The objective isn’t to hide the fact that Integral wants to correct the baseline. Reducing I gain cannot fix an incorrect feed-forward value.

It simply stops the Integral controller aggressively accumulating correction while the cold hydraulic system is simultaneously being constrained by the temperature-dependent duty limits.

And Derivative?

I left it alone.

Every temperature row uses the existing values:

There is currently no evidence that D needs temperature compensation.

Adding another variable because the software allows it is exactly how calibrations become unnecessarily complicated.

If future logs demonstrate a genuine temperature-dependent damping problem, I’ll change it.

Until then, D stays where it is.

Establishing a proper baseline

Before testing the new 3D PID, I logged the previous calibration fully warm.

That gives us something important: a benchmark.

At approximately 76–81°C oil temperature, the previous PID was already producing:

That’s very good.

So the new PID doesn’t get declared successful simply because a graph looks tidy.

It has to beat — or at minimum preserve — what I already have.

At 70–80°C, if the new calibration produces materially worse tracking than roughly 0.3° median absolute error, it has failed.

I’ll revert it.

Where the calibration stands now

The important bit is that this hasn’t been developed by randomly changing numbers until the car felt better.

Each step came from something measurable in the logs:

1. We saw excessive Integral correction.
2. We changed feed-forward.
3. That exposed a temperature relationship.
4. We correlated it against oil temperature.
5. We changed the available duty-cycle envelope.
6. Tracking improved substantially.
7. We then found that EMtune could add oil temperature directly to the PID gain tables.

Now I have a calibration specifically designed around what the data has shown us.

What happens next

The new 3D PID still needs validating.

The next useful log needs to capture the engine continuously through approximately:

• 20–40°C
• 40–60°C
• 60–70°C
• 70–80°C
• 80–100°C

Then, once properly hot, it needs some genuine loaded operation.

The channels that matter are VVT Target, VVT Position, Target Error, Solenoid Duty, PID Status and the individual P, I and D outputs.

I’m particularly interested in the transition through 60–80°C.

The previous calibration has already set a high standard there. The new strategy needs to preserve that accuracy while improving the behaviour earlier in the warm-up.

The ultimate objective isn’t a perfectly flat graph.

It’s much simpler than that.

When I ask the inlet cam to be somewhere, I want it to get there quickly, stay there accurately and do so without the PID controller having to fight the underlying system.

At around 100°C oil temperature, we’re already essentially there.

Now we’re trying to make the journey from cold oil to that operating state just as controlled.

The post Tuning VVT-i Properly: From Chasing Errors to an Oil-Temperature-Compensated PID first appeared on BlownByTwins.

The post Tuning VVT-i Properly: From Chasing Errors to an Oil-Temperature-Compensated PID 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.