SUBARU_5EAT_91D1206000
0x8008
MB431M
R9H
91D1206000
91D1206000
Pre-2005 (unconfirmed)
JDM
Subaru
5EAT TCU
91D1206000 (JDM)
5EAT
M32R
None
384kb
Firmware: 91D1206000 (cal ID MB431M, JDM, 384kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
The transmission's five forward gear ratios, indexed by current gear. Stock values match the Subaru factory service manual exactly: 3.540, 2.264, 1.471, 1.000, 0.834. The scale factor (raw/1024) is CONFIRMED — the decompiled code divides these by 0x400 when computing expected speed, and the result matches the published ratios to within 0.0007. Used by the TCU to compute expected output speed per gear and to detect gear-ratio faults (DTC P0730). Changing these does NOT change the physical gearing — it changes what the TCU BELIEVES the gearing is, which affects ratio-based fault detection and speed calculations.
One of five parallel 14-entry bit-pattern arrays (packed contiguously at 0x0087AA-0x0087EF), all indexed by the same internal shift-state variable (0-13) and each driving a different control output (this one feeds RAM 0x00808885). Confirmed via decompilation. EXPERT/DANGEROUS. These are BIT PATTERNS (every stock value is a power of two), not scalar quantities — editing them as ordinary numbers is very likely to produce an invalid pattern. On an automatic transmission an invalid clutch/solenoid pattern can command two elements at once, which can bind the driveline and cause real mechanical damage. The exact output each bit drives is NOT decoded — do not change these unless you have independently confirmed what each bit does on this exact firmware.
One of five parallel 14-entry bit-pattern arrays (packed contiguously at 0x0087AA-0x0087EF), all indexed by the same internal shift-state variable (0-13) and each driving a different control output (this one feeds RAM 0x00808883). Confirmed via decompilation. EXPERT/DANGEROUS. These are BIT PATTERNS (every stock value is a power of two), not scalar quantities — editing them as ordinary numbers is very likely to produce an invalid pattern. On an automatic transmission an invalid clutch/solenoid pattern can command two elements at once, which can bind the driveline and cause real mechanical damage. The exact output each bit drives is NOT decoded — do not change these unless you have independently confirmed what each bit does on this exact firmware.
One of five parallel 14-entry bit-pattern arrays (packed contiguously at 0x0087AA-0x0087EF), all indexed by the same internal shift-state variable (0-13) and each driving a different control output (this one feeds RAM 0x00808861). Confirmed via decompilation. EXPERT/DANGEROUS. These are BIT PATTERNS (every stock value is a power of two), not scalar quantities — editing them as ordinary numbers is very likely to produce an invalid pattern. On an automatic transmission an invalid clutch/solenoid pattern can command two elements at once, which can bind the driveline and cause real mechanical damage. The exact output each bit drives is NOT decoded — do not change these unless you have independently confirmed what each bit does on this exact firmware.
One of five parallel 14-entry bit-pattern arrays (packed contiguously at 0x0087AA-0x0087EF), all indexed by the same internal shift-state variable (0-13) and each driving a different control output (this one feeds RAM 0x00808863). Confirmed via decompilation. EXPERT/DANGEROUS. These are BIT PATTERNS (every stock value is a power of two), not scalar quantities — editing them as ordinary numbers is very likely to produce an invalid pattern. On an automatic transmission an invalid clutch/solenoid pattern can command two elements at once, which can bind the driveline and cause real mechanical damage. The exact output each bit drives is NOT decoded — do not change these unless you have independently confirmed what each bit does on this exact firmware.
One of five parallel 14-entry bit-pattern arrays (packed contiguously at 0x0087AA-0x0087EF), all indexed by the same internal shift-state variable (0-13) and each driving a different control output (this one feeds RAM 0x0080886B). Confirmed via decompilation. EXPERT/DANGEROUS. These are BIT PATTERNS (every stock value is a power of two), not scalar quantities — editing them as ordinary numbers is very likely to produce an invalid pattern. On an automatic transmission an invalid clutch/solenoid pattern can command two elements at once, which can bind the driveline and cause real mechanical damage. The exact output each bit drives is NOT decoded — do not change these unless you have independently confirmed what each bit does on this exact firmware.
Below this ATF temperature the TCU swaps in a placeholder (disabled) shift schedule specifically when in 5th gear — i.e. it restricts 5th until the fluid warms up. Stock 15 °C / 59 °F. Confirmed via decompilation: the check is gated on current gear == 5th. Raising it keeps 5th locked out longer; lowering it releases 5th sooner on a cold transmission.
The temperature the TCU substitutes when the measured ATF temperature is flagged unusable. Stock 95 °C / 203 °F — a deliberately warm assumption, so a failed sensor does not make the TCU behave as if the fluid were cold.
Lower half of a two-point temperature switch with built-in hysteresis (pairs with 'Cold Switchover Temperature (Upper)'). Below this the TCU selects one calibration constant; at or above the upper point it selects another. Stock -10 °C / 14 °F.
Upper half of the cold switchover hysteresis pair. Stock -5 °C / 23 °F. Keep this above the lower point — inverting them would remove the hysteresis and can cause the selection to chatter.
Pulses per revolution for speed sensor channel 1. CONFIRMED: the firmware computes RPM as 60,000,000 / (this value x measured pulse period) — the standard period-to-RPM formula (60 seconds x a 1 MHz timer). Stock value 16, i.e. a 16-tooth tone ring. Change this ONLY if the physical tone ring / sensor tooth count actually differs, otherwise every speed-derived calculation in the TCU will be wrong.
Pulses per revolution for speed sensor channel 2 — same confirmed 60,000,000/(N x period) RPM formula as channel 1, on an independent input with its own tooth count. Stock value 22. Same warning: only change this if the physical tooth count genuinely differs.
Upper clamp applied to both speed-sensor channels AND to the CAN-received engine speed signal — all three are limited to this value. Stock 10000 (RPM). This shared clamp is part of the evidence that all three signals carry the same unit; it also sets the ceiling the engine-speed table axes are derived against.
Confirmed via decompilation: the calibratable gain argument to the first-order smoothing filter that produces the CAN ID 0x410-derived reference signal (docs/TECHNICAL-NOTES.md), stock value 128. Larger = faster response to changes in the incoming CAN signal, smaller = more smoothing/lag.
Confirmed via decompilation: the calibratable gain argument to the smoothing filter that feeds the 'Smoothed Signal Response Curve' table (0x0117BE), stock value 128. Larger = faster response, smaller = more smoothing/lag.
Confirmed via decompilation: a single-byte constant (stock value 2) compared directly against the current gear (0x0080885A) and a second gear-like index (0x0080886E) in several places in the same function — reads like a 'this logic only applies above/below gear N' cutoff. Exact effect of changing it is NOT verified on real hardware.
Confirmed via decompilation: a constant compared against a computed signal delta in the same fault-detection routine that reads the Pressure Threshold E tables. Storage width (byte vs. word) was inferred from the surrounding code pattern, not independently double-checked — verify before relying on the exact stored value.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
42a
42b
43a
43b
44a
44b
45a
45b
ADC-to-temperature curve for temperature sensor 1. Column 1 is the inverted raw ADC reading, column 2 the resulting temperature as (value - 40) degrees C. This is the calibration that defines what the sensor reads: editing it changes every temperature-dependent decision the TCU makes. Confirmed encoding.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION. Converts the raw ADC reading from the sensor into a temperature. The breakpoint is the ADC count, the value is what the TCU believes that count means.
This is what every temperature-dependent behaviour in the transmission ultimately reads, so changing it shifts the apparent temperature everywhere at once - including the cold-fluid pressure boost and the overheat protection. It is a calibration for the sensor, not a tuning knob.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
42a
42b
43a
43b
44a
44b
45a
45b
ADC-to-temperature curve for temperature sensor 1. Column 1 is the inverted raw ADC reading, column 2 the resulting temperature as (value - 40) degrees C. This is the calibration that defines what the sensor reads: editing it changes every temperature-dependent decision the TCU makes. Confirmed encoding.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION. Converts the raw ADC reading from the sensor into a temperature. The breakpoint is the ADC count, the value is what the TCU believes that count means.
This is what every temperature-dependent behaviour in the transmission ultimately reads, so changing it shifts the apparent temperature everywhere at once - including the cold-fluid pressure boost and the overheat protection. It is a calibration for the sensor, not a tuning knob.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
ADC-to-temperature curve for temperature sensor 2. Same encoding as sensor 1: column 1 inverted raw ADC, column 2 temperature as (value - 40) degrees C.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION, second channel. See the notes on Temp Sensor 1: same role, same warning.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
ADC-to-temperature curve for temperature sensor 2. Same encoding as sensor 1: column 1 inverted raw ADC, column 2 temperature as (value - 40) degrees C.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION, second channel. See the notes on Temp Sensor 1: same role, same warning.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
TORQUE CONVERTER SLIP FACTOR. Part of the line pressure chain: engine torque from CAN 0x412 is multiplied by this factor, smoothed, multiplied again by the ATF temperature factor, and the result looks up the line pressure target.
The breakpoint is the turbine-to-engine speed ratio, so 1.000 is locked and lower numbers are more slip. Raising a value raises line pressure at that amount of slip, which firms up the clutches and speeds up shifts, at the cost of pump load and harsher engagement.
The scale is confirmed against the description posted by rimwall on the RomRaider forum: a ratio of 0.5 gives 1.392 here against his stated ~1.4, and low slip gives exactly 1.000 against his stated ~1.0.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
TORQUE CONVERTER SLIP FACTOR. Part of the line pressure chain: engine torque from CAN 0x412 is multiplied by this factor, smoothed, multiplied again by the ATF temperature factor, and the result looks up the line pressure target.
The breakpoint is the turbine-to-engine speed ratio, so 1.000 is locked and lower numbers are more slip. Raising a value raises line pressure at that amount of slip, which firms up the clutches and speeds up shifts, at the cost of pump load and harsher engagement.
The scale is confirmed against the description posted by rimwall on the RomRaider forum: a ratio of 0.5 gives 1.392 here against his stated ~1.4, and low slip gives exactly 1.000 against his stated ~1.0.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
Indexed by the CAN ID 0x412 byte 0 signal (the same operand used by the Pressure Control X-formula).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
Indexed by the CAN ID 0x412 byte 0 signal (the same operand used by the Pressure Control X-formula).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE PRESSURE FACTOR. The second multiplier in the line pressure chain. Runs about 1.70 when the fluid is very cold down to exactly 1.000 once warm, so the transmission raises line pressure while cold to compensate for fluid viscosity.
The /256 fixed point is confirmed from the code, not inferred from the shape: the lookup result is multiplied by a factor that defaults to 0x100 - which is 256, unity - and the product is shifted right by 16, which is exact only if both are /256.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE PRESSURE FACTOR. The second multiplier in the line pressure chain. Runs about 1.70 when the fluid is very cold down to exactly 1.000 once warm, so the transmission raises line pressure while cold to compensate for fluid viscosity.
The /256 fixed point is confirmed from the code, not inferred from the shape: the lookup result is multiplied by a factor that defaults to 0x100 - which is 256, unity - and the product is shifted right by 16, which is exact only if both are /256.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
Record-format curve located by call-site enumeration. Input not identified.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
Record-format curve located by call-site enumeration. Input not identified.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1. Mode-selected pair with Mode 2.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1. Mode-selected pair with Mode 2.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1. Mode-selected counterpart to Mode 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1. Mode-selected counterpart to Mode 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
9.4
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
9.4
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
9.4
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
9.4
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE20 as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE76 as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE74 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE50 as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE72 as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE18 as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE70 as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE1A as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE32 as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE34 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE36 as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE38 as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE8E as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE6E as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE26 as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE30 as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE2E as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEB2 as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE28 as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEB0 as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE2A as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEAE as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE6C as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEAC as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE6A as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEAA as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE8C as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE68 as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CED4 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CED2 as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CED0 as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CECE as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CECC as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CECA as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEC8 as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CED6 as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE2C as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE3A as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE98 as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE9C as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE9A as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE80 as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE7E as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE7C as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE7A as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE92 as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE90 as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE78 as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEC0 as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEBE as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEBC as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEBA as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEB8 as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_91FE216300
0x8008
MB436G
QS1
91FE216300
91FE216300
2005
USDM
Subaru
5EAT TCU
91FE216300 (USDM Outback XT)
5EAT
M32R
None
512kb
Firmware: 91FE216300 (cal ID MB436G, USDM, 512kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
42a
42b
43a
43b
44a
44b
45a
45b
ADC-to-temperature curve for temperature sensor 1. Column 1 is the inverted raw ADC reading, column 2 the resulting temperature as (value - 40) degrees C. This is the calibration that defines what the sensor reads: editing it changes every temperature-dependent decision the TCU makes. Confirmed encoding.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION. Converts the raw ADC reading from the sensor into a temperature. The breakpoint is the ADC count, the value is what the TCU believes that count means.
This is what every temperature-dependent behaviour in the transmission ultimately reads, so changing it shifts the apparent temperature everywhere at once - including the cold-fluid pressure boost and the overheat protection. It is a calibration for the sensor, not a tuning knob.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
42a
42b
43a
43b
44a
44b
45a
45b
ADC-to-temperature curve for temperature sensor 1. Column 1 is the inverted raw ADC reading, column 2 the resulting temperature as (value - 40) degrees C. This is the calibration that defines what the sensor reads: editing it changes every temperature-dependent decision the TCU makes. Confirmed encoding.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION. Converts the raw ADC reading from the sensor into a temperature. The breakpoint is the ADC count, the value is what the TCU believes that count means.
This is what every temperature-dependent behaviour in the transmission ultimately reads, so changing it shifts the apparent temperature everywhere at once - including the cold-fluid pressure boost and the overheat protection. It is a calibration for the sensor, not a tuning knob.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
ADC-to-temperature curve for temperature sensor 2. Same encoding as sensor 1: column 1 inverted raw ADC, column 2 temperature as (value - 40) degrees C.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION, second channel. See the notes on Temp Sensor 1: same role, same warning.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
ADC-to-temperature curve for temperature sensor 2. Same encoding as sensor 1: column 1 inverted raw ADC, column 2 temperature as (value - 40) degrees C.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION, second channel. See the notes on Temp Sensor 1: same role, same warning.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
TORQUE CONVERTER SLIP FACTOR. Part of the line pressure chain: engine torque from CAN 0x412 is multiplied by this factor, smoothed, multiplied again by the ATF temperature factor, and the result looks up the line pressure target.
The breakpoint is the turbine-to-engine speed ratio, so 1.000 is locked and lower numbers are more slip. Raising a value raises line pressure at that amount of slip, which firms up the clutches and speeds up shifts, at the cost of pump load and harsher engagement.
The scale is confirmed against the description posted by rimwall on the RomRaider forum: a ratio of 0.5 gives 1.392 here against his stated ~1.4, and low slip gives exactly 1.000 against his stated ~1.0.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
TORQUE CONVERTER SLIP FACTOR. Part of the line pressure chain: engine torque from CAN 0x412 is multiplied by this factor, smoothed, multiplied again by the ATF temperature factor, and the result looks up the line pressure target.
The breakpoint is the turbine-to-engine speed ratio, so 1.000 is locked and lower numbers are more slip. Raising a value raises line pressure at that amount of slip, which firms up the clutches and speeds up shifts, at the cost of pump load and harsher engagement.
The scale is confirmed against the description posted by rimwall on the RomRaider forum: a ratio of 0.5 gives 1.392 here against his stated ~1.4, and low slip gives exactly 1.000 against his stated ~1.0.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
Indexed by the CAN ID 0x412 byte 0 signal (the same operand used by the Pressure Control X-formula).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
Indexed by the CAN ID 0x412 byte 0 signal (the same operand used by the Pressure Control X-formula).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE PRESSURE FACTOR. The second multiplier in the line pressure chain. Runs about 1.70 when the fluid is very cold down to exactly 1.000 once warm, so the transmission raises line pressure while cold to compensate for fluid viscosity.
The /256 fixed point is confirmed from the code, not inferred from the shape: the lookup result is multiplied by a factor that defaults to 0x100 - which is 256, unity - and the product is shifted right by 16, which is exact only if both are /256.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE PRESSURE FACTOR. The second multiplier in the line pressure chain. Runs about 1.70 when the fluid is very cold down to exactly 1.000 once warm, so the transmission raises line pressure while cold to compensate for fluid viscosity.
The /256 fixed point is confirmed from the code, not inferred from the shape: the lookup result is multiplied by a factor that defaults to 0x100 - which is 256, unity - and the product is shifted right by 16, which is exact only if both are /256.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Record-format curve located by call-site enumeration. Input not identified.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Record-format curve located by call-site enumeration. Input not identified.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by ATF temperature from sensor 1. Mode-selected pair with Mode 2.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by ATF temperature from sensor 1. Mode-selected pair with Mode 2.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
Indexed by ATF temperature from sensor 1. Mode-selected counterpart to Mode 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
Indexed by ATF temperature from sensor 1. Mode-selected counterpart to Mode 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
31.4
37.6
50.2
62.7
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
31.4
37.6
50.2
62.7
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
31.4
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
3.1
12.5
25.1
37.6
50.2
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
3.1
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
3.1
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
3.1
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE4C as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEA2 as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEA0 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE7C as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE9E as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE44 as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE9C as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE46 as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE5E as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE60 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE62 as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE64 as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEBA as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE9A as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE52 as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE5C as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE5A as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEDE as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE54 as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEDC as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE56 as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEDA as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE98 as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CED8 as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE96 as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CED6 as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEB8 as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE94 as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF00 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEFE as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEFC as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEFA as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEF8 as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEF6 as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEF4 as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF02 as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE58 as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE66 as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEC4 as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEC8 as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEC6 as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEAC as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEAA as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEA8 as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEA6 as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEBE as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEBC as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEA4 as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEEC as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEEA as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEE8 as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEE6 as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEE4 as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_91D0207500
0x8008
MB436T
Q3E
91D0207500
91D0207500
Unknown
JDM
Subaru
5EAT TCU
91D0207500 (JDM)
5EAT
M32R
None
384kb
Firmware: 91D0207500 (cal ID MB436T, JDM, 384kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
42a
42b
43a
43b
44a
44b
45a
45b
ADC-to-temperature curve for temperature sensor 1. Column 1 is the inverted raw ADC reading, column 2 the resulting temperature as (value - 40) degrees C. This is the calibration that defines what the sensor reads: editing it changes every temperature-dependent decision the TCU makes. Confirmed encoding.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION. Converts the raw ADC reading from the sensor into a temperature. The breakpoint is the ADC count, the value is what the TCU believes that count means.
This is what every temperature-dependent behaviour in the transmission ultimately reads, so changing it shifts the apparent temperature everywhere at once - including the cold-fluid pressure boost and the overheat protection. It is a calibration for the sensor, not a tuning knob.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
42a
42b
43a
43b
44a
44b
45a
45b
ADC-to-temperature curve for temperature sensor 1. Column 1 is the inverted raw ADC reading, column 2 the resulting temperature as (value - 40) degrees C. This is the calibration that defines what the sensor reads: editing it changes every temperature-dependent decision the TCU makes. Confirmed encoding.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION. Converts the raw ADC reading from the sensor into a temperature. The breakpoint is the ADC count, the value is what the TCU believes that count means.
This is what every temperature-dependent behaviour in the transmission ultimately reads, so changing it shifts the apparent temperature everywhere at once - including the cold-fluid pressure boost and the overheat protection. It is a calibration for the sensor, not a tuning knob.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
ADC-to-temperature curve for temperature sensor 2. Same encoding as sensor 1: column 1 inverted raw ADC, column 2 temperature as (value - 40) degrees C.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION, second channel. See the notes on Temp Sensor 1: same role, same warning.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
ADC-to-temperature curve for temperature sensor 2. Same encoding as sensor 1: column 1 inverted raw ADC, column 2 temperature as (value - 40) degrees C.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION, second channel. See the notes on Temp Sensor 1: same role, same warning.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
TORQUE CONVERTER SLIP FACTOR. Part of the line pressure chain: engine torque from CAN 0x412 is multiplied by this factor, smoothed, multiplied again by the ATF temperature factor, and the result looks up the line pressure target.
The breakpoint is the turbine-to-engine speed ratio, so 1.000 is locked and lower numbers are more slip. Raising a value raises line pressure at that amount of slip, which firms up the clutches and speeds up shifts, at the cost of pump load and harsher engagement.
The scale is confirmed against the description posted by rimwall on the RomRaider forum: a ratio of 0.5 gives 1.392 here against his stated ~1.4, and low slip gives exactly 1.000 against his stated ~1.0.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
TORQUE CONVERTER SLIP FACTOR. Part of the line pressure chain: engine torque from CAN 0x412 is multiplied by this factor, smoothed, multiplied again by the ATF temperature factor, and the result looks up the line pressure target.
The breakpoint is the turbine-to-engine speed ratio, so 1.000 is locked and lower numbers are more slip. Raising a value raises line pressure at that amount of slip, which firms up the clutches and speeds up shifts, at the cost of pump load and harsher engagement.
The scale is confirmed against the description posted by rimwall on the RomRaider forum: a ratio of 0.5 gives 1.392 here against his stated ~1.4, and low slip gives exactly 1.000 against his stated ~1.0.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
Indexed by the CAN ID 0x412 byte 0 signal (the same operand used by the Pressure Control X-formula).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
Indexed by the CAN ID 0x412 byte 0 signal (the same operand used by the Pressure Control X-formula).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE PRESSURE FACTOR. The second multiplier in the line pressure chain. Runs about 1.70 when the fluid is very cold down to exactly 1.000 once warm, so the transmission raises line pressure while cold to compensate for fluid viscosity.
The /256 fixed point is confirmed from the code, not inferred from the shape: the lookup result is multiplied by a factor that defaults to 0x100 - which is 256, unity - and the product is shifted right by 16, which is exact only if both are /256.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE PRESSURE FACTOR. The second multiplier in the line pressure chain. Runs about 1.70 when the fluid is very cold down to exactly 1.000 once warm, so the transmission raises line pressure while cold to compensate for fluid viscosity.
The /256 fixed point is confirmed from the code, not inferred from the shape: the lookup result is multiplied by a factor that defaults to 0x100 - which is 256, unity - and the product is shifted right by 16, which is exact only if both are /256.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Record-format curve located by call-site enumeration. Input not identified.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Record-format curve located by call-site enumeration. Input not identified.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by ATF temperature from sensor 1. Mode-selected pair with Mode 2.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by ATF temperature from sensor 1. Mode-selected pair with Mode 2.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
Indexed by ATF temperature from sensor 1. Mode-selected counterpart to Mode 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
Indexed by ATF temperature from sensor 1. Mode-selected counterpart to Mode 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
6.3
34.5
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
6.3
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
6.3
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
6.3
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
22.0
25.1
31.4
37.6
40.8
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
22.0
25.1
31.4
34.5
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
22.0
25.1
31.4
34.5
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
22.0
25.1
31.4
34.5
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
22.0
25.1
31.4
34.5
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
31.4
34.5
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D85C as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8B2 as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8B0 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D88C as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8AE as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D854 as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8AC as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D856 as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D86E as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D870 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D872 as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D874 as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8CA as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8AA as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D862 as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D86C as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D86A as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8EE as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D864 as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8EC as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D866 as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8EA as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8A8 as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8E8 as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8A6 as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8E6 as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8C8 as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8A4 as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D910 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D90E as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D90C as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D90A as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D908 as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D906 as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D904 as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D912 as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D868 as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D876 as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8D4 as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8D8 as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8D6 as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8BC as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8BA as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8B8 as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8B6 as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8CE as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8CC as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8B4 as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8FC as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8FA as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8F8 as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8F6 as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D8F4 as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_91F0217100
0x8008
MB436P
Q3B
91F0217100
91F0217100
2003
USDM
Subaru
5EAT TCU
91F0217100 (USDM Outback 03)
5EAT
M32R
None
384kb
Firmware: 91F0217100 (cal ID MB436P, USDM, 384kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
42a
42b
43a
43b
44a
44b
45a
45b
ADC-to-temperature curve for temperature sensor 1. Column 1 is the inverted raw ADC reading, column 2 the resulting temperature as (value - 40) degrees C. This is the calibration that defines what the sensor reads: editing it changes every temperature-dependent decision the TCU makes. Confirmed encoding.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION. Converts the raw ADC reading from the sensor into a temperature. The breakpoint is the ADC count, the value is what the TCU believes that count means.
This is what every temperature-dependent behaviour in the transmission ultimately reads, so changing it shifts the apparent temperature everywhere at once - including the cold-fluid pressure boost and the overheat protection. It is a calibration for the sensor, not a tuning knob.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
42a
42b
43a
43b
44a
44b
45a
45b
ADC-to-temperature curve for temperature sensor 1. Column 1 is the inverted raw ADC reading, column 2 the resulting temperature as (value - 40) degrees C. This is the calibration that defines what the sensor reads: editing it changes every temperature-dependent decision the TCU makes. Confirmed encoding.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION. Converts the raw ADC reading from the sensor into a temperature. The breakpoint is the ADC count, the value is what the TCU believes that count means.
This is what every temperature-dependent behaviour in the transmission ultimately reads, so changing it shifts the apparent temperature everywhere at once - including the cold-fluid pressure boost and the overheat protection. It is a calibration for the sensor, not a tuning knob.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
ADC-to-temperature curve for temperature sensor 2. Same encoding as sensor 1: column 1 inverted raw ADC, column 2 temperature as (value - 40) degrees C.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION, second channel. See the notes on Temp Sensor 1: same role, same warning.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
ADC-to-temperature curve for temperature sensor 2. Same encoding as sensor 1: column 1 inverted raw ADC, column 2 temperature as (value - 40) degrees C.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION, second channel. See the notes on Temp Sensor 1: same role, same warning.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
TORQUE CONVERTER SLIP FACTOR. Part of the line pressure chain: engine torque from CAN 0x412 is multiplied by this factor, smoothed, multiplied again by the ATF temperature factor, and the result looks up the line pressure target.
The breakpoint is the turbine-to-engine speed ratio, so 1.000 is locked and lower numbers are more slip. Raising a value raises line pressure at that amount of slip, which firms up the clutches and speeds up shifts, at the cost of pump load and harsher engagement.
The scale is confirmed against the description posted by rimwall on the RomRaider forum: a ratio of 0.5 gives 1.392 here against his stated ~1.4, and low slip gives exactly 1.000 against his stated ~1.0.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
TORQUE CONVERTER SLIP FACTOR. Part of the line pressure chain: engine torque from CAN 0x412 is multiplied by this factor, smoothed, multiplied again by the ATF temperature factor, and the result looks up the line pressure target.
The breakpoint is the turbine-to-engine speed ratio, so 1.000 is locked and lower numbers are more slip. Raising a value raises line pressure at that amount of slip, which firms up the clutches and speeds up shifts, at the cost of pump load and harsher engagement.
The scale is confirmed against the description posted by rimwall on the RomRaider forum: a ratio of 0.5 gives 1.392 here against his stated ~1.4, and low slip gives exactly 1.000 against his stated ~1.0.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
Indexed by the CAN ID 0x412 byte 0 signal (the same operand used by the Pressure Control X-formula).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
Indexed by the CAN ID 0x412 byte 0 signal (the same operand used by the Pressure Control X-formula).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE PRESSURE FACTOR. The second multiplier in the line pressure chain. Runs about 1.70 when the fluid is very cold down to exactly 1.000 once warm, so the transmission raises line pressure while cold to compensate for fluid viscosity.
The /256 fixed point is confirmed from the code, not inferred from the shape: the lookup result is multiplied by a factor that defaults to 0x100 - which is 256, unity - and the product is shifted right by 16, which is exact only if both are /256.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE PRESSURE FACTOR. The second multiplier in the line pressure chain. Runs about 1.70 when the fluid is very cold down to exactly 1.000 once warm, so the transmission raises line pressure while cold to compensate for fluid viscosity.
The /256 fixed point is confirmed from the code, not inferred from the shape: the lookup result is multiplied by a factor that defaults to 0x100 - which is 256, unity - and the product is shifted right by 16, which is exact only if both are /256.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Record-format curve located by call-site enumeration. Input not identified.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Record-format curve located by call-site enumeration. Input not identified.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by ATF temperature from sensor 1. Mode-selected pair with Mode 2.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by ATF temperature from sensor 1. Mode-selected pair with Mode 2.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
Indexed by ATF temperature from sensor 1. Mode-selected counterpart to Mode 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
Indexed by ATF temperature from sensor 1. Mode-selected counterpart to Mode 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
69.0
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
69.0
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
56.5
62.7
69.0
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
69.0
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
69.0
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
56.5
62.7
69.0
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
3.1
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
3.1
25.1
37.6
43.9
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
3.1
25.1
37.6
43.9
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
3.1
18.8
25.1
31.4
37.6
43.9
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
31.4
34.5
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
69.0
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
69.0
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
56.5
62.7
69.0
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
31.4
37.6
43.9
50.2
56.5
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
31.4
37.6
43.9
50.2
56.5
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEF0 as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF46 as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF44 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF20 as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF42 as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEE8 as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF40 as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEEA as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF02 as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF04 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF06 as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF08 as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF5E as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF3E as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEF6 as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF00 as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEFE as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF82 as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEF8 as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF80 as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEFA as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF7E as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF3C as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF7C as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF3A as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF7A as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF5C as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF38 as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CFA4 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CFA2 as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CFA0 as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF9E as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF9C as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF9A as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF98 as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CFA6 as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEFC as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF0A as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF68 as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF6C as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF6A as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF50 as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF4E as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF4C as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF4A as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF62 as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF60 as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF48 as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF90 as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF8E as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF8C as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF8A as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF88 as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_ABD1A03100
0x8008
MB4434
Q1F
ABD1A03100
ABD1A03100
2005
JDM
Subaru
5EAT TCU
ABD1A03100 (JDM Legacy GT 2005)
5EAT
M32R
None
384kb
Firmware: ABD1A03100 (cal ID MB4434, JDM, 384kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC3C as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC92 as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC90 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC6C as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC8E as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC34 as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC8C as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC36 as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC4E as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC50 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC52 as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC54 as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCAA as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC8A as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC42 as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC4C as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC4A as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCCE as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC44 as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCCC as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC46 as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCCA as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC88 as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCC8 as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC86 as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCC6 as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCA8 as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC84 as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCF0 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCEE as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCEC as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCEA as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCE8 as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCE6 as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCE4 as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCF2 as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC48 as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC56 as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCB4 as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCB8 as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCB6 as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC9C as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC9A as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC98 as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC96 as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCAE as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCAC as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC94 as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCDC as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCDA as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCD8 as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCD6 as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCD4 as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_91D1207900
0x8008
MB4373
Q3P
91D1207900
91D1207900
Unknown
JDM
Subaru
5EAT TCU
91D1207900 (Hitachi 31711AG589)
5EAT
M32R
None
384kb
Firmware: 91D1207900 (cal ID MB4373, JDM, 384kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
42a
42b
43a
43b
44a
44b
45a
45b
ADC-to-temperature curve for temperature sensor 1. Column 1 is the inverted raw ADC reading, column 2 the resulting temperature as (value - 40) degrees C. This is the calibration that defines what the sensor reads: editing it changes every temperature-dependent decision the TCU makes. Confirmed encoding.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION. Converts the raw ADC reading from the sensor into a temperature. The breakpoint is the ADC count, the value is what the TCU believes that count means.
This is what every temperature-dependent behaviour in the transmission ultimately reads, so changing it shifts the apparent temperature everywhere at once - including the cold-fluid pressure boost and the overheat protection. It is a calibration for the sensor, not a tuning knob.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
42a
42b
43a
43b
44a
44b
45a
45b
ADC-to-temperature curve for temperature sensor 1. Column 1 is the inverted raw ADC reading, column 2 the resulting temperature as (value - 40) degrees C. This is the calibration that defines what the sensor reads: editing it changes every temperature-dependent decision the TCU makes. Confirmed encoding.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION. Converts the raw ADC reading from the sensor into a temperature. The breakpoint is the ADC count, the value is what the TCU believes that count means.
This is what every temperature-dependent behaviour in the transmission ultimately reads, so changing it shifts the apparent temperature everywhere at once - including the cold-fluid pressure boost and the overheat protection. It is a calibration for the sensor, not a tuning knob.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
ADC-to-temperature curve for temperature sensor 2. Same encoding as sensor 1: column 1 inverted raw ADC, column 2 temperature as (value - 40) degrees C.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION, second channel. See the notes on Temp Sensor 1: same role, same warning.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
ADC-to-temperature curve for temperature sensor 2. Same encoding as sensor 1: column 1 inverted raw ADC, column 2 temperature as (value - 40) degrees C.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION, second channel. See the notes on Temp Sensor 1: same role, same warning.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
TORQUE CONVERTER SLIP FACTOR. Part of the line pressure chain: engine torque from CAN 0x412 is multiplied by this factor, smoothed, multiplied again by the ATF temperature factor, and the result looks up the line pressure target.
The breakpoint is the turbine-to-engine speed ratio, so 1.000 is locked and lower numbers are more slip. Raising a value raises line pressure at that amount of slip, which firms up the clutches and speeds up shifts, at the cost of pump load and harsher engagement.
The scale is confirmed against the description posted by rimwall on the RomRaider forum: a ratio of 0.5 gives 1.392 here against his stated ~1.4, and low slip gives exactly 1.000 against his stated ~1.0.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
TORQUE CONVERTER SLIP FACTOR. Part of the line pressure chain: engine torque from CAN 0x412 is multiplied by this factor, smoothed, multiplied again by the ATF temperature factor, and the result looks up the line pressure target.
The breakpoint is the turbine-to-engine speed ratio, so 1.000 is locked and lower numbers are more slip. Raising a value raises line pressure at that amount of slip, which firms up the clutches and speeds up shifts, at the cost of pump load and harsher engagement.
The scale is confirmed against the description posted by rimwall on the RomRaider forum: a ratio of 0.5 gives 1.392 here against his stated ~1.4, and low slip gives exactly 1.000 against his stated ~1.0.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
Indexed by the CAN ID 0x412 byte 0 signal (the same operand used by the Pressure Control X-formula).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
Indexed by the CAN ID 0x412 byte 0 signal (the same operand used by the Pressure Control X-formula).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE PRESSURE FACTOR. The second multiplier in the line pressure chain. Runs about 1.70 when the fluid is very cold down to exactly 1.000 once warm, so the transmission raises line pressure while cold to compensate for fluid viscosity.
The /256 fixed point is confirmed from the code, not inferred from the shape: the lookup result is multiplied by a factor that defaults to 0x100 - which is 256, unity - and the product is shifted right by 16, which is exact only if both are /256.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE PRESSURE FACTOR. The second multiplier in the line pressure chain. Runs about 1.70 when the fluid is very cold down to exactly 1.000 once warm, so the transmission raises line pressure while cold to compensate for fluid viscosity.
The /256 fixed point is confirmed from the code, not inferred from the shape: the lookup result is multiplied by a factor that defaults to 0x100 - which is 256, unity - and the product is shifted right by 16, which is exact only if both are /256.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Record-format curve located by call-site enumeration. Input not identified.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Record-format curve located by call-site enumeration. Input not identified.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by ATF temperature from sensor 1. Mode-selected pair with Mode 2.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by ATF temperature from sensor 1. Mode-selected pair with Mode 2.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
Indexed by ATF temperature from sensor 1. Mode-selected counterpart to Mode 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
Indexed by ATF temperature from sensor 1. Mode-selected counterpart to Mode 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
9.4
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
9.4
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
9.4
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
9.4
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4D0 as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D526 as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D524 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D500 as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D522 as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4C8 as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D520 as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4CA as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4E2 as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4E4 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4E6 as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4E8 as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D53E as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D51E as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4D6 as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4E0 as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4DE as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D562 as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4D8 as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D560 as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4DA as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D55E as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D51C as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D55C as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D51A as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D55A as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D53C as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D518 as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D584 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D582 as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D580 as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D57E as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D57C as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D57A as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D578 as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D586 as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4DC as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4EA as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D548 as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D54C as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D54A as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D530 as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D52E as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D52C as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D52A as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D542 as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D540 as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D528 as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D570 as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D56E as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D56C as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D56A as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D568 as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_AAD1A07100
0x8008
MB440X
Q2P
AAD1A07100
AAD1A07100
Unknown
JDM
Subaru
5EAT TCU
AAD1A07100 (Hitachi 31711AJ782)
5EAT
M32R
None
384kb
Firmware: AAD1A07100 (cal ID MB440X, JDM, 384kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
42a
42b
43a
43b
44a
44b
45a
45b
ADC-to-temperature curve for temperature sensor 1. Column 1 is the inverted raw ADC reading, column 2 the resulting temperature as (value - 40) degrees C. This is the calibration that defines what the sensor reads: editing it changes every temperature-dependent decision the TCU makes. Confirmed encoding.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION. Converts the raw ADC reading from the sensor into a temperature. The breakpoint is the ADC count, the value is what the TCU believes that count means.
This is what every temperature-dependent behaviour in the transmission ultimately reads, so changing it shifts the apparent temperature everywhere at once - including the cold-fluid pressure boost and the overheat protection. It is a calibration for the sensor, not a tuning knob.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
42a
42b
43a
43b
44a
44b
45a
45b
ADC-to-temperature curve for temperature sensor 1. Column 1 is the inverted raw ADC reading, column 2 the resulting temperature as (value - 40) degrees C. This is the calibration that defines what the sensor reads: editing it changes every temperature-dependent decision the TCU makes. Confirmed encoding.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION. Converts the raw ADC reading from the sensor into a temperature. The breakpoint is the ADC count, the value is what the TCU believes that count means.
This is what every temperature-dependent behaviour in the transmission ultimately reads, so changing it shifts the apparent temperature everywhere at once - including the cold-fluid pressure boost and the overheat protection. It is a calibration for the sensor, not a tuning knob.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
ADC-to-temperature curve for temperature sensor 2. Same encoding as sensor 1: column 1 inverted raw ADC, column 2 temperature as (value - 40) degrees C.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION, second channel. See the notes on Temp Sensor 1: same role, same warning.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
27a
27b
28a
28b
29a
29b
30a
30b
31a
31b
32a
32b
33a
33b
34a
34b
35a
35b
36a
36b
37a
37b
38a
38b
39a
39b
40a
40b
41a
41b
ADC-to-temperature curve for temperature sensor 2. Same encoding as sensor 1: column 1 inverted raw ADC, column 2 temperature as (value - 40) degrees C.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE SENSOR CALIBRATION, second channel. See the notes on Temp Sensor 1: same role, same warning.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
TORQUE CONVERTER SLIP FACTOR. Part of the line pressure chain: engine torque from CAN 0x412 is multiplied by this factor, smoothed, multiplied again by the ATF temperature factor, and the result looks up the line pressure target.
The breakpoint is the turbine-to-engine speed ratio, so 1.000 is locked and lower numbers are more slip. Raising a value raises line pressure at that amount of slip, which firms up the clutches and speeds up shifts, at the cost of pump load and harsher engagement.
The scale is confirmed against the description posted by rimwall on the RomRaider forum: a ratio of 0.5 gives 1.392 here against his stated ~1.4, and low slip gives exactly 1.000 against his stated ~1.0.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
TORQUE CONVERTER SLIP FACTOR. Part of the line pressure chain: engine torque from CAN 0x412 is multiplied by this factor, smoothed, multiplied again by the ATF temperature factor, and the result looks up the line pressure target.
The breakpoint is the turbine-to-engine speed ratio, so 1.000 is locked and lower numbers are more slip. Raising a value raises line pressure at that amount of slip, which firms up the clutches and speeds up shifts, at the cost of pump load and harsher engagement.
The scale is confirmed against the description posted by rimwall on the RomRaider forum: a ratio of 0.5 gives 1.392 here against his stated ~1.4, and low slip gives exactly 1.000 against his stated ~1.0.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82AC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
Indexed by the CAN ID 0x412 byte 0 signal (the same operand used by the Pressure Control X-formula).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
Indexed by the CAN ID 0x412 byte 0 signal (the same operand used by the Pressure Control X-formula).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE PRESSURE FACTOR. The second multiplier in the line pressure chain. Runs about 1.70 when the fluid is very cold down to exactly 1.000 once warm, so the transmission raises line pressure while cold to compensate for fluid viscosity.
The /256 fixed point is confirmed from the code, not inferred from the shape: the lookup result is multiplied by a factor that defaults to 0x100 - which is 256, unity - and the product is shifted right by 16, which is exact only if both are /256.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by ATF temperature from sensor 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
ATF TEMPERATURE PRESSURE FACTOR. The second multiplier in the line pressure chain. Runs about 1.70 when the fluid is very cold down to exactly 1.000 once warm, so the transmission raises line pressure while cold to compensate for fluid viscosity.
The /256 fixed point is confirmed from the code, not inferred from the shape: the lookup result is multiplied by a factor that defaults to 0x100 - which is 256, unity - and the product is shifted right by 16, which is exact only if both are /256.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
17a
17b
18a
18b
19a
19b
20a
20b
21a
21b
22a
22b
23a
23b
24a
24b
25a
25b
26a
26b
Indexed by internal signal FE. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
One of three parallel curves feeding adjacent solenoid output variables, sharing a common input.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by internal signal 82CC. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Record-format curve located by call-site enumeration. Input not identified.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Record-format curve located by call-site enumeration. Input not identified.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the reference speed signal (a parallel copy of the central CAN-derived speed value).
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
Indexed by the smoothed CAN 0x410 engine-speed signal (the same input as the Speed Trim / Slip Detection families). One of six selected by operating mode.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
RPM RANGE: engine speed is a uint16 scaled by 1/8, so the highest value these tables can hold is 8191 RPM. The stock calibration already uses breakpoints as high as 8160 RPM elsewhere, so there is room to raise shift and slip breakpoints for a built engine - but a target above 8191 RPM cannot be represented here, and entering one will clip.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by ATF temperature from sensor 1. Mode-selected pair with Mode 2.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
Indexed by ATF temperature from sensor 1. Mode-selected pair with Mode 2.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
Indexed by ATF temperature from sensor 1. Mode-selected counterpart to Mode 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
14a
14b
15a
15b
16a
16b
Indexed by ATF temperature from sensor 1. Mode-selected counterpart to Mode 1.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
Indexed by the smoothed internal signal AE8. Physical meaning of the input is not confirmed.
Format: an array of 8-byte records, each one segment of a piecewise-linear curve. The array is terminated by a leading 0xFFFF.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D78C as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7E2 as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7E0 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7BC as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7DE as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D784 as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7DC as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D786 as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D79E as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7A0 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7A2 as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7A4 as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7FA as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7DA as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D792 as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D79C as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D79A as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D81E as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D794 as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D81C as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D796 as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D81A as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7D8 as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D818 as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7D6 as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D816 as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7F8 as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7D4 as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D840 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D83E as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D83C as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D83A as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D838 as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D836 as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D834 as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D842 as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D798 as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7A6 as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D804 as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D808 as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D806 as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7EC as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7EA as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7E8 as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7E6 as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7FE as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7FC as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7E4 as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D82C as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D82A as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D828 as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D826 as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D824 as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_ABD1207000
0x8008
MB5300
Q5L
ABD1207000
ABD1207000
2006
JDM
Subaru
5EAT TCU
ABD1207000 (06 JDM Legacy GT)
5EAT
M32R
None
384kb
Firmware: ABD1207000 (cal ID MB5300, JDM, 384kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCC4 as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD1A as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD18 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCF4 as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD16 as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCBC as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD14 as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCBE as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCD6 as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCD8 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCDA as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCDC as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD32 as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD12 as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCCA as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCD4 as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCD2 as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD56 as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCCC as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD54 as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCCE as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD52 as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD10 as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD50 as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD0E as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD4E as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD30 as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD0C as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD78 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD76 as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD74 as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD72 as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD70 as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD6E as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD6C as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD7A as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCD0 as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCDE as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD3C as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD40 as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD3E as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD24 as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD22 as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD20 as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD1E as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD36 as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD34 as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD1C as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD64 as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD62 as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD60 as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD5E as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DD5C as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_ACD1207000
0x8008
MB558D01
Q7W
ACD1207000
ACD1207000
2006
JDM
Subaru
5EAT TCU
ACD1207000 (LGT06 JDM)
5EAT
M32R
None
512kb
Firmware: ACD1207000 (cal ID MB558D01, JDM, 512kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
37.6
50.2
62.7
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
37.6
50.2
62.7
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
37.6
50.2
62.7
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
3-4 Up
4-5 Up
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
3-4 Up
4-5 Up
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
4-5 Up
2-1 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
4-5 Up
2-1 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE68 as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEBE as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEBC as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE98 as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEBA as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE60 as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEB8 as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE62 as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE7A as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE7C as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE7E as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE80 as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DED6 as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEB6 as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE6E as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE78 as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE76 as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEFA as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE70 as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEF8 as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE72 as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEF6 as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEB4 as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEF4 as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEB2 as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEF2 as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DED4 as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEB0 as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF1C as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF1A as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF18 as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF16 as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF14 as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF12 as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF10 as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF1E as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE74 as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE82 as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEE0 as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEE4 as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEE2 as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEC8 as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEC6 as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEC4 as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEC2 as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEDA as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DED8 as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEC0 as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF08 as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF06 as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF04 as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF02 as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF00 as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_ADE0236000
0x8008
MB562EH
Q8C
ADE0236000
ADE0236000
Unknown
Unknown
Subaru
5EAT TCU
ADE0236000
5EAT
M32R
None
512kb
Firmware: ADE0236000 (cal ID MB562EH, Unknown, 512kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
31.4
43.9
62.7
69.0
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
31.4
43.9
50.2
62.7
69.0
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
31.4
43.9
50.2
62.7
69.0
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
43.9
50.2
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
31.4
34.5
37.6
40.8
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
22.0
25.1
28.2
31.4
34.5
37.6
40.8
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
3-4 Up
4-5 Up
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
3-4 Up
4-5 Up
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
4-5 Up
2-1 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
4-5 Up
2-1 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
37.6
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
37.6
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
31.4
37.6
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
31.4
43.9
62.7
69.0
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
31.4
43.9
50.2
62.7
69.0
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
31.4
43.9
50.2
62.7
69.0
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
31.4
43.9
62.7
69.0
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
31.4
43.9
50.2
62.7
69.0
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
31.4
43.9
50.2
62.7
69.0
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
37.6
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
37.6
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
31.4
37.6
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
6.3
12.5
18.8
25.1
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
6.3
12.5
18.8
25.1
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
6.3
12.5
18.8
25.1
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
6.3
12.5
18.8
25.1
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC1C as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC72 as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC70 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC4C as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC6E as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC14 as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC6C as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC16 as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC2E as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC30 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC32 as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC34 as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC8A as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC6A as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC22 as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC2C as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC2A as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCAE as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC24 as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCAC as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC26 as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCAA as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC68 as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCA8 as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC66 as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCA6 as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC88 as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC64 as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCD0 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCCE as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCCC as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCCA as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCC8 as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCC6 as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCC4 as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCD2 as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC28 as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC36 as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC94 as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC98 as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC96 as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC7C as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC7A as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC78 as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC76 as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC8E as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC8C as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DC74 as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCBC as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCBA as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCB8 as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCB6 as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DCB4 as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_ACD1A06000
0x8008
MB558D20
Q6E
ACD1A06000
ACD1A06000
2007
JDM
Subaru
5EAT TCU
ACD1A06000 (JDM 2007)
5EAT
M32R
None
512kb
Firmware: ACD1A06000 (cal ID MB558D20, JDM, 512kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
37.6
50.2
62.7
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
37.6
50.2
62.7
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
37.6
50.2
62.7
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
3-4 Up
4-5 Up
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
3-4 Up
4-5 Up
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
4-5 Up
2-1 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
4-5 Up
2-1 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
15.7
18.8
25.1
37.6
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE78 as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DECE as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DECC as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEA8 as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DECA as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE70 as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEC8 as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE72 as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE8A as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE8C as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE8E as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE90 as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEE6 as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEC6 as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE7E as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE88 as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE86 as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF0A as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE80 as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF08 as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE82 as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF06 as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEC4 as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF04 as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEC2 as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF02 as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEE4 as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEC0 as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF2C as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF2A as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF28 as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF26 as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF24 as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF22 as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF20 as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF2E as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE84 as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DE92 as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEF0 as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEF4 as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEF2 as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DED8 as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DED6 as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DED4 as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DED2 as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEEA as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DEE8 as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DED0 as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF18 as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF16 as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF14 as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF12 as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DF10 as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_91A0217300
0x8008
MB4365
Q0A
91A0217300
91A0217300
Unknown
EDM
Subaru
5EAT TCU
91A0217300 (EDM)
5EAT
M32R
None
384kb
Firmware: 91A0217300 (cal ID MB4365, EDM, 384kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D6F4 as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D74A as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D748 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D724 as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D746 as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D6EC as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D744 as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D6EE as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D706 as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D708 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D70A as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D70C as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D762 as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D742 as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D6FA as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D704 as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D702 as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D786 as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D6FC as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D784 as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D6FE as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D782 as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D740 as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D780 as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D73E as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D77E as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D760 as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D73C as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7A8 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7A6 as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7A4 as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7A2 as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7A0 as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D79E as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D79C as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7AA as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D700 as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D70E as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D76C as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D770 as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D76E as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D754 as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D752 as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D750 as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D74E as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D766 as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D764 as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D74C as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D794 as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D792 as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D790 as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D78E as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D78C as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_91A0217400
0x8008
MB4372
Q3M
91A0217400
91A0217400
Unknown
EDM
Subaru
5EAT TCU
91A0217400 (EDM)
5EAT
M32R
None
512kb
Firmware: 91A0217400 (cal ID MB4372, EDM, 512kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D96C as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9C2 as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9C0 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D99C as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9BE as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D964 as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9BC as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D966 as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D97E as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D980 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D982 as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D984 as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9DA as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9BA as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D972 as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D97C as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D97A as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9FE as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D974 as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9FC as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D976 as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9FA as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9B8 as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9F8 as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9B6 as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9F6 as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9D8 as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9B4 as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DA20 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DA1E as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DA1C as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DA1A as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DA18 as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DA16 as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DA14 as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DA22 as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D978 as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D986 as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9E4 as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9E8 as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9E6 as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9CC as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9CA as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9C8 as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9C6 as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9DE as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9DC as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D9C4 as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DA0C as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DA0A as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DA08 as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DA06 as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01DA04 as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_91A1207300
0x8008
MB4364
QZ9
91A1207300
91A1207300
Unknown
EDM
Subaru
5EAT TCU
91A1207300 (EDM)
5EAT
M32R
None
384kb
Firmware: 91A1207300 (cal ID MB4364, EDM, 384kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4D0 as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D526 as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D524 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D500 as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D522 as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4C8 as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D520 as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4CA as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4E2 as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4E4 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4E6 as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4E8 as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D53E as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D51E as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4D6 as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4E0 as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4DE as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D562 as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4D8 as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D560 as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4DA as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D55E as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D51C as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D55C as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D51A as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D55A as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D53C as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D518 as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D584 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D582 as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D580 as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D57E as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D57C as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D57A as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D578 as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D586 as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4DC as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D4EA as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D548 as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D54C as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D54A as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D530 as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D52E as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D52C as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D52A as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D542 as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D540 as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D528 as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D570 as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D56E as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D56C as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D56A as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D568 as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_91FE207100
0x8008
MB436L
Q2Z
91FE207100
91FE207100
2005
USDM
Subaru
5EAT TCU
91FE207100 (USDM Legacy GT 2005)
5EAT
M32R
None
384kb
Firmware: 91FE207100 (cal ID MB436L, USDM, 384kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE64 as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEBA as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEB8 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE94 as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEB6 as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE5C as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEB4 as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE5E as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE76 as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE78 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE7A as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE7C as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CED2 as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEB2 as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE6A as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE74 as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE72 as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEF6 as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE6C as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEF4 as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE6E as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEF2 as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEB0 as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEF0 as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEAE as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEEE as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CED0 as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEAC as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF18 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF16 as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF14 as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF12 as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF10 as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF0E as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF0C as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF1A as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE70 as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CE7E as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEDC as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEE0 as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEDE as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEC4 as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEC2 as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEC0 as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEBE as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CED6 as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CED4 as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEBC as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF04 as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF02 as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CF00 as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEFE as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01CEFC as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_AAD1A06000
0x8008
MB4402
Q0H
AAD1A06000
AAD1A06000
Unknown
JDM
Subaru
5EAT TCU
AAD1A06000 (JDM)
5EAT
M32R
None
512kb
Firmware: AAD1A06000 (cal ID MB4402, JDM, 512kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D774 as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7CA as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7C8 as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7A4 as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7C6 as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D76C as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7C4 as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D76E as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D786 as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D788 as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D78A as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D78C as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7E2 as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7C2 as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D77A as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D784 as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D782 as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D806 as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D77C as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D804 as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D77E as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D802 as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7C0 as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D800 as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7BE as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7FE as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7E0 as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7BC as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D828 as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D826 as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D824 as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D822 as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D820 as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D81E as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D81C as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D82A as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D780 as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D78E as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7EC as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7F0 as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7EE as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7D4 as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7D2 as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7D0 as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7CE as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7E6 as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7E4 as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7CC as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D814 as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D812 as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D810 as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D80E as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D80C as 0x1844. The code is the P-number in hex, so this reads as P1844.
SUBARU_5EAT_8AF0237300
0x8008
MB500NJ0
Q7A
8AF0237300
8AF0237300
2006
USDM
Subaru
5EAT TCU
8AF0237300 (USDM Tribeca 2006)
5EAT
M32R
None
512kb
Firmware: 8AF0237300 (cal ID MB500NJ0, USDM, 512kb)
Subaru 5EAT TCU (5-speed automatic transmission control unit), Mitsubishi/Renesas M32R CPU.
Firmware: 91D1206000 (MB431M / R9H)
Origin: JDM TCU, MCU wa12212953www (M32R, 144-pin, 384KB). Most likely a 2003-2004 JDM Legacy — the market is stated by the person who dumped it, but the exact year/model is NOT confirmed (the unit had no housing or part-number label). Note this is NOT the 05-06 USDM TCU, which uses a different MCU.
Confirmed: table addresses, DTC list, checksum, gear ratios (raw/1024), Confirmed conversions: gear ratios (raw/1024), engine speed (raw/8), temperature (raw-40 degC), vehicle speed (km/h), accelerator pedal angle (raw/255 = 0-100%). Anything left as "raw" has no confirmed conversion. Pressure units are NOT confirmed and are not stored in the ROM. See docs/TECHNICAL-NOTES.md for detail.
REQUIRES RomRaider 1.0.0 or later. The shift schedule and record curves are 3D tables; RomRaider 0.8.2 reports "There was an error loading table" for them.
This is a static file editor only — cannot connect live to the vehicle through RomRaider. Run tools/checksum.py after any edit, before flashing.
SHIFT SCHEDULE GROUP SELECTOR. The transmission carries ten complete shift schedules in each of five groups, and this table decides which GROUP is in use.
Each cell holds a selector code, not a number to scale:
0x81, 0x82, 0x83, 0x85 select schedule groups 2, 3, 4 and 1
0x80, 0x84, 0x8C select group 0
0xFF no override - the current position stands
0x00 entry unused
The firmware reads it as base + index*4 + a sub-index of -3 to +4, so the rows and columns here are the raw storage rather than two named axes; what indexes it is not established.
Worth knowing before changing anything: three firmwares - ACD1207000, ACD1A06000 and ADE0236000 - carry 0x83 where the other thirteen carry 0xFF. Those images force a gear limit where the rest leave the selector alone, so this table really does differ between calibrations and is not boilerplate.
Codes confirmed from the firmware's own comparison chain, which tests exactly 0x80 to 0x85 and 0x8C.
ATF TEMPERATURE BLEND WINDOW. Below the first temperature the transmission uses its cold calibration for solenoid target pressure; above the second it uses the warm one; between them it interpolates linearly between the two.
This is not per-gear or per-solenoid - all seven solenoid channels read the same pair, so widening or narrowing the window changes when every clutch and brake hands over from cold to warm behaviour.
Stock is 15 C to 135 C in every firmware examined. Raising the lower figure keeps cold-ATF pressures in use for longer; lowering the upper figure reaches full warm behaviour sooner.
Confirmed by following all seven solenoid drivers in the decompiled firmware, which interpolate on exactly these two bytes against the ATF reading.
Gear 1 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 2 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 3 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 4 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 5 of 5. Speed-based trim value, indexed by engine speed. The RPM axis scale is code-derived (raw/8), not a guess — see the Info entry.
Gear 1 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 2 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 3 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 4 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 5 of 5. Threshold curve used to detect clutch/converter slip, indexed by engine speed. Data values are a speed in the same internal units the TCU compares against (engine speed x gear ratio).
Gear 1 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 2 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 3 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 4 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 5 of 5. Expected/baseline speed curve — the actual speed signal is compared against this to detect slip. Feeds the X-axis of the Pressure Control B/C and Shift Solenoid Control tables.
Gear 1 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 2 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 3 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 4 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 5 of 5. Pressure/duty correction curve. The X-input is (accelerator pedal angle x 256) minus the Reference Speed Baseline lookup — a difference, so the axis itself is raw even though both operands are now identified. Pedal angle arrives on CAN 0x412 byte 0 as raw 0-255 = 0-100%. Stock values are flat (20) in every gear.
Gear 1 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 2 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 3 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 4 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 5 of 5. Alternate-mode counterpart to Pressure Control B — same role, used under a different operating condition. Stock values are flat (20) in every gear.
Gear 1 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 2 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 3 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 4 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Gear 5 of 5. Shift solenoid control curve, indexed by slip amount. Stock data steps up with gear (6, 6, 6, 10, 10).
Mode 1 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
Mode 2 of 2 (selected by an internal mode flag, not gear). Same slip-amount X-formula as Pressure Control B/C/D (confirmed via decompilation: X = smoothed reference * 256 - Reference Speed Baseline lookup). Stock data is flat (0) in both modes — a real, editable table even though it isn't currently varying.
X-input is CAN ID 0x511 payload byte 4, scaled by a fixed 333/256 (~x1.301) factor before this lookup. CAN 0x511 originates from the VDC/ABS module (bytes 0-1 are steering wheel angle, byte 6 vehicle G-force); byte 4 is not identified in the community CAN decoding. Stock data is flat (0) — real, editable, currently inert.
Gear 1 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 2 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 3 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 4 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
Gear 5 of 5. Signed correction curve against engine speed, selected by a gear-indexed pointer array at 0x117A0. Gear 1 is all zeros (no correction), and the magnitude falls with each higher gear (about -1970 at the top of gear 2 down to -390 in gear 5) — the shape of a shift-shock or torque-phase correction.
Values are genuinely NEGATIVE and stored as signed 16-bit. Real-world units are not confirmed.
This family was only found after correcting the Ghidra M32R processor definition: the pointer array that selects it was unreadable before.
X-input confirmed via decompilation: the same ceiling-clamped CAN ID 0x410-derived reference value already traced in docs/TECHNICAL-NOTES.md (before its x256 scale-up), NOT gear-indexed — a single standalone curve. Stock data is a genuine hump shape: rises from 61 to a peak of 127 around the middle of the axis, then falls back to 0 at the high end — a real, currently-populated tunable curve.
X-input is an internal RAM value (traced back through several conditional assignments in the decompiled code, but not yet to a specific sensor or CAN ID — see docs/TECHNICAL-NOTES.md). Stock data is a real, populated step curve (64 up to 256), not flat/placeholder.
X-input is the same internal signal as the 'Signal FE Response Curve' table, but smoothed through a calibratable first-order filter before this lookup (confirmed via decompilation: the filter target is that byte shifted left 8, i.e. x256). This is a DIFFERENT signal chain from the engine-speed tables, so the RPM scale used on those does NOT apply here — left raw deliberately. Stock data is a real, populated rising curve (200 up to 1189).
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in ATFTempLow drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in IMode drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
18.8
25.1
37.6
50.2
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Kickdown drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Manual drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
56.5
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
31.4
37.6
50.2
56.5
62.7
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
31.4
37.6
43.9
50.2
56.5
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
15.7
18.8
25.1
31.4
37.6
43.9
50.2
56.5
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode3 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Mode6 drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Normal drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
56.5
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
31.4
37.6
50.2
56.5
62.7
69.0
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
31.4
37.6
43.9
50.2
56.5
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
31.4
37.6
43.9
50.2
56.5
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Slope drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 1.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
50.2
62.7
75.3
100.0
1-2 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 2.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
37.6
43.9
50.2
56.5
62.7
69.0
75.3
100.0
1-2 Up
2-3 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 3.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
12.5
18.8
25.1
31.4
37.6
43.9
50.2
56.5
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in Manual 4.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
0.0
6.3
12.5
18.8
25.1
31.4
37.6
43.9
50.2
56.5
62.7
69.0
75.3
87.8
100.0
1-2 Up
2-3 Up
3-4 Up
4-5 Up
2-1 Down
3-2 Down
4-3 Down
5-4 Down
THE SHIFT MAP. All eight shift points in one table, in the form a five-speed automatic is normally calibrated: vehicle speed against accelerator pedal angle, one row per shift event.
Read a cell as: this shift happens at this road speed when the pedal is at this position. Raise a value to delay the shift, lower it to bring the shift on earlier. The upshift rows come first, then the downshifts - the gap between an upshift and its matching downshift is the hysteresis that stops the transmission hunting between two gears, so move the pair together unless you specifically intend to change it.
Every value is vehicle speed in km/h, confirmed against the factory shift chart. The axis is accelerator opening angle, stored as 0-255 for 0-100%.
Cells showing '-' are not editable. They are pedal positions where that particular curve has no vertex in the ROM, so there is no byte to change. Each curve is stored as its own polyline with its own breakpoints; this table lines them up on the shared pedal axis and leaves a gap where a curve does not use a position, rather than inventing a value.
Requires the patched RomRaider in romraider-5eat/. The eight curves sit at eight separate addresses with different lengths, which upstream cannot express as one table - see Table3D.cellIndices.
The schedule used in Sport# drive mode with the lever in P, N, D or Manual 5.
The firmware picks a schedule by index:
drive mode x 50 + shift lever x 10 + gear x 2
Drive modes are Normal, Sport#, Slope, Manual, Kickdown, ATF Temp Low, I-Mode and three not yet identified. Lever positions are D and Manual 5 together, then Manual 4, 3, 2 and 1.
Schedules share curves - a table used in D is often the same object used in Manual 5 - so editing one map can change another. Check the addresses if that matters.
The formula, the drive mode mapping and this naming are rimwall's, from the RomRaider forum thread; FINDINGS section 51 verifies them against the code.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 2-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 3-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 4-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-1. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-2. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
DOWNSHIFT PRESSURE TARGET, 5-3. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
DOWNSHIFT PRESSURE TARGET, 5-4. The pressure commanded during this particular downshift, against vehicle speed.
Pressure is in kPa on the scale confirmed against the factory manual - these maps reach 1372 kPa, which is the manual's figure for full throttle in D.
Raising a value makes this downshift firmer and faster; lowering it makes it softer and slower, at the cost of more clutch slip during the change. Pair it with the ramp step and duration tables in this category, which control how quickly the pressure is allowed to get there.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE RAMP STEP, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
Once the hold period expires, the commanded pressure moves from where it started toward the target by this much. A large value - 32767 appears in the stock calibration for most entries - means effectively no limit, so the pressure goes straight to target. A small value makes the application gradual, which is what the factory calls smooth control.
This is the knob for downshift harshness. Smaller steps are softer and slower.
2-1
3-1
3-2
4-1
4-2
4-3
5-1
5-2
5-3
5-4
DOWNSHIFT PRESSURE HOLD DURATION, one entry per downshift in the order 2-1, 3-1, 3-2, 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4.
How long the pressure is held at its floor before the ramp starts. The value is a count of controller loops. The loop period has NOT been established, so this is left as a raw count rather than converted to milliseconds - a time unit derived from a guessed task rate would look authoritative and be wrong.
Larger values delay the pressure rise, which softens the initial engagement.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
13a
13b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
1a
1b
2a
2b
3a
3b
4a
4b
5a
5b
6a
6b
7a
7b
8a
8b
9a
9b
10a
10b
11a
11b
12a
12b
LINE PRESSURE TARGET. Engine torque in, commanded line pressure out. This is what the pressure control solenoid is driven to achieve.
The torque axis is the engine torque the ECU reports on CAN 0x412, after the TCU has multiplied it by the Torque Converter Slip Pressure Factor, smoothed it, and multiplied it again by the ATF temperature factor. So the axis is effective torque, not raw crank torque.
Both units are confirmed against outside sources rather than inferred. The torque axis comes from the community CAN decoding of 0x412 bytes 3-4. The pressure axis reproduces the two figures in the factory manual's line pressure test: about 524 kPa at low torque against a specified 490 nominal (385-555 band), and 1372 kPa at 400 Nm against a specified 1370 at full throttle in D.
RAISING THESE RAISES CLAMPING FORCE. Firmer, faster shifts and more clutch holding capacity, at the cost of harsher engagement, more pump load and more heat. Several maps exist and the TCU selects between them by operating state - which state picks which map has NOT been established, so change them as a set unless you have logged which one is active.
This table holds ONE of the two quantities in the record array, so it can be shown in real units. Rows are the polyline vertices in order: 1a is the start of segment 1, 1b its end, 2a the start of segment 2, and so on. A segment's end normally equals the next segment's start; where it does not, the curve steps vertically at that point, which is deliberate. The companion table in the same category holds the other quantity, row for row.
P0705 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D778 as 0x0705. The code is the P-number in hex, so this reads as P0705.
P0712 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7CE as 0x0712. The code is the P-number in hex, so this reads as P0712.
P0713 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7CC as 0x0713. The code is the P-number in hex, so this reads as P0713.
P0715 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7A8 as 0x0715. The code is the P-number in hex, so this reads as P0715.
P0719 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7CA as 0x0719. The code is the P-number in hex, so this reads as P0719.
P0720 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D770 as 0x0720. The code is the P-number in hex, so this reads as P0720.
P0724 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7C8 as 0x0724. The code is the P-number in hex, so this reads as P0724.
P0725 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D772 as 0x0725. The code is the P-number in hex, so this reads as P0725.
P0731 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D78A as 0x0731. The code is the P-number in hex, so this reads as P0731.
P0732 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D78C as 0x0732. The code is the P-number in hex, so this reads as P0732.
P0733 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D78E as 0x0733. The code is the P-number in hex, so this reads as P0733.
P0734 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D790 as 0x0734. The code is the P-number in hex, so this reads as P0734.
P0735 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7E6 as 0x0735. The code is the P-number in hex, so this reads as P0735.
P0736 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7C6 as 0x0736. The code is the P-number in hex, so this reads as P0736.
P0741 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D77E as 0x0741. The code is the P-number in hex, so this reads as P0741.
P0743 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D788 as 0x0743. The code is the P-number in hex, so this reads as P0743.
P0748 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D786 as 0x0748. The code is the P-number in hex, so this reads as P0748.
P0751 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D80A as 0x0751. The code is the P-number in hex, so this reads as P0751.
P0753 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D780 as 0x0753. The code is the P-number in hex, so this reads as P0753.
P0756 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D808 as 0x0756. The code is the P-number in hex, so this reads as P0756.
P0758 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D782 as 0x0758. The code is the P-number in hex, so this reads as P0758.
P0761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D806 as 0x0761. The code is the P-number in hex, so this reads as P0761.
P0763 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7C4 as 0x0763. The code is the P-number in hex, so this reads as P0763.
P0766 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D804 as 0x0766. The code is the P-number in hex, so this reads as P0766.
P0768 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7C2 as 0x0768. The code is the P-number in hex, so this reads as P0768.
P0771 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D802 as 0x0771. The code is the P-number in hex, so this reads as P0771.
P0773 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7E4 as 0x0773. The code is the P-number in hex, so this reads as P0773.
P0801 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7C0 as 0x0801. The code is the P-number in hex, so this reads as P0801.
P0817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D82C as 0x0817. The code is the P-number in hex, so this reads as P0817.
P0880 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D82A as 0x0880. The code is the P-number in hex, so this reads as P0880.
P0882 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D828 as 0x0882. The code is the P-number in hex, so this reads as P0882.
P0883 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D826 as 0x0883. The code is the P-number in hex, so this reads as P0883.
P0955 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D824 as 0x0955. The code is the P-number in hex, so this reads as P0955.
P0957 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D822 as 0x0957. The code is the P-number in hex, so this reads as P0957.
P0958 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D820 as 0x0958. The code is the P-number in hex, so this reads as P0958.
P1601 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D82E as 0x1601. The code is the P-number in hex, so this reads as P1601.
P1706 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D784 as 0x1706. The code is the P-number in hex, so this reads as P1706.
P1707 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D792 as 0x1707. The code is the P-number in hex, so this reads as P1707.
P1710 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7F0 as 0x1710. The code is the P-number in hex, so this reads as P1710.
P1716 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7F4 as 0x1716. The code is the P-number in hex, so this reads as P1716.
P1717 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7F2 as 0x1717. The code is the P-number in hex, so this reads as P1717.
P1718 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7D8 as 0x1718. The code is the P-number in hex, so this reads as P1718.
P1760 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7D6 as 0x1760. The code is the P-number in hex, so this reads as P1760.
P1761 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7D4 as 0x1761. The code is the P-number in hex, so this reads as P1761.
P1762 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7D2 as 0x1762. The code is the P-number in hex, so this reads as P1762.
P1798 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7EA as 0x1798. The code is the P-number in hex, so this reads as P1798.
P1799 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7E8 as 0x1799. The code is the P-number in hex, so this reads as P1799.
P1817 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D7D0 as 0x1817. The code is the P-number in hex, so this reads as P1817.
P1840 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D818 as 0x1840. The code is the P-number in hex, so this reads as P1840.
P1841 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D816 as 0x1841. The code is the P-number in hex, so this reads as P1841.
P1842 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D814 as 0x1842. The code is the P-number in hex, so this reads as P1842.
P1843 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D812 as 0x1843. The code is the P-number in hex, so this reads as P1843.
P1844 - stock code word (Enabled) vs a zero word (Disabled-style).
DISABLED writes 0x0000 to this code's slot, making it identical to the many slots the factory leaves empty. This is NOT a proven fault or report disable. The firmware does not test this code word for nonzero before selecting or reporting a fault, so detection, failsafe, persistence and code selection can all remain active, and whether a scan tool still reports the fault with a zero word is unverified. Treat it as an experimental code-word replacement, not a DTC-disable control.
Even in the best case it would suppress the CODE, not the FAULT - whatever limp-home, pressure or shift behaviour the TCU applies when that bit sets will still happen. Useful only after a hardware change that leaves a sensor permanently faulted; a poor idea for silencing a fault you have not diagnosed.
This is inferred from the table layout and confirmed against the firmware's report path (which does not gate on a nonzero word); it is not tested on a vehicle. Note the code you removed before you remove it.
Stored at 0x01D810 as 0x1844. The code is the P-number in hex, so this reads as P1844.