V00C00G 17-20 USDM / JDM hybrid integrated ECU project (v60)

[callisto]

2026-10-14: v60 posted.

UPDATE (2026-10): My car is on V00C-v60 now, after having been through dozens of revisions and written Excel sheets and R workbooks for MAF and AVCS analysis and rescaling, and I've finally torn out the pre-facelift changes I mistakenly integrated into prior versions. I will document below precisely what changes this contains for the curious, and continue studying how things work and documenting everything and slowly fleshing out the XML defs for gen1, and have built an initial automation pipeline for doing so once I've put in the Ghidra effort for each ECU — but school is quite intense this year with a full courseload for sixteen of the next eighteen months, so having reversed all 18EU and many of my 20JP changes inherited into V00C, I think I've probably finished making changes for this project unless/until I discover further unique benefits in U01A that are appropriate to copy into V00C.

When I set out to buy a new 2020 BRZ a few years ago to replace my seal-distraught 2013, the dealer misplaced it on the lot and conveniently found it with a 15% higher price. So I drove five hours away to a dealer that had a new 2019 BRZ at 10% off taking up showroom floor space, and on the drive home through the mountains after midnight as I was putting the car through various rpm/load patterns to get used to the differences and dial it in, I decided that it was now my life goal to upgrade my 2019 BRZ to the 2020 BRZ that I'd wanted. The 2020 was the final model year! And I had a theory that Subaru had done one last tuning pass on it, so that it was effectively a third gen1 OEM tune distinct from the prior B, K, and S eras.

Five (now seven!) years and a million lines of Ghidra discovery later, I have succeeded. I have created V00C-v60, an OEM+ 2020 USDM AK8 upgrade ECU for my 19US AL7 vehicle that incorporates the 2020 JDM closed loop and throttle tip-in behaviors [REVERSAL: but no longer any of the 2018 EDM tune of the direct/port injection system] and the 2022 (!) Subaru smoothed throttle map.

It idles so smoothly that I think it’s stalled, but no, it’s just idling quietly. Sometimes the only engine I can hear is the AOS doing its thing. Still sounds like itself under acceleration, though :)

The goal here was to build an OEM+ ECU; I don't have a dyno and I only have my daily driver BRZ, so I wanted an ECU that uses exclusively OEM maps without any creative invention on my part, that would simply deal with California's 91oct/E10 gas and give me a smoother drive. It does that, in spades, and while I no longer live in Cal91, these changes still improve quality of life regardless of fuel octane.

USDM: I live in the US, so I used a US ECU, because I'd like to know if my evap canister fails someday. It took me two years to learn how CANbus communications work to even diagnose the 0x3D1 / U0155 dilemma preventing use of MY20 V00C on MY17-19 vehicles, and then it was solved within a week. Thank you to the folks who chimed in on the forum thread about that!

JDM: I ran U01A on my car for a couple years, and then it took another year to figure out why it felt different than V00C. Turns out, 'DOM'estic AK8 has some subtle changes to a couple dozen undocumented fueling tables, and some not-so-subtle changes to throttle tip-in, a tweak to MAF correction targets. But it has the K00G-era AVCS tune and no US smog bits, so I didn't want to just run U01A and be done.

REVISION (2026-10): U01A is the post-facelift descendant of K00G, and while it works relatively well on US/CA vehicles, it will erratically underreport MAF due to not knowing about the evap canister integration into the intake, and is lacking the effort spent on reducing emissions that Subaru was forced to invest into in the US. Most, but not all, of the closed loop changes I previously considered to be improvements in U01A versus V00C were in fact simply Subaru treating K00C and K00G as relatively independent forks of each other.

EDM: A couple years ago, when I was looking into the direct/port injection ratio maps, I spot checked each lineage-branch of ECU and found that S20G had a significantly more detailed DI/PI tune that isn't available anywhere else in the world.

REVERSAL (2026-10): However, this is purely to make the pre-facelift 2018 EU intake (K00G->N->Q->S20G) comply with 2019 EU emissions standards, and as such creates a great deal of dramas and trim errors when combined with post-facelift V00C. I ended up retaining nothing from S20G (18EU) except the knowledge I gained along the way, and have removed my custom DI/PI 'reduce port injection when IAM drops' logic as no longer relevant.

REVISION (2026-10): For non-US/CA/EU folks with a post-facelift vehicle, just use U01A; you don't need emissions and so you can benefit directly from 20JP's stock tune without needing to do anything special. Pre-facelift folks, you're already well-covered by OFT and others.

Note that I (still) do not recommend attaching these XML files to the master 'stock ROMs' thread yet - I will post them there when they're finished - especially because I have no idea if the CEL toggles are all correct and for a while that was the highest priority everyone had for them. U0155 is, for obvious reasons, correct in V00C, however :)

If I had a bench test setup, my next project would be to buy an 86GRMN ECU and download it and study the custom intake logic; it should be possible (~a year) to port it forward to V00C. Buying that ECU costs $350 but who knows when I'll have the bench dumping setup built, and I'm having to learn electronics in order to learn how to unbrick ECUs if I want to continue developing custom code logic that goes beyond simple table modifications.

Attached are:

ZA1JV00C00G-v60-bin.zip: This is the 2020 USDM base. It still has all the smog bits enabled, and I patched CANbus id 0x3D7 to be 0x3D1 to work with non-20US facelifts. As far as I know, 3D7 is exclusive to 20US, but sample size n=2. If you get U0155 within 5 minutes of starting vehicle, you probably have a 20US; open it in RomRaider with the XML, flip the U0155 compatibility switch at the end of the list, save, reflash. This also has my (unrelated to U01A) backport of the gen2 throttle in it, which makes the dip invisible during normal city use in exchange for reducing pedal precision when on the track (which I never do); see Requested Torque B to review or revert.

ZA1JV00C00G-v15.xml: This is the RomRaider XML file I'm using with it. I do not guarantee that all tables have been mapped yet, but certainly the vast majority are. I have not verified the CEL disable/enable toggles, which is why they're commented out.

ZA1JU01A-v15.xml, ZA1JS20G-v15.xml: RomRaider XML files for 2020 JDM and 2018-2019 EDM. As above: I do not guarantee that all tables have been mapped yet, and in fact I'm pretty certain I have more work to do to finish that. But it's sufficient to run diffs to see what I've been merging into V00C00G.

logcfg-V00C.zip: Because one tactrix logcfg is never enough. The 'standard' one has the usual things that people expect in tuning. The rest have other, weirder, fancier things, like the memory addresses of the fuel trim and knock correction tables. I could write an entire log file exclusively for showing how the closed-loop process calculates fueling. Someday I'd like to be able to display my learned values with a keypress.

A brief description of the ECUs I now know and love:

20US V00C00G "AK8 H4 Tier3 MT", and 20JP U01A00G "AK8 H4 DOM MT", are the final AK8-generation ECUs here; if there are others, I haven't looked for them yet, but I will certainly get around to that eventually. I will abbreviate them without 00G hereafter. I was right! There was a final tuning pass hiding in the 2020 U01A ECU!

19EU S20G "AL7 H4NA EU 6MT", and 19EU S10C "AL7 H4NA Tier2 6MT", are the 2018-2019 AL7-generation ECUs here; I suspect that S20G was the final EDM software release as, most likely, there's some sort of horsepower price paid for emissions catchup; perhaps someone will collect data on that someday. My new vehicle purchase came with S10C which was issued alongside K10C, N20C in TSB 11-184-18.

16EU K00G "AN5 H4NA EU 6MT" is the well-known base for the OFT tunes, the last 'simple' tune, and is widely understood by the community, and when I was solving the 0x3D1 problem, I had to go all the way back to 13US B00C "AR2 H4NA Tier2 6MT" to prove how rarely they change the one CANbus ID that gave me problems.

