This topic describes a series of software patches in the stock ECU in order to allow for full time closed loop fueling, regardless of load, rpm, temp. and so on. Obviously it won't run in CL during fuel cut and shorty after starting when the wideband O2 sensor is not ready to start measuring. The benefits to this are:

1. The tuning process is greatly simplified - there won't be a gazillion tables to tune and edit.
2. The ECU will always target a known AFR and will always strive to achieve it with + - 0.2 AFR accuracy. Lean conditions will be compensated for quite well, up to + - 25%.
3. The OBD2 PID "Desired A/F Ratio" will now work all the time, not just during the usual low load-low rpm combo that you might be used to.
4. STFT and LTFT will now be active all the time and can be used directly to make adjustments to the VE table.

Under OEM logic the ECU will target a lambda of 1 + - 6 corrections that I didn't bother to figure out. These corrections can't bring the CL target lambda outside ~0.85 to 1.05, there are 2 limiters in place for this. Outside of CL, the ECU is free to target lambda 1 or richer than that.

There are 7 issues:

1. Raising all the limiters that decide if CL(closed loop) or OL(open loop) should be used. Namely, 4x 2D tables for maximum load vs RPM limiters(the one with a "unk" in its name in VT/ME is still engine load), a 2D TPS vs RPM limiter, a 1D RPM limiter and a few others that do not pose an issue and can be left as is(e.g. misfire counter, timers for CL/OL switch hysterezis, a few others).
2. Disabling the multitude of lambda compensation tables. There are 2 for rpm vs load, 3 for ect vs load, and a bunch more for the other 4 lambda trims I didn't bother to dig up.
3. Re-enabling(or forcing the sole use of) a single rpm vs load trim table which will become the base table for lambda target and disabling the use of 2 out of 3 ect vs load trim tables.
4. Patching the use of a single rpm vs load lambda base table, of 17x24 size.
5. Lowering/raising the CL target lambda limits so that they do not constrain the target lambda any more than the factory O2 can read.
6. (optional) Changing the Y axis(load) of the ect vs load lambda trim table to ect vs iat lambda trim. This is for boosted cars that run a separate charge air temp sensor that indicates high IATs.
7. There are a million RX8 ROMs out there, and chances are you can't just copy and paste one foreign ROM into your ECU. Each invidual ROM family requires a software patch for FTCL(full time closed loop fuelling). Mine is a N3ZHEC, the early european 6 port manual gearbox variant.

About software patching the OEM ECU:

1. This is serious nerd territory but also a good time to pick up on ghidra.
2. Tables are stored as structures, in the shape of table length on X axis, table length on Y axis(if any), address towards X axis, address towards Y axis(if any), address towards Z axis(table data), data type flag(8 bit or 16 bit or 32 bit data), then a scalar for multiplication and a scalar for addition. The last 2 might not be present for some tables, where the Z axis data is used directly.
3. You call a table by feeding it through a function that has as input the X/Y axis, the pointer for the table structure(defined above) and it will return you the Z data * scalar1 + scalar2. For example, if in the ROM the raw data is 50, scalar1 is 0.023 and scalar2 is 23; the function will return 50*0.023+23 = 24.15.
4. Replacing assembler instructions with NOPs at the right time and place will turn off certain unwanted features/corrections.

Suggested fixes:

1. For the 1D RPM and 2D TPS tables you simply set them to unreachable values, e.g. RPM limit of 10000 and a TPS limit of 127%. For the 4 2D limiter tables you will have to change the scaler for each of them, the default value is 0.0039, I use 0.0117 for the A/B/C ones, for the 4th one(with "unk" in its name) the stock scaler is 0.0078, I use 0.0156. This allows you to set a load limit that is so high, it won't ever be reached. Mine are at 300%.
2. and 3 and 4: Disabling 4 out of 6 CL lambda trim variables is done by NOP'ing them out at the time when they are added/subtracted to the CL target. NOTE THAT THESE ADDRESS ARE VALID FOR N3ZHEC calibration (only).

What I call the monster table is a 17x24 huge table of RPM vs Load = CL target lambda table base value. This is the only base table used at all times, and is only modified by the ECT/Load or ECT/IAT enrichment one.
The string at 0x7F32C is:
001100180007F3480007F38C0007F3EC04000000BB09A0273E 1FBE7743FA0000447A000044BB800044FA0000451C4000453B 8000455AC000457A0000458CA000459C400045ABE00045BB80 0045CB200045DAC00045EA600045FA00004604D0003DCCCCCD 3E4ccccd3e99999A3ECCCCCD3F0000003F19999A3F3333333F 4CCCCD3F6666663F8000003F8CCCCD3F99999A3FA666663FB3 33333FC000003FCCCCCD3FD9999A3FE666663FF33333400000 0040066666400CCCCD401333334019999A
which defines the structure of this table as being a 17x24 in size, with X/Y/Z axis address right after the structure, with RPM axis from 500 to 8500 in 500 RPM increments, with Load axis from 10 to 240% (because boosted engines) in 10% increments, with a scalar1 of -0.021, with a scalar2 of 0.156 and a data type of 8 bits unsigned.

