Where are LTFT data stored?

[RustySocket]

I'm trying to understand how long term fuel trims are applied when in OL condition and where the learned data is stored. When looking at LTFT in a log does anyone know which table is storing the data and what breakpoints will cause it to shift from one learned value to the next?


I've found two tables AF learning #1 Airflow Ranges A and AF learning #1 Airflow Ranges B.


The tables contain different breakpoints:


[Table2D]
A B C D E
1.60 5.0 12.0 20.0 60.0


[Table2D]
A B C D E
0.80 3.4 8.5 16.0 45.0


There was some discussion I found on a search of RR forums here regarding these two tables but there was never a consensus of which table actually stored to data that I could find.


Anyone have any information on which table stores the data and how it is applied. Or are there conditions that will cause the learned trims to be pulled from table A vs table B?


The only information I can find is in this thread here:
http://www.ft86club.com/forums/showthread.php?p=1706473

[steve99]

The ltft data is stored in RAM as its can change .and its cleared if you reset or reflash ecu as ecu is reset on flashing the ROM which is actually EEROM.

I dont claim to know how the exact learning occurrs but their are several bands of ltft that are storred related to maf flow rates. As you go through the rpm range maf flow changes and you move through the different maf flow rate bands and you will see the different ltft applied. These values will change as temperature,atmospheric pressure, fuel composition eg ethanol conrent, ect changes.

just note ltft is stored and applied reliative to maf flow rates not rpm or throttle position, its a continuous learning process

ltft is the ecus attempt to correct maf scaling errors and account for temperature air density pressure and fuel changes.

their is a bit more explaination in the MAF Scaling link below

if you use the VGI maf scaling utility it will sort all this out for you

[Wepeel]

I've wondered this and I think I've asked it before on here. The thing that throws me off is I've seen LTFT jump when MAF flow was the same but crossing RPM thresholds. On my previous car (STI) it was all just MAF flow rate based, independent of RPM. On the BRZ it seems it might be a function of more than just that - not sure if it's due to 2 injector sets, but it seems different.

[Kodename47]

Originally Posted by Wepeel

On the BRZ it seems it might be a function of more than just that - not sure if it's due to 2 injector sets, but it seems different.

I think that this might be the case. However I've only played with one set of learning ranges, ECUtek only has one which ties in with Romraider's A so B is new to me.

Someone could always test it out if they have access.

[steve99]

be very difficult to work out unless somone looked at the code.
but maybe the change was due to a new learnt value of ltft being stored rarther than a threshold range being crossed ?

[RustySocket]

Thanks for the responses guys. I guess it doesn't really matter, I'm not a programmer and just looking for the information using a search function was difficult for me. I was happy to be able to find out anything at all. I don't have the background or skillset to take it any further than this.


I'm just trying to learn about the ECU and how all the sensors and tables in the rom interact to make adjustments to fueling in a broader sense. Not that I ever hope to become some great tuner that knows everything there is, but I'd like to understand how to read the datalogs and why the ECU makes the adjustments it does. I certainly understand that there can be multiple data sources being polled and that when looking at a datalog I am only seeing the result of those changes. I'm just trying to understand why to fuel trim changes when it does within OL conditions and what triggers it to happen. Whether it is airflow, rpm, load AF reading, or some combination of all.


One thing is becoming readily apparent ,it is much more complicated than I imagined. There are some incredibly smart people on these forums and I'm not as smart as I thought I was.

[steve99]

Originally Posted by RustySocket

Thanks for the responses guys. I guess it doesn't really matter, I'm not a programmer and just looking for the information using a search function was difficult for me. I was happy to be able to find out anything at all. I don't have the background or skillset to take it any further than this.


I'm just trying to learn about the ECU and how all the sensors and tables in the rom interact to make adjustments to fueling in a broader sense. Not that I ever hope to become some great tuner that knows everything there is, but I'd like to understand how to read the datalogs and why the ECU makes the adjustments it does. I certainly understand that there can be multiple data sources being polled and that when looking at a datalog I am only seeing the result of those changes. I'm just trying to understand why to fuel trim changes when it does within OL conditions and what triggers it to happen. Whether it is airflow, rpm, load AF reading, or some combination of all.