Thank you, FT86club.

I am forever, forever grateful to all of the work posted on this forum by everyone else. So many people were here and so many have faded away, and I have a folder with hundreds of printouts of their work that I've been reading through for years. ztan, steve, wayno, compelica, shiv, there are so many names I could list here. If you've ever posted about development in the tuning forum, I appreciate you. The prototype XML files and the debugging and logic and evolution of knowledge about the car is what made this possible.

[callisto]

TLDR, please? (it took three years to write these three sentences)

This V00C work is my effort to make an OEM+ flash that has the best of all three worlds: US evap/smog logic and JP improvements to fueling and throttle logic. (Formerly, also EU direct/port injector logic.)

Relative to the S10C (19US) that my 2019 BRZ came with, U01A (20JP) has a much more precisely dialed-in fueling system with tangential changes to cranking, idle, tip-in, and MAF correction. (Formerly, I thought S20G (18EU) had a much more precisely dialed-in DI/PI system, but it's just emissions-tuned K00G+ and is incompatible with V00C.)

As of v60, all V00C OEM values modified are copied from U01A unmodified, except for a single change to Front Oxygen Sensor Rich Limit lowering it to match the lowest sensor reading on the stock facelift O2 sensor scale (0.750->0.716, or in ratio terms 11.0->10.5), and most importantly, a backported gen2 Subaru throttle map tweaked to gen1's facelift torque curves.

What all does this project incorporate into V00C? (besides years of reading SH-2A assembly code)

Fueling (Tip-In, Closed Loop, Open Loop, Cranking, Idle, MAF Correction):

U01A is so much smoother on my car than either S10C or V00C, both at idle and when accelerating. I ended up reviewing perhaps the entirety of the closed loop, documenting tens of tables and constants that hadn't been surfaced previously, and identifying every difference between U01A and V00C in those codepaths. U01A is running a later version of the main engine code than V00C, and a couple of the changes I identified ends up reducing compensations in various interesting ways that build on the changes in V00C. However, most of them derive from K00G and are straight replicas thereof, and so are reversions or outright incompatible with stable trims if integrated into V00C.

Tip-In: U01A activates enrichment at half of the IPW threshold of K00G/S10C/V00C, now Active Above 1.2ms, below even the forum's OFT recommendation of 1.5ms. Compensation B/C (ECT) expands to a 3D table in the facelift era, with port injection ratio as the new Y-axis, and exclusively in U01A at PI ratio 50%..100% it gradually adds compensation in B (+60..+30% <=0..+50C; 0% >=+60C) and subtracts compensation in C (0% <= +30C; -20..-70% +40..>=60C). I incorporated both of these changes into V00C.

Cranking: U01A seems to use less IPW to start the engine. I noticed zero starting issues from 5C..100C in two years of usage, so I incorporated the Cranking table changes. They've continued to perform well from v21 clear through to v60 with no issues across multiple states and tens of thousands of miles.

MAF Correction: This particular shift in MAF Correction After Start (Neutral, In Gear) was interesting. There are two primary divergences to consider. K00G has an eight-row table, of which idle mode counters 1-2 have a gradient +35-40g/s..+7g/s at <=-10..90C. S20G smooths out the gradient to +32..+4g/s at <=-20..90C; S10C/V00C, to +32..+6g/s at <=-10..90C, with a bump to +40 at -10C; and U01A, to -32..+6g/s at <=-10..90C with no bump. Notably, however, V00C/U01A make two additional changes: they normalize each non-zero row to the same values, and they add a third data row at counter 8, that neither S10C nor S20G have. I considered this for a long while. I ruled out incorporating the values from S20G because I remember seeing in another table somewhere that US/JP have one tenth higher engine load table definitions than EU and so I'd better stick with either U01A or V00C for this, and I decided that since I'd incorporated a great deal of fueling compensations that affect the 'g/s' of the vehicle at the temperatures changed here, that I should use U01A's values rather than V00C's; while they do not 'lessen' the cold idle loudness, the U01A map is a visibly smoothed horizontally variant of the V00C map, which would end up smoothing out fueling shifts and so likely improves engine health / idle / trims logic. I've had this U01A change in place from v21 through v60 with no issues and retained it.

Front O2: At some point I lowered the Front Oxygen Sensor Rich Limit from 0.750 to 0.716, paralleling the O2 scaling table's minimum value; the sensor's CEL limits are defined elsewhere and the engine targets ~0.6 at load/rpm extremes and collecting additional data is of interest to me. I may reverse this in the future; it's easily reversed in RomRaider by anyone as well.

Torque Requested B: Another side project was to smooth out the gen1 throttle map to be less inclined to inject unwanted G forces into long slow curves. I ended up investing thirty pages of spreadsheet calculations and some final hand tuning to backport the gen2 Subaru MY22-25 throttle map, which both smooths out the car's response below 28% throttle to be more chill to drive and also changes gen1's 'driver is responsible for managing pedal position for peak torque, which varies by +/- 0-5% every 200 rpm' approach to a more linear-smoothed 'throttle plate manages peak torque, in response to smooth inputs from driver'; this also happens to make the dip perceptible only through the sound of the engine throttle opening up briefly, and the car now accelerates smoothly for any given pedal input below 28%/100hp and transitions smoothly into 'peak torque' WOT above that, effectively negating the impact of the dip on the vehicle. Track drivers will likely want to reverse this change; daily drivers will probably value this immensely, especially at today's (2026-10-14) fuel prices.

What differences were reviewed but ultimately excluded? (there's still unreviewed differences)

See the historical notes section below, where I detail everything I attempted to include but ultimately rejected. There are so, so many minor differences but at the end of the day I went with only those things I could prove were U01A improvements beyond both K00G and V00C, which was not many things after all.

Which tables specifically are changed from OEM V00C? (as of v21)

In approximately RomRaider order. Punctuation marks: tables I created* for this project, ^on/off switches I created to fix a specific byte or avoid relocating tables:

• ^U0155 fix for 2017-2019 USDM
• Idle Speed Target L
• Cranking Fuel Injector Pulse Width (ECT) B, E, F, I, J
• Tip-in Enrichment Compensation (ECT) B,C
• MAF Correction After Start (Neutral, In Gear)
• Front Oxygen Sensor Rich Limit
• Requested Torque B

Why doesn't this incorporate any of the usual performance tune changes? (such as racing throttle, linear fueling maps, cold idle silencing, and so on)

I used a for-sale tune on my 2013 BRZ and it was critically necessary to get that vehicle to perform well. But when I replaced it with a 2019 and tried to use that same K00G-derived tune, it did not particularly improve my vehicle relative to S10C, and when I went looking for other for-sale tunes, they all either derived from K00G or installed the DRM that prohibits the exact tuning work this community did back in gen1. So I decided to document S10C internally to understand what was so unusual about facelifts, which required learning Ghidra and SuperH both, to see what all was different and whether I could incorporate anything from my purchases into my vehicle without having to downgrade from S10C. Eventually I found V00C and tried to run it, but the U0155 obstacle took me years to diagnose and mitigate, and so in the meantime I started comparing K00G to S10C to V00C, and then added in U01A and S20G and B00C, and have since extended to A01G.

What I suspected, and what I was not entirely correct about, was that the 2020 JDM release had an extra-special ECU. Not to the degree of split-intake like the 2017 GRMN86, but given that Subaru was offering a ten-year engine wash and retrofit and update to the latest bits, it seemed likely that they'd invested some effort into that final year's ECU as well. Yes, they did! 2020 JDM has the best CL and MAF and idle maps of all gen1 OEM ECUs, but 2020 USDM has the only evap/smog logic of the three. So creating the holy trinity of "final release" became my quest. This release is the first step towards that goal, and only around v20 did I finally prove with certainty how to Tactrix log the IAM, LTFT, and FLKC learning table data. After studying that for a couple years, I ultimately ended up removing all 2018 EUDM changes I'd incorporated and many of the 2020 JDM changes that were just K00G in disguise.

Ultimately, this all reflects my aesthetic choices. I'm building an OEM++ vehicle, and facelift-era ECUs are perfectly sufficient to enjoy the car without having to tune it further, but moving up from S10C to either of V00C/U01A demonstrated on my car that OEM+ was possible out of the box; when the hybrid work pays off, I'll have an OEM+ vehicle that is the very best of OEM, and that makes me happy. The last time my mechanic drove my car, he reacted viscerally, positively, to the experience, but was completely unable to explain why it felt so magical to drive. That is my aesthetic goal for this hybrid project. Also, I can say under penalty of perjury that I have gone out of my way to maintain or improve the vehicle's emissions, which I find aesthetically pleasing (yes, I'm weird, but I also have asthma). And now I have a 2019 BRZ with 2020's improvements from US and JP, and with gen2's smoothed throttle, for a total cost of $150 (to replace the ECU I bricked trying to write new code for v45).

I respect that both facelift non-performance work aren't as interesting to the wider tuner community. But there's another reason I'm putting in all this work: to publish RomRaider XML defs for gen1 facelift V00C/U01A, which can now be flashed onto any facelift (thanks to the V00C-U0155 fix switch above), so that XML tuners on facelift vehicles have the option to port their K00G work forward, or to inspect post-facelift tuning changes for possible incorporation into K00G tunes, or to ask questions like "Can I just copy this table or are there new tables waiting in the code?" (which, now, I can answer!), or to suggest new projects like "Can we expand K00G's tables?" (sure, it's simple, I can provide instructions, but it carries a slight risk of bricking). Others who are interested in performance tuning are much more likely to do well with it than I will, so I'll provide the shoulders to stand on and let them excel instead. There aren't many of us XML tuners left at all, but that's fine. Our car is worth it all to me.

What's next for the ECU work? (so many things)

In no particular order, I am interested in starting/finishing/progressing all of these things; a handful are already underway, slowly:

• Releasing RomRaider XMLs and Tactrix logcfgs for every gen1 ECU.
• Writing a templating engine for generating RomRaider XMLs (xaxis, yaxis, sizes) from ECU table memory locations. (in progress)
• Patching RomRaider to support our 2d/3d tables natively to dramatically simplify the XML defs.
• Creating a git repository that contains the table data from all gen1 ECUs for analysis and diffing.
• Documenting the CAN communications routines and how the CAN values are produced. (in progress)
• Finding/Dumping an GRMN86 ECU bin, analyzing/posting the custom intake logic, and integrating it into V00C/U01A. (in progress)
• Finding/Making a MAF sensor map for the gen2 O2 sensor in gen1 facelift intake.

Things I've completed from my todo list as of v60:

• Finding/Making a Port Injection ratio lookup table for IAM compensation to see if it stabilizes at a higher IAM on 91oct. (v22, #4) — not included in v60 anymore, as without the S20G changes it isn't really necessary and added a layer of maintenance complexity I prefer to avoid right now.
• Porting the A01G speed density logic to K00G and to U01A/V00C and then logging its results alongside raw sensor data. — I did consider this, but for naturally-aspirated engines, our MAP sensor is unable to function for speed density for a full half of our torque range, which makes this effectively of no use on unboosted vehicles. Boosted vehicles now come with manufacturer tunes and A01G vehicles can't run newer than B-series ECUs, so I concluded research.
• Releasing a K00G table expansion ECU that lets tuners have more finesse than the stock tables allow. — I decided against this, as maintaining separate XMLs is a nightmare and developing these changes requires flashing K00G onto my 2019 which makes it suck. Also, I bricked an ECU while experimenting with expanded tables for other projects, and while I'm grateful for the understanding of how SH-2A chips handle that event, I'm not prepared to unbrick at this time.
• Comparing 92oct E0 to 92oct E10 fuel and learning more about flexfuel tuning. — Fuel prices are through the roof and the car understands and copes with ethanol shifts so long as I haven't screwed up the fuel trim system with S20G alterations, so I'll leave this for some other year.
• Understanding the 2020 USDM 0x3D7 CAN change. — the HVAC controls in 20US read their Celsius/Fahrenheit setting from the instrument cluster, which was also updated in 20US. Someday I will extract and decode the CCU and perhaps even learn how to reflash mine to Celsius, but at least I do now understand this.
• Creating a hybrid U01A for non-US folks following the logic described above. — MY17-20US are solved, MY17-18 EU folks are stuck on their pre-facelift branch; the rest of the non-US/CA facelift world can just flash U01A directly with no steps or hybrid required.
• Map Q00G and compare it to its predecessor/successor K00G/S20G. — I'll still do this someday, if only to understand where U01A diverged from S20G, but it's no longer a priority.

No longer applicable due to S20G removal as of ~v40, but updated with conclusions:

Port Injection (ratios, thresholds, compensations):

This project began when I became curious what differed between two final non-US releases, S20G (EU) and U01A (JP). For various reasons I'm fascinated by the DI/PI system of this engine, and when I saw how much more detailed and smoothed the S20G map was than any other release worldwide, I started trying to incorporate that into U01A. After U01A v4 I suddenly uncovered the U0155 solution for running V00C on MY19, a much longer-standing goal, and so I tried to incorporate the S20G port injection into V00C. As is usual for V00C versus U01A, it did not go as smoothly - but neither V00C nor U01A were exactly thrilled by this at first, even though both had newer fueling logic than S20G that should have worked well with it. Identifying all of the changes was an adventure; there are certain logic branches that use a 'default' PI ratio of 60% in S20G where in all other ECUs it's 50%, except that V00C has in a specific single routine a more advanced decision tree, of which one leaf parallels S20G, but it took several revisions to pin that down precisely in the XML as table PI Ratio Threshold (Unknown), given that the logic tree is built on a bunch of engine values I don't yet have explanations for.

Unfortunately, around v40-45 or so, I realized that many of the changes I was importing from S20G and U01A were just K00G unmodified values that were reversals of K00C->S10C->V00C changes, since K00G->U01A never had to be tuned for emissions while K00G->S20G was tuned extremely heavily after the Volkswagen scandal. So I unwound those changes gradually and as of v60 nothing is left from S20G in the hybrid, and I've altered the post to reflect that.

Direct Injection (firing angle):

After a couple especially bad rounds of low IAM, I decided to read everything ever posted on the forum about DI/PI; this uncovered a very interesting thread about trying to tune DI/PI for knock prevention rather than for horsepower, which is exactly the sort of thing I'm interested in; three hours of reading, one sleep interval, and one webinar transcript later, I realized that tuning DI/PI in this engine requires tuning not only PI ratios but also the DI firing angles in order to compensate for the heating shifts, found that I hadn't yet fixed the RR def for DI in S20g, and discovered that the PI mixture/charge benefits in S20G are accompanied by DI timing/cooling changes. With those incorporated, DI/PI seems copacetic now. Notably, every other DI table and value that I inspected is unchanged between V00C and U01A, but this specific firing angle change was quite significant and strongly resembles the new shape of the PI map. However, between v21 and v40 or so, I ended up reversing all of this; it turns out that K00G->S20G emissions tuning was so wildly different from K00C->S10C->V00C that I had misunderstood these changes as being portable between them, which they were not.

Closed Loop: U01A alters nearly a quarter of the tables involved in the closed loop fueling system. I ended up incorporating all of their changes in bulk for some time; it's possible to math out how they effect the final fueling, but that's a far more extensive project than trying to import the fueling improvements from U01A into V00C, and given how many of them improved closed loop fueling specifically in maps keyed by PI Ratio, I'd hoped that this ends up combining the smoothness of U01A's fueling with the finesse of S20G's DI/PI. It did not, as I was essentially trying to cross-apply closed loop changes to K00G that had not accounted for emissions changes in V00C, and my trims became unstable.

Open Loop: U01A raises the Minimum Active POL Enrichment to 14.70, versus V00C's 14.41. I waffled on this change a great deal, as I don't yet have the logs proving which is better, but given the car's interdependent CL/OL system and that I had two years of good driving experiences on U01A, I decided to incorporate 14.70 into v21. However, this was later reversed; V00C stock has a working closed loop system and reverting to the K00G open loop threshold of 14.7 isn't necessary and had no useful effects on driveability.

Idle: U01A significantly lowers the idle speed targets in Idle Speed Target L (only) across the board, relative to V00C/S20G (an unusual pairing!), removing altogether the significant bump at -20..+90 and lowering the peak target from 8 to 2 (!) table-wide. I've had this incorporated since v21 but reversed it to V00C stock in v60 after studying the code: it appears to control how rapidly the engine pursues the Idle Speed Target rpm, under specific one-of-three cold idle scenarios, while being the same as U01A when fully warmed up. It doesn't alter the loud cold start idle and U01A has the same table values as K00G, which meant that S20G/V00C improved this — not U01A. Since the post-facelift fueling logic is more complex, I decided it was best to leave this alone; perhaps in a few years, I'll better understand the idle targets process and have documented it out and can make a more reasoned judgement.

AVCS: In the guts of the AVCS code logic, which is so similar intake and exhaust that (irritated perfectionist voice) led to two S10C XML correction releases, there is a single set of constants on the intake side that change. I have approximately identified these as A/B path +advance/-retard learning constants, though investigation will continue since I do not appreciate mysteries. Notably, S20G dials back the intensity of adjustments to a fraction of their original value, and then disables one of the four paths outright. I chose to adopt the S20G lower-intensity AVCS adjustment velocities, though I did not adopt the disabled path but instead used the ratio of A+/- (both present) to calculate the appropriate missing B value. This work is reflected in table AVCS Intake Unknown Adj H, and can be easily reverted by setting all values to their V00C/U01A OEM of +0.500 (all positive numbers as stored, the advance/retard logic handles 'negative' itself). This was all unwound at the same time as the other v40-era reversals; V00C/U01A AVCS works fine and having determined that S20G is a pre-facelift K00G-derivative, better to revert this V00C stock than try to hybridize a K00G tuning with no apparent benefits.

Which tables specifically were changed from OEM V00C? (as of v21, but no longer in v60)

In approximately RomRaider order. Punctuation marks: tables I created* for this project, ^on/off switches I created to fix a specific byte or avoid relocating tables:

• Ignition Timing Compensation Idle Target In Error B (S20G)
• AVCS Intake Unknown Adj* H (S20G)
• CL Fueling Transient Unknown* B, S, W, ZA (U01A)
• Input A Rising Load Activation ECT Load 2, 3, 6, 8, 12, 14 (U01A)
• PI Ratio Thresholds (S20G)
• PI Ratio Threshold (Load, RPM, Unknown) (S20G)
• PI Ratio ECT Compensation (& Load) (S20G)
• Total Injection Ratio Port Warm (S20G)
• ^Total Injection Ratio Port Override (Cold, Hot) (~S20G)
• GDI Firing Angle Cold Idle (S20G)
• ^GDI Firing Angle Override (Low/High / Cold/Hot) (S20G)
• DiPi Fueling ECT Unknown* 1, 2, 3, 4, 7 A/B, 10, 11 A, 14, 15, 16, 18, 23, 28 A (U01A)
• Minimum Active Primary Open Loop Enrichment (S20G)

[callisto]

Here's v21. It took three weeks and a great deal of reading of old forum posts, but I finally pinned down why v15 had such a weak IAM compared to stock U01A/V00C - I had missed the DI table change accompanying the PI table change! - and removed all of the low octane detuning now that it's performing well. Initial results since yesterday show IAM steadily advancing, it's currently at 0.8+ with no drops yet, on the usual Cali 91oct gas. Next on my list is to figure out a logcfg that satisfies all of the fields expected by the maptuning app.

New:

- Copied GDI firing angle (High Cold) table from S20G. I had to read another fifty pages of forum discussions from the gen1 era to uncover the missing realization that direct injection and port injection are tuned in concert by separate tables. Sigh. V00C/U01A have improved the GDI Pressure tables since K00G/S20G, so I left those along, but S20G's direct firing angle table is critical for using S20G's novel port injection ratio table. Also, added RomRaider option switches to make V00C, like S20G, use the High Cold data for all five firing angle tables. (No changes to base timing; that's still V00C/U01A OEM.)

- Table "AVCS Intake Unknown Adj H" created, with values that derive from S20G. Buried in the AVCS intake code is a set of A/B +/- values that control how aggressively the engine's learning logic advances or retards the cams, with seeming ties to the direct/port injection calculations. Compared to every other ECU, the S20G logic is slightly more conservative in advance, and outright disables the B/- path altogether. As V00C has slightly more complex code paths than S20G, but also has the old K00G-era A/B/+/- values, I decided to adopt the more conservative values from S20G except for the B- disable value, which I replaced instead by comparing A+ to A- and then applying that to B+. So, AB+/- 0.5 (K00G, U01A, V00C) becomes A+/- 0.250/0.055 B+/- 0.320/0.070 (S20G-derived).

- Added RomRaider option switch to permit use with pre-2020 USDM, which when enabled changes a specific CAN id from 0x3D7 to 0x3D1, resolving the issue that causes U0155 without having to disable that CEL. The attached -3D1.bin / -3D7.bin now highlight this switch as the only change when compared in RomRaider.

Updated:

- Fuel Injection Ratio ECT Threshold A/B. Imported the remaining known direct/port injection ratio table changes from S20G. I'd previously left out some ECT thresholds work while debugging DI/PI, but now that I have the direct injection issue pinned down, I pulled these in to ensure that the ECU doesn't unintentionally amplify the port injection ratio.

- Ignition Timing Compensation Idle Target In Error Range B. This table has changed drastically since K00G in the facelift era ECUs, and also extended the X axis one step further to +300 RPM of idle speed error, though most of that new column is just zeroes. However, S20G improves on S10C/U01A/V00C, smoothing out the +200 and +300 columns, so I incorporated that here - anything that improves idle in our vehicles is a win.

- CL Fueling Target Compensation A/B/C (defs). V00C has slightly more complex closed loop / engine load compensation logic, and so in order to pin down what changed, I ended up renaming the A/B/C tables so that the A/B tables can be compared to and copied from other ECUs if desired, which lack the (now) C table altogether. Their contents are now unmodified stock V00C, as there's no improvements to bring in from S20G/U01A and clearly V00C was OEM tuned, in particular, in this specific place. Works for me.

Reverted:

- Reset base timing, knock advance, knock correction to V00C OEM; in v15 they were heavily detuned while I investigated DI/PI things.

- Restored MAF, MAP sensor CEL thresholds from V00C; in v15 they had the old more permissive K00G/S20G/U01A values.

Note that this is not a complete description of everything that has changed from V00C OEM to V00C v22 - for that, see #2 above, or use the attached v22 XML defs with RomRaider to inspect and compare against V00C00G.bin (or if you have an EcuTek license, it can open v22 just fine, insofar as I haven't made any new tables or anything, but I can't possibly verify that EcuTek can see every change I've made, so you might want to use RomRaider to identify changes and then EcuTek-or-whatever to validate that you can see them at all).

[callisto]

• Finding/Making a Port Injection ratio lookup table for IAM compensation to see if it stabilizes at a higher IAM on 91oct.

v21 still produces extremely poor results over time on 91oct (learned IAM below 0.6!), though the AFR vs. commanded is basically identical through the entire WOT on every release that uses the JDM fueling logic. I tested with a PI ratio table capped at 30% back around v18 and it appreciated that, and having ruled out everything else, this PI table is just too hot for 91oct. So, here's v22 implementing IAM-adjusted port injection ratio, produced by hex-patching new code into v21.

(This code was present and working perfectly from v21 onwards; however, I removed it in v60 along with the 18EU S20G changes I'd incorporated as probably-unnecessary and especially because maintaining code patches to the ECU is very expensive when unbricking is not possible, so even though it worked great, v60 no longer contains any custom code.)

if value > offset: value = (iam * (value - offset)) + offset; else, value unchanged.

offset = PI Ratio Thresholds (Low) - 10% in S20G, v22
value = Total Warm Injection Ratio lookup - varies by rpm/load, as high as 60% in S20G, v22
iam = 0.7 by default, we're all familiar

example: (iam 0.8 * (60.2% - 10%)) + 10% = (80% of 50.2%) + 10% = (40.2% + 10%) = 50.2%

I used the low threshold as the offset because I wanted to ensure that cells with PI always continue to have PI. I'm modifying only the result of the table lookup before the twenty-odd compensations occur, so that all of the downstream code continues working properly (e.g. overriding DI/PI during cold start). And for the time being I'm simply using a linear map of (iam: 0.0->1.0) -> (pi_ratio: offset->value) to shrink the port injection 'envelope' to fit available gas without reducing the fidelity of the gradient.

After an hour or so of driving with a couple of WOT, it's a little over 0.8 (stable at 0.82 as of Friday night) and advanced itself as high as 0.95 when cruising in sixth gear, but I need to give it some more learning time. For the curious, here's a datazap zoomed into the final WOT; locating IAM drop events and inspect the various PI Ratio fields at those points in time will show the adjustment's effect on PI lookup (example). It still has a lot of learning cycles left to do, but at least that validates the logic.

Decompiled code:

void CALC_dipi_ratio_IAM_degrade_FUN(float value)

{
  ENGINE_dipi_total_injection_ratio_port_result = value;
  if (((0.35 <= value) && (ENGINE_iam[0] < 1.0)) &&
     (ENGINE_dipi_total_injection_ratio_port_result = 0.35, 0.0 < ENGINE_iam[0])) {
    ENGINE_dipi_total_injection_ratio_port_result = (value - 0.35) * ENGINE_iam[0] + 0.35;
  }
  return;
}

Native assembly:

                             //
                             // custom.iam_dipi 
                             // ram:00130000-ram:00130fff
                             //
                             *************************************************************
                             *                            FUNCTION                         
                             *************************************************************
                             void  __stdcall  CALC_dipi_ratio_IAM_degrade_FUN  (float 
             void              <VOID>         <RETURN>
             float             fr0:4          value
             undefined4        fr1:4          offset                                  XREF[1]:     00130002 (W)   
             undefined4        fr2:4          iam                                     XREF[1]:     0013000a (W)   
                             CALC_dipi_ratio_IAM_degrade_FUN                 XREF[2]:     QUERY_dipi_ratio_tables_FUN:0006
                                                                                          QUERY_dipi_ratio_tables_FUN:0006
        00130000 d4  0a           mov.l      @(-> PI_Ratio_Thresholds ,pc ),r4                 = 001118c0
        00130002 f1  48           fmov.s     @r4 => PI_Ratio_Thresholds ,offset
        00130004 f1  05           fcmp/gt    value ,offset
        00130006 89  0c           bt         LAB_00130022
        00130008 d4  09           mov.l      @(-> ENGINE_iam ,pc ),r4                           = fff815cc
        0013000a f2  48           fmov.s     @r4 => ENGINE_iam ,iam                             = ??
        0013000c f3  9d           fldi1      fr3
        0013000e f3  25           fcmp/gt    iam ,fr3
        00130010 8b  07           bf         LAB_00130022
        00130012 f3  8d           fldi0      fr3
        00130014 f2  35           fcmp/gt    fr3 ,iam
        00130016 89  01           bt         LAB_0013001c
        00130018 a0  03           bra        LAB_00130022
        0013001a f0  1c           _fmov      offset ,value
                             LAB_0013001c                                    XREF[1]:     00130016 (j)   
        0013001c f0  11           fsub       offset ,value
        0013001e f0  22           fmul       iam ,value
        00130020 f0  10           fadd       offset ,value
                             LAB_00130022                                    XREF[3]:     00130006 (j) ,  00130010 (j) , 
                                                                                          00130018 (j)   
        00130022 d4  04           mov.l      @(-> ENGINE_dipi_total_injection_ratio_port_res  = fff8a180
        00130024 4f  26           lds.l      @r15 +, pr
        00130026 00  0b           rts
        00130028 f4  0a           _fmov.s    value ,@ r4 => ENGINE_dipi_total_injection_ratio_p  = ??
        0013002a 00  00           align      align(2)
                             PTR_PI_Ratio_Thresholds_0013002c                XREF[1]:     CALC_dipi_ratio_IAM_degrade_FUN:
        0013002c 00  11  18       float[2]   PI_Ratio_Thresholds
                 c0
                             PTR_ENGINE_iam_00130030                         XREF[1]:     CALC_dipi_ratio_IAM_degrade_FUN:
        00130030 ff  f8  15       float[2]   ENGINE_iam                                       = ??
                 cc
                             PTR_ENGINE_dipi_total_injection_ratio_port_res  XREF[1]:     CALC_dipi_ratio_IAM_degrade_FUN:
        00130034 ff  f8  a1       float *    ENGINE_dipi_total_injection_ratio_port_result    = ??
                 80

And the patch at @620fe..62107 that jumps to the new routine:

        000620fe d4  01           mov.l      @(-> CALC_dipi_ratio_IAM_degrade_FUN  ,pc ),r4    = 00130000
        00062100 44  2b           jmp        @r4 => CALC_dipi_ratio_IAM_degrade_FUN
        00062102 00  09           _nop
                             PTR_CALC_dipi_ratio_IAM_degrade_FUN_00062104    XREF[1]:     000620fe (R)   
        00062104 00  13  00       addr       CALC_dipi_ratio_IAM_degrade_FUN
                 00

If this works out long-term I'll find an FFF8 memory hole to put it into for logging, but for now it's stable and behaving appropriately enough, so posting it here (but not updating the main post above yet). Use v21 xml and logcfg above to interact with this, to flip the U0155 switch if needed, etc.

[callisto]

In the months since v22, I've learned just enough about DI/PI that make it clear that my plan to fold in S20G's specialized ratios is not going to work without considerably more awareness of the timing curves, detailed logging of the 0..720° cycle, and so on. I've started a project to forward-port all of the old A01G/B01C-era logging values, but in the meantime, I removed the S20G di/pi work for now as it led to constant IAM instability on Cal 91.

However, I kept the new dipi-decay algorithm work in place, as it parallels how IAM 0.0..1.0 moves the car from Timing Low to Timing High in facelift-era ECUs (see next paragraph) and set it to scale from 0.01% PI (in v32, 0x130038: float 3c 23 d7 0a) at IAM 0.0 to 'the original target PI' at IAM 1.0. Combined with the normal PI table, IAM now stabilizes as intended and from there I was able to start tuning for Cal 91 octane gas.

Since V00C/U01A are facelift-era, they have the newer 4D timing tables (^). With PI now scaling down as IAM drops, I focused on measuring where knock occurred, collecting and analyzing every daily drive using the old ways — I am forever grateful to Kodename for the spreadsheets and to vimsh for mafscaling.jar. And after for a solid month of driving around on Cal 91, it turned out that knock below 3800rpm was pushing IAM so much further down than knock above 3800rpm — which only knocked at positive KCAs and in some areas had reached KCA max — that I ended up incrementally detuning, based on logged knock data from daily driving, every Low timing cell from 0..3600rpm. With that in place, the car no longer knocks at low rpm / low-med load, IAM leveled out at 92% (0.92) rather than at 70% (0.7), and the car's been running on that for several weeks now.

Unfortunately for my Cal 91 efforts, I've moved to Oregon, and so now I'm on Shell 92/E10, which likely means that this is the endpoint of my low octane detuning. I'll still keep an eye on it and if I find knock imbalance on Or 92 in the maps, then fixing that will benefit Cal 91 as well. My main computer is packed so I have an SD full of logs that I will eventually append here — but in the meantime, here's the updated v32 that's been stable and happy for general daily use. The dip doesn't feel like a dip anymore; it just feels like you go from 'efficiency' range <3800 to 'G-forces, actives' range >3800. And it will still auto-adapt all the way back to factory timing max + KCA max if your gas is good enough. See end of post for the map change.

For anyone who wants to pick this up and work on detuning further, take detailed logs, identify knock events at KCA <= 0 that resulted in an FLKC drop, and then incrementally detune only those knock events with the lowest IAM of the logs. Remember that you're detuning in Base Timing A2 at IAM 0.0; so if you have a very small FLKC -1.05 knock at IAM 0.7, applying -1.05 to Base Timing A2 is only going to apply -0.32 at IAM 0.7 (your IAM is 30% below max, so your A2 Low change is only 30% applied). Or: I did at one point consider detuning Base Timing A2 (Low) to all cells -20.0 and then seeing what IAM the car levels out at. Or: The incremental method, but with live-patching of the A2 table and a dyno; I don't have those things.

The prior ECU defs and logcfg XMLs are still correct; someday I'll have a big logcfg update for S/U/V, but not today. As of this release, I have neither issues nor reservations to report, and I think it's fine to install this on any MY19-20 USDM (with the usual reminder to toggle the U0155 switch in RomRaider if you see permanent code U0155 after flashing). I'll update the main post above to reflect this update over time, once I have access to my notes again.

(^) Essentially, the K00G-era lookup in Base Timing A is replaced by a pair of {load, rpm} lookups into Base Timing A1 (High) and Base Timing A2 (Low); and then it interpolates the final timing advance from Low..High based on IAM. If your IAM is 0.7, you'll get (70% of High + 30% of Low); if your IAM is 1.0, you'll get (100% of High + 0% of Low), and so on. This is just the same interpolation we're all used to with 3D tables already, but I haven't found a table editor tool that can cope with that extra layer of interpolation, so you either have to be good at looking at a RomRaider changes chart and then multiplying by (for example) 0.7, or you'll end up making a spreadsheet so you can modify a 'target IAM' cell like I did. If I could write Java, I'd patch RomRaider or mafscaling; perhaps someday. (^^)

(^^) Or: For anyone who's played 5D Chess With Multiverse Time Travel, A1 High and A2 Low are just two timeline branches of the chessboard where you either advanced the queen "not at all" or "all the way to the other side of the board", and the IAM interpolation just tells you how far the queen ends up advancing. :)


Base Timing A2 (Low, IAM=0.0) map change, showing the timing changes I accumulated. The 4000..6000 @ 0.15-0.20 changes are estimated to be necessary, based on how things went from 2800-3600 @ 0.15-0.20; at IAM 0.92, that's a whole -0.11 less advance in v32 versus stock in that region. If I had more time on Cal 91 I'd probably end up finding a dyno to reevaluate that. (And, no, I have no idea why RomRaider is in Comic Sans.)

[callisto]

• Comparing 92oct E0 to 92oct E10 fuel and learning more about flexfuel tuning.

https://datazap.me/u/callisto/v00c-v...zoom=4220-4289

In the process of rediscovering the old A-era fueling parameters, I ended up tracing the entire fueling algorithm (as part of an exercise in getting my setup working on my laptop during my move). I've been studying the usual flexfuel solutions for a few years because, as part of dealing with Cal91 E10 versus the car's clear preference for 93 E0, it seemed worth understanding.

It still does, but I've made an interesting point of progress: at the end of the 'base' fueling calculations, in between deciding 'X fuel is required' with all the compensations:

_megacalc_one = ENGINE_map_a308_clftu_K-Y_ZA-ZF_ZJ_ZK_iarlael_1-14 + FLOAT_fff8ac84 + FLOAT_fff8aaf8 + FLOAT_fff8ab00 + FLOAT_fff8aba8 + CALC_dipi_fueling_1-9_adj + 1.0 + DAT_fff8a2b4 + FLOAT_fff8a2d4 + _ect_ratio + (FLOAT_fff8ab0c - FLOAT_fff8ab30) + FLOAT_fff8ac68 + fVar4; fVar1_two = _megacalc_one * FLOAT_fff8a0c4;

(For whatever reason, this step only uses closed loop tables #11-38 plus di/pi compensation fueling tables #1-9. A couple of them changed between S10C and V00C/U01A, so I ended up writing an absolutely litany of table defs for them, simply to keep track. Some have A/B or A/B/C or A/Bx1/2 variants, and I didn't even bother documenting another couple tens of them that have noop values or effects. The work never ends.)

Anyways, before splitting it up between DI/PI, there's a single short calculation routine that allows for easy injection of a 'X fuel is required' scaling factor to the base fuel quantity before the DI/PI divvying up occurs. I'm on E10 and have generally been seeing around +5% LTFT, which lines up with what I'd expect from the lambda shift from E0 to E10 given my somewhat recent knowledge about this all:

(9.00 * E%) + (14.7 * 1-E%) = (9 * .1) + (14.7 * .9) = 14.13 / 14.7 = 0.961 lambda ^ -1 = +4.06%

So I decided to patch in the ability to modify the base fueling result with an ethanol scaling factor of sorts. Since the engine seeks to center around lambda 1.000 (which most logcfgs will represent in terms of 1.0=AFR 14.7 for E0 gasoline, rather than for 1.0=AFR 14.13 for E10), and my logs are showing near-perfect mirroring of AFR Actual and AFR Commanded during acceleration, I don't want to mess with the sensor scalings. They're already working, and if I leave it alone and do nothing, it's perfectly fine with stable trims. I don't have to do any of this at all, if I'm satisfied with just letting it work without trying to understand it better.

Tonight's first test run with the new code confirmed that I'm patching in at the right place to have the effect I desired. I don't have a WOT log yet because people were trying to sleep, but certainly my long-standing positive few percent positive (or zero) fuel trims are now a few percent zero (or negative) fuel trims. Excellent. Didn't have to mess with sensor scaling or fueling tables, and the factor is conveyed in a variable that has no other effects beyond this specific calculation — unlike, as far as I can tell, every other existing pathway that might apply.

I suspect once I give this time to bake for another month, I'll see the usual pattern of LTFTs, except now shifted by -4% — but I confirmed my understanding of the fueling systems enough to commit a long-standing LTFT adjustment to the ECU without having to muck with the injector scalings, the sensor scalings, the closed/open fueling tables, all of that — and the good data for total fueling port/direct in the datazep logs bodes well for the recovered fueling logparams being good results. And it only took a few weeks of study. Always glad when people ask interesting questions and now I'll be able to get those A logparams ported forwarded to V (and K!).

Before:

void DiPi_Fueling_FUN_00060ee8(void) {
  if ((U0155_BOOL_fff8c30c) && (SBYTE_fff8c30b != 0)) {
    fVar1 = divide_except_by_zero((float)(int)SBYTE_fff8c30b,100.0);
    FLOAT_fff8a0c4 = bound_value(fVar1 + 1.0,1.0,1.2);
  }
  else {
    FLOAT_fff8a0c4 = 1.0;
  }
}

After:

void DiPi_Fueling_FUN_override_60ee8_to_130058(void) {
  if ((U0155_BOOL_fff8c30c) && (SBYTE_fff8c30b != 0)) {
    fVar1 = divide_except_by_zero((float)(int)SBYTE_fff8c30b,100.0);
    FLOAT_fff8a0c4 = bound_value((fVar1 + 1.0) * 1.0405828,1.0,1.2);
  }
  else {
    FLOAT_fff8a0c4 = 1.0405828;
  }
}

Before (raw assembly):

                         *******************************************************
                         *                      FUNCTION                       *
                         *******************************************************
                         undefined __stdcall DiPi_Fueling_FUN_00060ee8(void)
           undefined       <UNASSIGNED> <RETURN>
           undefined4      Stack[-0x4]  local_4                            XREF[2]:   00060ee8(*), 
                                                                                      00060f24(*)  
                         DiPi_Fueling_FUN_00060ee8                 XREF[1]:   DiPi_Fueling_FUN_00060eb8:00
     00060ee8   4f 22           sts.l        pr,@-r15=>local_4
     00060eea   d6 7e           mov.l        @(PTR_SBYTE_000610e4,pc),r6                = fff8c30b
     00060eec   66 60           mov.b        @r6=>SBYTE_fff8c30b,r6                     = ??
     00060eee   d2 7e           mov.l        @(->U0155_BOOL_fff8c30c,pc),r2             = fff8c30c
     00060ef0   60 20           mov.b          @R2=>U0155_BOOL_fff8c30c,r0                = ??
     00060ef2   88 01           cmp/eq       0x1,r0
     00060ef4   8b 13           bf           LAB_00060f1e
     00060ef6   26 68           tst          r6,r6
     00060ef8   89 11           bt           LAB_00060f1e
     00060efa   46 5a           lds          r6,fpul
     00060efc   f4 2d           float        fpul,fr4
     00060efe   02 10 25 14     movi20       #divide_except_by_zero,r2
     00060f02   c7 7a           mova         @(FLOAT_000610ec,pc),r0                    = 100.0
     00060f04   42 0b           jsr            @R2=>divide_except_by_zero                 float divide_except_by_zero(
     00060f06   f5 08           _fmov.s      @r0=>FLOAT_000610ec,fr5                    = 100.0
     00060f08   f5 9d           fldi1        fr5
     00060f0a   f0 50           fadd         fr5,fr0
     00060f0c   f4 0c           fmov         fr0,fr4
     00060f0e   02 10 24 2c     movi20       #bound_value,r2
     00060f12   c7 77           mova         @(FLOAT_000610f0,pc),r0                    = 1.2
     00060f14   42 0b           jsr            @R2=>bound_value                           float bound_value(float inpu
     00060f16   f6 08           _fmov.s      @r0=>FLOAT_000610f0,fr6                    = 1.2
     00060f18   d2 6f           mov.l        @(PTR_FLOAT_000610d8,pc),r2                = fff8a0c4
     00060f1a   a0 03           bra          LAB_00060f24
     00060f1c   f2 0a           _fmov.s      fr0   @R2=>FLOAT_fff8a0c4                    = ??
                         LAB_00060f1e                              XREF[2]:   00060ef4(j), 00060ef8(j)  
     00060f1e   f5 9d           fldi1        fr5
     00060f20   d2 6d           mov.l        @(PTR_FLOAT_000610d8,pc),r2                = fff8a0c4
     00060f22   f2 5a           fmov.s       fr5   @R2=>FLOAT_fff8a0c4                    = ??
                         LAB_00060f24                              XREF[1]:   00060f1a(j)  
     00060f24   4f 26           lds.l        @r15=>local_4+,pr
     00060f26   00 6b           rts/n

After (raw assembly):

                         *******************************************************
                         *                      FUNCTION                       *
                         *******************************************************
                         void __stdcall DiPi_Fueling_FUN_override_60ee8_to
           void            <VOID>       <RETURN>
                         DiPi_Fueling_FUN_override_60ee8_to_130058 XREF[1]:   DiPi_Fueling_FUN_override_60
     00130058   4f 22           sts.l        pr,@-r15
     0013005a   d6 12           mov.l        @(PTR_SBYTE_001300a4,pc),r6                = fff8c30b
     0013005c   66 60           mov.b        @r6=>SBYTE_fff8c30b,r6                     = ??
     0013005e   d2 12           mov.l        @(->U0155_BOOL_fff8c30c,pc),r2             = fff8c30c
     00130060   60 20           mov.b          @R2=>U0155_BOOL_fff8c30c,r0                = ??
     00130062   88 01           cmp/eq       0x1,r0
     00130064   8b 17           bf           LAB_00130096
     00130066   26 68           tst          r6,r6
     00130068   89 15           bt           LAB_00130096
     0013006a   46 5a           lds          r6,fpul
     0013006c   f4 2d           float        fpul,fr4
     0013006e   02 10 25 14     movi20       #divide_except_by_zero,r2
     00130072   c7 0e           mova         @(FLOAT_001300ac,pc),r0                    = 100.0
     00130074   42 0b           jsr            @R2=>divide_except_by_zero                 float divide_except_by_zero(
     00130076   f5 08           _fmov.s      @r0=>FLOAT_001300ac,fr5                    = 100.0
     00130078   f5 9d           fldi1        fr5
     0013007a   f0 50           fadd         fr5,fr0
     0013007c   f4 0c           fmov         fr0,fr4
     0013007e   c7 0d           mova         @(FLOAT_001300b4,pc),r0                    = 1.0405828
     00130080   f5 08           fmov.s       @r0=>FLOAT_001300b4,fr5                    = 1.0405828
     00130082   f4 52           fmul         fr5,fr4
     00130084   f5 9d           fldi1        fr5
     00130086   02 10 24 2c     movi20       #bound_value,r2
     0013008a   c7 09           mova         @(FLOAT_001300b0,pc),r0                    = 1.2
     0013008c   42 0b           jsr            @R2=>bound_value                           float bound_value(float inpu
     0013008e   f6 08           _fmov.s      @r0=>FLOAT_001300b0,fr6                    = 1.2
     00130090   d2 09           mov.l        @(PTR_FLOAT_001300b8,pc),r2                = fff8a0c4
     00130092   a0 04           bra          LAB_0013009e
     00130094   f2 0a           _fmov.s      fr0   @R2=>FLOAT_fff8a0c4                    = ??
                         LAB_00130096                              XREF[2]:   00130064(j), 00130068(j)  
     00130096   c7 07           mova         @(FLOAT_001300b4,pc),r0                    = 1.0405828
     00130098   f5 08           fmov.s       @r0,fr5
     0013009a   d2 07           mov.l        @(PTR_FLOAT_001300b8,pc),r2                = fff8a0c4
     0013009c   f2 5a           fmov.s       fr5   @R2=>FLOAT_fff8a0c4                    = ??
                         LAB_0013009e                              XREF[1]:   DiPi_Fueling_FUN_override_60
     0013009e   4f 26           lds.l        @r15+,pr
     001300a0   00 6b           rts/n
     001300a2   00 00           align        align(2)
                         PTR_SBYTE_001300a4                        XREF[1]:   DiPi_Fueling_FUN_override_60
     001300a4   ff f8 c3 0b     addr         SBYTE_fff8c30b                             = ??
                         PTR_U0155_BOOL_fff8c30c_001300a8          XREF[1]:   DiPi_Fueling_FUN_override_60
     001300a8   ff f8 c3 0c     addr         U0155_BOOL_fff8c30c                        = ??
                         FLOAT_001300ac                            XREF[2]:   DiPi_Fueling_FUN_override_60
                                                                               DiPi_Fueling_FUN_override_60
     001300ac   42 c8 00 00     float        100.0
                         FLOAT_001300b0                            XREF[2]:   DiPi_Fueling_FUN_override_60
                                                                               DiPi_Fueling_FUN_override_60
     001300b0   3f 99 99 9a     float        1.2
                         FLOAT_001300b4                            XREF[3]:   DiPi_Fueling_FUN_override_60
                                                                               DiPi_Fueling_FUN_override_60
                                                                               DiPi_Fueling_FUN_override_60
     001300b4   3f 85 31 d1     float        1.0405828
                         PTR_FLOAT_001300b8                        XREF[2]:   DiPi_Fueling_FUN_override_60
                                                                               0013009a(R)  
     001300b8   ff f8 a0 c4     addr         FLOAT_fff8a0c4                             = ??

ps. I assume this is already possible with Ecutek and flexfuel kits in various ways, but I'm not planning to do E85, so in the short-term this is as much academic as anything else. But, progress is progress.

[callisto]

While studying AVCS and LIVC, I finally realized a meaningful effect of one of the major AVCS changes in post-K00G, both in U01A and in V00C: a significant amount of valve overlap was removed at all load levels around 5000rpm (sloped by +/-600rpm) — and a slight amount of valve overlap was removed at 2000rpm / load 0.80-0.85. This is, apparently, why the Y-axis was shifted to include new entries for { 4700, 4900, 5000 }: to permit more granular reduction in overlap than simple linear interpolation allowed.

(For the curious, the new less-overlap AVCS tables can be copied to K00G-era by simply discarding the final three rows of the new tables — though of course, I have no idea if this is a good idea or not!)

I linear-interpolated the K00G tables into the V00C axes in order to inspect things before/after without drama. No luck there!

Turns out the Intake AVCS tables use byte storage while the Exhaust AVCS tables use ushort, so the '.5' decimals created by a proper linear interpolation of K00G to the new axes can't be saved because they're not on an integer boundary. I don't expect anyone to actually load the U/V axes into K00G without also loading the U/V tables, but duly noted. Fortunately, interpolating K00G stock at 40:60 ratio rather than 50:50 results in whole integers in every cell, so I'll include that as a bonus at the end in case someone somehow finds use for it.

Anyways, I've attached the before/after tables of K00G-stock (interpolated), of U01A/V00C-stock, of the differences; and, using Kodename's worksheets (my eternal thanks) of the raw and >1mm overlap impact of these changes.

I'm not actually sure why 5000rpm is a threshold here, though. The K00G PI kicking in from 4800-5200 at load 0.9+ is, in V00C, PI always being on at load 0.9+ with some nuance in how much that's absent from K00G — but these overlap changes affect all load points, including the 0% PI range from 0.15-0.9. Hmm.

I've read hundreds of pages of forum threads about AVCS across several forums, but I honestly don't feel like I understand yet why they made this change. I still hear the usual cylinder noises in S/U/V at 4500-5000 rpm that are familiar to K/OFT users, and given the load levels, it's clearly not about DI/PI. But my early work with another Kodename sheet (DI Calc) suggests an unproven theory, which I will probably explain poorly.

This band that's being modified is around 5000 rpm, where — if I remember correctly from years of forums reading — the DI system begins injecting fuel before the exhaust has closed. In K00G, there's a sharp boost out of the dip to peak at 4400rpm / 66° overlap (41° at 1.0mm) and then the overlap gradually fades to 0° / 6725rpm followed by -4° / 6800rpm. In V00C, that boost does not peak so simply, with the differences map showing anywhere from -5°, to -40° (at 4900rpm/0.8load), less overlap per cell changed. In both cases, by 5600rpm both K and U/V are behaving the same again, with the SOI advanced perhaps 30° ahead of exhaust close at first (and then the gap closes by redline). So.. hm.

Digging around further, I notice that in one FA24 discussion, KillerB talks about how an oil pressure drop around 5000rpm is normal as the AVCS system is making shifts around that point. And since the redline isn't much different between FA20 and FA24, I imagine it's happening around that same point in FA20D, too. And, so, my current working theory:

The massive AVCS spike pre-facelift just after the dip at 4400rpm towards redline could be dropping oil pressure at a particularly bad time for the engine, resulting in an oil starvation / rod knock event.

What I don't know, yet, is how much oil pressure is redirected 'from' the main engine 'to' the AVCS valves to make this happen. If one goes from 4000/0.9 to 4400/0.95 to 4800/1.0, the AVCS in K00G is theoretically asked to use oil pressure to swing 44° of AVCS (14° of Intake and 30° of Exhaust) — but in U01A/V00C, there's only 14° of AVCS movement requested (all Intake, no Exhaust). And as an interesting side note, OFT only swings 8° of AVCS (5° of Intake and 3° of Exhaust), perhaps as a side effect of maxing everything out and leaving it there.

So I suppose my next task would be to log AVCS activity and various oil pressure locations, in order to assess precisely how much oil pressure these AVCS shifts are costing in oil pressure from the rest of the engine. But I am not set up with the hardware to do that right now. Perhaps someday!

avcs-K00G-left-V00C-right.png: OEM tables for AVCS intake/exhaust, K00G left (rescaled for comparison), V00C right (differences as shown).

avcs-overlap-K00G-vs-V00C: Kodename's overlap calculator; K00G left (rescaled), V00C middle (no notes), overlap changes right (from K00G to V00C); raw overlap figures (top), >1.0mm overlap figures (bottom); color scale blue-green-yellow-red (least to most significant cells).

(Sorry for the low quality images, but after so, so many posts with dead image hyperlinks, better an annoying image than none at all. At least they're not Comic Sans this time.)

(I haven't looked into the overlap change at 2000 / 0.80-0.85, but I suspect it's more likely knock reduction than anything else. Though — it does smooth out an Exhaust AVCS transition that was pushing +30° over 400rpm, which I don't think occurs anywhere else in the entire table. Hmm. Maybe I'll understand better next year.)

[Compelica]

Originally Posted by callisto

The massive AVCS spike pre-facelift just after the dip at 4400rpm towards redline could be dropping oil pressure at a particularly bad time for the engine, resulting in an oil starvation / rod knock event.

Sounds plausible - would a pressure drop like that be visible from gauges and logs?

Can't recall but have read somewhere in the forums that the stock oil pump provides more than enough pressure to the point that a good amount actually gets bypassed at high RPMs.

[callisto]

v60 is published, and may end up being the conclusion of my hybrid efforts. As revised heavily above now notes in detail, I've ended up removing all MY18 EUDM / S20G changes from the hybrid and a good chunk of MY20 JDM / U01A changes as well — changes that were, in fact, either region-specific emissions changes to old-intake S20G that weren't compatible with new-intake, or stock K00G values unchanged in U01A that were changed as part of US/CA emissions tuning in S10C/V00C. This one also incorporates my gen2 throttle smoothing work — it's like driving a car without a dip when driving mpg-ly rather than performance-ly. If I make significant changes that deserve another comment in the future, I'll do so, but I'm content with the outcome of 20US + the best of 20JP + the throttle of 22US on my 19US as of today (2026-10-14).