5. Raising/lowering CL target lambda ceiling/floor limiters is done by simply editing them in the ROM, addresses are 7016C and 701C8 (in N3ZHEC).



6. First you can decide if you even want any temperature compensation to your base CL target lambda table(the monster one). If you do, define this table. Sits at 70B9C

If you want to use it as is, be my guest. If you want to change the Y axis to IAT then see the last row of the excel screenshot.

7. To find all the required offsets for _your_ individual ROM you need Ghidra, which also happens to be the same tool to edit your ROM, which also happens to be free and quite well documented. As a basic starting point, you have the offsets given in this tutorial and a stock copy of N3ZHEC attached here to build on.

Note the highlighted area:
CL_lambda_target_final = (float)Constrain((CL_lambda_corr_RPMvsLOAD - CL_lambda_corr_ECTvsLOAD(IAT_patched)) + 1.0,0.85,1.05);

The CL_lambda_corr_RPMvsLOAD parameter is the base table, CL_lambda_corr_ECTvsLOAD(IAT_patched) is the temp enrichment, +1 is a constant offset which you don't need to worry about, and 0.85 / 1.05 are the stock CL target limits.

Finally the result is that these 2 tables now control the FTCL lambda target:



The large table - the small one = FTCL AFR target at any time, every time.

Some of the testing runs to validate this train of patches:

This was the very first WOT run with an incomplete patch and absolutely no prior tuning of the VE/MAF, and no previous fuel trims.









102% load and still in CL! This is proof that the tables whose scalar was changed are now working as expected and allowing us to set a maximum load limit CL/OL threshold above 100% which is as high as it goes with OEM programming. This FTCL patch is viable for boosted cars as well.

This about sums it up. I have been on this patch/mod for 3 fuel tanks now with no adverse effects. Will move this into my boosted build when I get that car on the road back again. Should make for a nice power adder now that I no longer have to tune my brains out to get an ideal AFR under any load or temp.

 

Wow, nice project. I thought the point of open loop under heavy load was that the O2 sensor response isn't fast enough to be a reliable control mechanism? It could get into weird injector pulse width oscillations trying to read a laggy signal and potentially cause a lean spike. Is that not the case?
​​​​​​

 

Not the case as far as I have seen.Deff. can't work any worse than OL where literally anything goes, it does 18AFR at WOT? Well, too bad then, ECU won't care to add fuel.

This mod should not be used as an excuse for messing up the car's hardware and then not tuning for it... this is a tool to cut down on the lots of tables you have to edit and to make it easier to tune the VE table via STFTs to get them within + -5% at all times.

 

Wow. Nice work!

 

Awesome work. Any resources you can link that helped you to find/define these tables? I have prior experience in reverse engineering but not with ECU's and ghidra isn't telling me much with my ecu files. Otherwise I'm happy to send you my ECU bin and you can have a play around.

 

Years of compounded weird knowledge have led to this, not one site in particular. You know what they say, if you want it done right, do it yourself.

 

Final result, once the car builds some trims:


This makes me think that building in some rich pockets just before/during the toggling of the intake valves would suit the car well.

 

So i have two rx8 one a 04 automatic and one a 07 manual and i had the 04 sitting in the garage for about 2 weeks and when i went to fire it up it wouldn't start but the atleast it would actually attempt to start but ive fixed that one but now my 07 was running just fine until one day it lost all of its power barely starts and barely idles so i looked under the car and the cat was all red so i put it in the garage and jacked it up to work on the exhaust and the clutch. The first thing i did was took the battery terminals off the battery and then took the cat off and busted it up and since i was waiting on the clutch to get in i decided to put the cat back in and fire it up to see if that fixed the issue of starting and idling. When i went to fire it up the battery was dead so i charged it and when it was fully charged i tried to start it and it wouldn't start. All it sounds like is air rushing out of the exhaust there doesn't seem to be any spark and then exhaust smells just like fuel. Was wondering if its just cause the car sat for a week cause the other one also had an issue starting after 2 weeks. Or if it was because of busting all the stuff out of the exhaust. I'll post all the codes that it had before i took the exhaust out

 

Could be flooded, please check for the deflood procedure, clean off the plugs and try again. It takes longer than you would think. Start your own thread in the new members section please. @Tgoecker

 