One thing is becoming readily apparent ,it is much more complicated than I imagined. There are some incredibly smart people on these forums and I'm not as smart as I thought I was.

have a look here
http://www.norcalmotorsports.org/use...gGuide-0_5.pdf

the more you look into it the more complex it gets :-) never ending learning curve ignore all the turbo stuff in that guide the brz ecu operates in a similar manner

www.romraider.com also has some good guides

but if you just scaling maf use VGI utility then look at wayno's tune guide for OFT tunes

[RustySocket]

Originally Posted by steve99

have a look here
http://www.norcalmotorsports.org/use...gGuide-0_5.pdf

the more you look into it the more complex it gets :-) never ending learning curve ignore all the turbo stuff in that guide the brz ecu operates in a similar manner

www.romraider.com also has some good guides

but if you just scaling maf use VGI utility then look at wayno's tune guide for OFT tunes

@steve99, thanks. It was @Waynos guides, your helpful links and the gathering of all my logs to fine tune my OFT tune that led me to ask the question. I have been reading everything I can find to learn how this all interacts expecially the guides over on romraider. As always, thanks for sharing information and your helpful responses.

[callisto]

Originally Posted by steve99

be very difficult to work out unless somone looked at the code.
but maybe the change was due to a new learnt value of ltft being stored rarther than a threshold range being crossed ?

I now have almost worked out this answer, and with precisely two results on the forum for "airflow ranges", am documenting what I've found in the only thread that seems relevant:

A/F Learning #1 Airflow Ranges A controls define the stored LTFT (long term fuel trims) boundaries; the table defines buckets A through F by specifying the maximum of buckets A through E. So, table A = buckets { A <= 1.60; B <= 5.00; C <= 12.00; D <= 20.00; E <= 60.00; F > 60.00 } means that MAF 0.4 is bucket A, MAF 10.0 is bucket C, etc.

A/F Learning #1 Airflow Ranges B specified the midpoint of the LTFT learning range within each bucket. This is annoying to explain in words, but easy in math — (learning min = midpoint – (learning max – midpoint)). So, then, given table B = midpoints { A : 0.80, B : 3.40, C : 8.50, D : 16.00, E : 45.00 }, the learning MAF ranges for LTFT buckets are:

{ A: 0.00-1.60; B: 1.80-5.00; C: 5.00-12.00; D: 12.00-20.00; E: 30.00-60.00; F: not defined }

Note the gaps from MAF 1.60-1.80 and from MAF 20.00-30.00. I'd always wondered why the Ranges A/B tables were slightly weird, and that at least answers the outcome of that weirdness. Couldn't say why, though; maybe CL/OL transitions, or who knows what. (There are various conditions that I haven’t listed that will suspend LTFT learning as well, like you must be going at least 3 km/h.)

But the interesting part here is that the learning range for F can't be determined by this logic, because there's no maximum for LTFT bucket F. And so the ECU hard-codes the maximum learning range for F as 200.0 (K00G float @10eddc). Since stock has "MAF Limit (Maximum)" set (elsewhere) to 200.0 and CELs when the sensor reaches MAF >= 272, I know some end up raising the MAF limit or outright replacing it. However, I don't think(?) it's well-known that the ECU stops learning fuel trims at 200 g/s regardless of what MAF Limit (Maximum) is set to. So, duly noted!

For those interested in seeing this in Ghidra, these exact bytes point directly to the AFR learning limit for Bucket F — d2 1e 60 63 f9 26 d2 1e f8 26 f9 81 38 11 70 02 f9 82 31 91 30 01 f8 26 39 11 70 01 f8 91 e0 fc f1 87 60 43 88 04 89 09 e5 08 34 53 89 06 60 63 f8 26 39 11 70 01 f8 90 00 0b f1 8a d2 11 f8 28 — for K00G and V00C, and so presumably everything in between as well. If someone wants to patch a switch into the RomRaider XML to fix this, modifying four bytes — K00G @623a4: 00 10 ed dc — to instead point to the MAF Limit (Maximum) value — K00G @623a4: 00 10 44 3c — would do it. As always, please verify all of these addresses with both competence and a hex editor; if you don't know what you're doing and get this wrong, you'll brick your car, etc.