Hi ciprian,
Not sure if this serves as useful information to you in any way, but when I was trying to make the rx8 cruise at lean AFRs outside the CL range, I found that the "closed loop additive" table in mazdaedit/versatuner is actually an OPEN loop additive table. I haven't seen anyone else discuss this so hopefully it's new, and it was a way for me to drive near the o2 limit of 1.4 lambda without spoofing the sensor voltages or playing with VE tables as people have in the past.

Whilst this is now moot seeing as you can change the CL limits and achieve the same thing without all the attendant random corrections, it might potentially help with your valve opening lean spikes. When you drive in CL (not OL), but also change the "closed" loop additive table, you'll see that there is no effect on actual AFR but that the STFT changes to account for it. The desired AFR also does not change, which means that the fuel is added much like a 'disturbance' or post error signal in system control. The STFT maxxes out when you plus or minus about 0.2 lambda in the table (which is safe to do generally from loads 0.25 to 0.56). Now, currently you can smooth out lean spikes within CL, but if you wanted to reduce the magnitude of the spikes, you could potentially make use of the additive table to give the commanded fuel a head start on enrichment, knowing ahead of time e.g. what rpm the APV opens. For SSV, where you only know the rpm range but not exact load of activation, the additive might reduce the peaks you currently have during activation (and reduce the required STFT at these places) in trade for extra small dips at loads where the SSV does not activate (and where STFT comes in the opposite way). Instead of the one big peak you currently have, you'd have like one period of a sine wave but of half the magnitude. Just a thought

 

Those 2 tables are no longer used in my FTCL patch, and are not used during OL fueling at all(either in mine or factory logic). OL has completely different tables in another area of the ROM, including rpm/throttle based minimum enrichment. Have not found yet any way to add tip-in enrichment, this would be useful for boosted engines.
The rest of the enrichment you described is what I plan to do - I can aproximate a rpm/load combo where the valves will open and enrich the target at those points. Now since the stock tune doesn't bother with this I presume it doesn't mean much for the engine. I always steer on the OEMs side whenever possible, but I'm not bound by the same requirements as they are.

 

Hmm, coud it be a calibration thing ? Mine is N3ZKEC. I know you're not using the OL tables, but for me the CLA table affects STFT during CL. Only reason I mentioned it, is because I'm not sure how else you'd be able to tune out the spikes if that's the end goal here (and I agree, the spikes don't matter).

You're currently targeting R = x AFR, and get some tracking error. The control doesn't care if you then target R = x + d AFR to try and compensate, there'll still be a spike / error. The valves are introducing a disturbance T, which means the signal is picked up after the controller block, affecting output Y, but ignoring your targeted R.



CL adjusts for this of course (through the error signal, E), but only within the limitations of the controller, which you probably don't want to change in the ROM without affecting response at all loads/rpms. If a disturbance happens at a given (load, rpm), we can counteract it by adding an equal and opposite disturbance, D = -T, at that point. Such an artificial disturbance must not affect the AFR target R, but also be captured in the output Y and therefore seen by our o2 sensor, H.

For me, this is apparently what the CLA table does, but alas, if yours doesn't behave like this, then using it isn't an option.

 

No. Your understanding of the 2 load/rpm lambda trim tables in CL is incomplete.
-> the 2 stock lambda trim tables are used as such:
if (some condition I never figured out)
use table _A
else
use table _B
...
lots of other stufff
...
CL_target_lambda = 1+ table A/B + a bunch of other stuff - a bunch of other other stuff.
​​​​​​The tables are not used anywhere else - that's why I took the liberty of obliterating both of them and replacing them both with just 1 huge rpm/load lambda trim table.

My STFTs are quite all over the place when running FTCL. One second I'm cruising at +1% STFT, then I stab the throttle and get a STFT spike of +12% then the next split second it is back to 0. If I hadn't been listening in to the native CAN messages where the ECU outputs STFT/LTFT I would have never found out, that is just how fast they change. OBD2 loggers won't catch that.

Just the magic the ECU does behind the curtain to keep AFR within the target. I haven't touched the PID controller behind and I dare not - simply because that can literally set a car on fire. Not to say a poorly done FTCL patch is harmless, but at least I understand what I did. Getting the "VE" / engine load compensation table(for fueling only) / fuel scalar table to compensate the bulk of the trims is a lot more useful in this regard.

 

I can confirm the 1st table was in use when I tried to test lean burn (target 1.15 lambda) it would max out at 1.05 and I had to disable CL control.

I'm playing with your .bin file (I'm lucky to have the same ecu cal), and I'm wondering about the second table..
for first table float HiLo I see the 0.85 and 1.05.. for second address its these 2 values :
701C8 -0.03
701CC 0.03
Can you confirm the adress, or does it have some odd scaling ? I tried to look around for similar values with no sucess

 

Of the 1st table I am sure 100%. Of the 2nd not so much. I think it's some form of instant fuel trim constrain in terms of lambda error or something. For the moment I am no longer touching it after reverting to stock.

 

Possibly of interest to the matter at hand is adjusting STFT limits - how much fuel qty, as a %, can the ECU add or subtract.


For the add part - the ecu can add up to 25% in "normal" conditions. I can't figure out what the axis on those tables is, so I'm just gonna presume it's a timer or some iteration counter.
For the subtract part there are 3 paths - by coolant, by rpm/load and by that mysterious ??? axis. The highest value out of the 3 is selected. I think I'm gonna adjust the rpm/load one to not allow leaning out too much under higher loads.
Then the STFT is capped to be inbetween the lower and higher bounds. A great find nonetheless.

 

Recently tuned a greddy boosted renesis with this mod. The entire thing went butter smooth and the entire tune was done in maybe 20 pulls and JUST a quarter of a fuel tank to hit all the relevant load/rpm areas. Some tweaks to maf scaling(about 3% up iirc), some tweaks to inj scaling, a fat rich pocket when SSV opens and otherwise business as usual.

Log STFT/load/rpm, move trims to "VE" table, log again, hitting as many rpm/load cells as possible. At the end stft would be +- 5% under load.

At this point I'd highly point everyone to either move to N3ZHEC as a base ROM and start building off it or morph the mod to their base ROM. Not the slushboxed or 4 port engines though !




I've left it a tad rich under the highest load/rpm combo, for those cases where you floor it from fuel cut straight into boost at 5000+rpm.

 

Thanks for this patch, I went on with it to a identical ROM configuration.

On this Load Limiter Table Scaler setup could You give a bit more detailed instructions:
1) About changing the scaler associated with the Tables-2D RPMvsLOAD A/B/C and Unk. Should I modify the scalers that sit in the ROM at some addresses?
Tables have uint8 values. And I tried to follow the logic which You described for the new 3D Big-AFR-table. Did not manage to understand how 2D table Lookups work in this case and where are these Scalers stored in the ROM.

2) I.e., could you point the addresses to those scalers(A/B/C 0.0039 and Unk 0.0078) for each 2D RPMvsLOAD in the stock-ROM, and would then the desired Table values max to uint8 FF in each cells for 300% with adjusted scalers?

I am asking, as on a couple of test runs Close Loop change to Open Loop(above 6k RPM and 3rd gear WOT). I expect the Load to climb over 100%(my OBD reader value gap at 100% so not sure what is the actual Load).

Editedit: Confirmed these scalars worked, absolute load(Found this parameter in my OBD-reader) a tad above 100%+ and CL at WOT >6k RPM.

Unknown A Table definition start at 0x0006A39C
Scalar#1 address = 0x0006A3A8
Stock value = 3C000000 -> New value 3C 80 80 80

CL Threshold A Table definition start at 0x0006A360
Scalar#1 address = 0x0006A36C
Stock value = 3B800000 -> New value 3c 40 c0 c0

CL Threshold B Table definition start at 0x0006A374
Scalar#1 address = 0x0006A380
Stock value = 3B800000 -> New value 3c 40 c0 c0

CL Threshold C Table definition start at 0x0006A388
Scalar#1 address = 0x0006A394
Stock value = 3B800000 -> New value 3c 40 c0 c0

 

you are very likely looking at engine relative load (absolute load / max load - like defined in ecu map).
you need absolute load (or sometimes called actual load

 

Today I overcame a slight drawback of this full time closed loop mod, namely the rich limit the factory O2 can read. I have been shooting in the dark at this matter for months wondering how to f' solve it, because as is you can't set a closed loop target richer than ~11, 10.98 to be oddly specific.
To save the boring research and development, with a resistor added in the ECU and some rescaling here and there I can now get the wideband o2 to read as rich as 9.96 AFR, which is just about as rich as you could ever possibly want to run. My open loop targets under 190-200% load were in the 10.8 realm, after switching to FTCL I had to bump those up to 11.05 to leave some headroom for adjustments.

The first 2 parameters are grabbed by standard OBD2 queries as a sanity check, the rest are streamed via CAN and via multiple patches. Stock, the AFR would top out at 11.15 and aprox. -1.35mA current. These values should be familiar to anyone that ever tuned an 8.


Some sw patching needed in 2 areas here... nothing too scary


So there you have it... reads as rich as possible AND as stock as possible... because these wb o2 sensors don't die even after 22+ years of service unlike the generic aftermarket stuff that's never as long-lived.