Logging K00G float 0xFFF8AAD4 and byte 0xFFF8AAE4 should verify all of this; that the learning limit is capping at 200 g/s and that learning stops (AAE4 flips from 1 to 0) at that point. With the above pointer patch in place and a raised MAF Limit (Max), the logging should show learning continuing beyond the prior 200 hard-coded limit. Hopefully, anyways. I don't have anywhere locally that's safe to exceed MAF 200 and my budget doesn't extend to a dyno run right now. Nor do I know if it matters to boosted folks. But: it might, and so I'm sharing now rather than when I finish solving the complete LTFT mystery.

None of this explicitly says "here is where the LTFT values are stored", because my decoding so far shows two arrays of ten values and there's six LTFT buckets; I can't explain why there's two arrays, and I'm about 80/20 certain that I should be pointing to twelve value arrays instead of ten in each them, but which one is the important one? and so on. For anyone following after me, the above locations will put you into the dead center of LTFT calculation to work that out (unless I've updated since I posted this with a reasonable answer!). And that, at the very least, is progress worth noting. As Monty Python once didn’t say: "The thread’s not dead. It's sleeping!"

[callisto]

I missed a paragraph and it’s an important one: LTFT learning occurs for two independent conditions, with two sets of learned values: At PI (port injection) 0%, and at PI <70%. And, there’s a special LTFT learning bucket for PI >=70% that appears to disregard MAF outright. Which should help explain why LTFT can change when MAF doesn’t cross a bucket threshold, but load and rpm *do* cross a PI Ratio Thresholds table boundary to/from 0%.

[tomm.brz]

but no oem tune (and actually virtually no custom.tunes) uses 70% of PI or more

[tomm.brz]

Originally Posted by callisto

I missed a paragraph and it’s an important one: LTFT learning occurs for two independent conditions, with two sets of learned values: At PI (port injection) 0%, and at PI <70%. And, there’s a special LTFT learning bucket for PI >=70% that appears to disregard MAF outright. Which should help explain why LTFT can change when MAF doesn’t cross a bucket threshold, but load and rpm *do* cross a PI Ratio Thresholds table boundary to/from 0%.

also don't know if you are aware, if you put 14.7 in closed loop fueling tables, LTFT gets completely disabled which is nice if you have a good maf scaling
STFT continues to work all the time in closed loop

you can also offset the lambda scaling and put 0.99-0.995 instead of 1 for lambda=1 so the real AFR during closed loop is leaner: it shows 14.7 but real afr is more around 15.5

[callisto]

Originally Posted by tomm.brz

but no oem tune (and actually virtually no custom.tunes) uses 70% of PI or more

Yeah, you’d have to hit 800cc(?) of total fueling with stock direct injectors to force that condition, which seems rather unlikely. I’d still encourage collecting LTFT offset in logs, though; look for bucket 9 and assess PI ratio in those areas. I believe there’s a 100% PI operation mode during various idle phases? I’m collecting logs with stock DI/PI and LTFT retraining post-flash this week and will revisit. (Some of my older logs have bucket 9, but I want controlled data rather than adhoc.)

Originally Posted by tomm.brz

also don't know if you are aware, if you put 14.7 in closed loop fueling tables, LTFT gets completely disabled which is nice if you have a good maf scaling
STFT continues to work all the time in closed loop

There are various direct switches to just turn off either, but I haven’t had cause to pursue that yet. Should I read a thread somewhere about disabling LTFT to learn more?

[tomm.brz]

It s possible to set more than 70% PI if you use port injectors bigger than 450cc, probably even less, could also be that stock 228cc are already enough for NA engine, but would not be smart as DI helps performance immensely.. PI only it knocks like hell and feels sluggish. You can run PI up to 18ms of injection opening time, but DI only for about 6ms

yes you are right about PI though, after a cold start , which is 50/50% with DI stratified (injected during exhaust stroke), fueling goes to 100% PI on idle and throttle release for a bit
Anyway i feel pretty good tuning with ltft completely turned off, STFT reacts already very quick and has plenty of headroom, smoother on transient also this way.. I also disable LTFT on open loop so my LTFT never ever works
People I tune, i keep LTFT activated on closed loop fueling for them as it helps diagnose eventual problems or leaks

i don t know about threads on this topic, i got the info from steve99 who found out that if you put 14.7 on closed loop targets, it forces LTFT to 0 all the time