[MidnightTuning]

Hey All,

I had been thinking, one feature I have always found annoying considering its missing is Long Term Fuel Trimming.
This is common on a lot of OEM platforms and is really useful when you want to learn a fueling correction and have it apply in Realtime without having a laptop connected.

Yes I'm aware that you can just let the autotune feature correct the VE table for you, but there are plenty of downsides to that:
-Its a paid feature of TunerStudio
-Requires the laptop to always be connected (Not handy if your laptop / connection is prone to dropping out)

I've started on implementing this myself via the Arduino IDE and corrections.cpp but its safe to say my C experience is lacking and getting my head around the current code base has been somewhat challenging, despite coming from a background of OEM ecu reverse engineering.

Has anyone else ever wanted this or tried working on it? Would be keen to hear any ideas. My version so far is very basic; a set of RPM and MAP ranges with a stored correction for each and the system only updates the values when the current "Short Term" Oxygen correction exceeds a given range.

Cheers
-Rob

[PSIG]

I had been thinking, one feature I have always found annoying considering its missing is Long Term Fuel Trimming.

Hey, Rob - there are multiple versions of long-term trims used in various systems for different reasons. Please define your version of "Long Term Fuel Trimming".

[MidnightTuning]

Hey, Rob - there are multiple versions of long-term trims used in various systems for different reasons. Please define your version of "Long Term Fuel Trimming".

Hey PSIG,

Sorry, by Long Term Fuel Trimming, I mean a system where the current fueling error observed in the short term fuel trimming (Equivalent to the current logic already present for the o2 sensor in Speeduino) is saved to a Load over RPM table in non-volatile memory and applied as a correction to fueling.

What this effectively does is allows the Speeduino to keep a record of the fueling error it has seen in the past for a given RPM and Load and preemptively apply a correction to account for it. This is the general idea of the system used on a range of OEM platforms.

One way of implementing this (And this is the way I have been experimenting with) is by defining an allowed error range of the Short Term Fuel Trimming / current o2 logic, and when the amount of Short Term Fuel Trimming correction being applied exceeds this range, the corresponding Load / RPM cell in the LTFT table is either incremented by one or decremented by one, then that correction applied as a fueling correction.

Over time with this setup, the Speeduino would learn a long term correction that needs to be applied to keep fueling steady at the target. And eventually, the user may be able to read back the long term trim data, to use as a correction to there VE table when tuning.

Hopefully that helps clear up my goal?
-Rob

[LPG2CV]

I would think perhaps call it Internal Auto-Tune

I did wonder about this myself, but my C skills are also not up to the task.

However, just some thoughts

Where would you store the data in a mega2560? Possibly the 2nd fuel table if you were not using it. Ideally, to know how valid a datum is, it would be preferable to kmow how many hits that value has to determine it's accuracy. Pehaps store this in the 2nd ignition table.

When the code is running, it would have to exclude some engine conditions, such as WUE and AE. Probably Decel as well. Whilst I writing this, I'm thinking that O2 correction also has to consider all of theses conditions to know if it should try to correct. So perhaps the test should simply be that if O2 correction has been applied, then I need to calulate how much and store an equivilent VE number

Just writing a single byte to eeprom should be simple enough in it's self, though the process is slow compare to writing to memory. However, Speedy interpolates values between cells. The current VE value is affected by the cells immediately surrounding the current load/rpm. You need to do the reverse of the interpolation to determine the cells to change (and do you know the propportion to change each).

Whilst all this is being calculated, the mega has an engine to run, so a key value to watch is the loop time.

You also need to determine a way of saving the data before turning off the engine. You cant write continously to eeprom as that will degrade the memory and also slow the loop to much.

So this is why the auto tune process is outsourced to the laptop. OEM processors are very much more robust, and unfortunately, more expensive.

However .... A very fast STM32F407 with FRAM eeprom may be a different matter ...

[iltheo84]

You also need to determine a way of saving the data before turning off the engine. You cant write continously to eeprom as that will degrade the memory and also slow the loop to much.

So this is why the auto tune process is outsourced to the laptop. OEM processors are very much more robust, and unfortunately, more expensive.

However .... A very fast STM32F407 with FRAM eeprom may be a different matter ...

Most OEM ECUs have constant battery power to (at last part of) their electronics, so they can keep data in volatile memory and store it permanently every once in a while, Speeduino always turns off completely so it's far more complicated to add such a feature.

An idea could be using a second MEGA to perform auto-tune on request, mimicking the Tunerstudio code but in a much smaller and cheaper form factor, via serial communication.

[jonbill]

My understanding of OEM long term fuel trim is to compensate for the slow degradation of the engine and components over 10s of 1000s of miles, rather than fixing up deficiencies in the original tune.
Surely manual (or even auto) tuning is the correct approach to getting the tune right?
I appreciate having a PC connected while capturing 100s of miles of road use is a bit clunky, so I always log all my journeys with RealDash on a tablet, and look at a histogram or MLV VE analyse later.

[PSIG]

^^This. I suggest the OEM uses are not exactly like that, and a different approach to LTFT be considered (why I asked the question ). First, this is long-term. EGO and other corrections are currently short-term, but can provide data averaged and accumulated over time ('rolling average') for long-term corrections, across 10s of operating hours or more. Slow and easy adjustment for long-term repetitive error from the intended target.

Assuming all that, the LTFT would *not* correct for simple change of fuel quality from fill-up to fill-up. That's short term or medium term. Importantly, it would *not* correct if exceeding a certain limit, but rather within a limit, as outside that would be a trouble code. This avoids (examples) a randomly misfiring cylinder, leaking injector or vacuum leak from wrecking the tune while ignoring the problem. Normal correction limits are for normal corrections, short or long. More than that is a problem and should throw an error, light a CEL/MEL, etc.

As real-time corrections are always correcting after-the-fact (not optimal), I do support the idea of LTFT, but only for small *accumulated* error and not with excessive authority to be "fixing" problems it should not. As features are based on solving specific identified problems or opportunities - how's that perspective sound so far?

[MidnightTuning]

Wow I wasn't expecting my little idea to get so much attention here in the forums.

As all this was going down, I've cloned the repo and began a prototype. My prototype doesn't support interpolation across its own proprietary table structure and instead calculates a prom address to R/W from based on mapping RPM and MAP over a 0-8 integer scale. This should be ok, as the table will smooth itself over time to its ideal values even with hard cell boundary's. For a prototype it will be fine anyway.

I do worry though as there were some valid points mentioned above. Notably the life expectancy of the EEPROM and the hit to loop time incurred by reading and writing to it basically from within the main loop. The life expectancy part doesn't worry me too much as we are spreading the R/W over a table, not just a single byte like my first prototype of the idea, but its definitely still a valid concern. Loop time concerns me though, writes to EEPROM take 3.3ms per write instruction which i'm not sure the overall loop time can take. Guess I'll find out when I flash my test version.

Thanks everyone for your inputs, I suppose I'll keep you updated as my version goes along. Perhaps the speeduino will need some sort of battery backed external memory for the task, kind of like KAM in Ford's EEC ECUs. Guess I'll find out.

[MidnightTuning]

^^This. I suggest the OEM uses are not exactly like that, and a different approach to LTFT be considered (why I asked the question ). First, this is long-term. EGO and other corrections are currently short-term, but can provide data averaged and accumulated over time ('rolling average') for long-term corrections, across 10s of operating hours or more. Slow and easy adjustment for long-term repetitive error from the intended target.

Assuming all that, the LTFT would *not* correct for simple change of fuel quality from fill-up to fill-up. That's short term or medium term. Importantly, it would *not* correct if exceeding a certain limit, but rather within a limit, as outside that would be a trouble code. This avoids (examples) a randomly misfiring cylinder, leaking injector or vacuum leak from wrecking the tune while ignoring the problem. Normal correction limits are for normal corrections, short or long. More than that is a problem and should throw an error, light a CEL/MEL, etc.

As real-time corrections are always correcting after-the-fact (not optimal), I do support the idea of LTFT, but only for small *accumulated* error and not with excessive authority to be "fixing" problems it should not. As features are based on solving specific identified problems or opportunities - how's that perspective sound so far?

Your perspective is spot on PSIG, exactly what I'm after here. We wouldn't use LTFT like the OEMs do but that doesn't void it of having any use at all in Speeduino.

FYI currently in my prototype, the LTFT table is residing at 3457 decimal, an area that storage.h in the source code indicates is empty currently, with 217 bytes of space

[JHolland]

^^This. I suggest the OEM uses are not exactly like that, and a different approach to LTFT be considered (why I asked the question ). First, this is long-term. EGO and other corrections are currently short-term, but can provide data averaged and accumulated over time ('rolling average') for long-term corrections, across 10s of operating hours or more.
Slow and easy adjustment for long-term repetitive error from the intended target.

Assuming all that, the LTFT would *not* correct for simple change of fuel quality from fill-up to fill-up. That's short term or medium term. Importantly, it would *not* correct if exceeding a certain limit, but rather within a limit, as outside that would be a trouble code. This avoids (examples) a randomly misfiring cylinder, leaking injector or vacuum leak from wrecking the tune while ignoring the problem. Normal correction limits are for normal corrections, short or long. More than that is a problem and should throw an error, light a CEL/MEL, etc.

^ all of this. Modern ECUs have quite complex fuel trims, Speeduino would have to be fairly simple, like a 90s setup with only one pair of STFT and LTFT. The OEMs accumulate LTFT over different periods of time and using different strategies so there isn't likely to be one ideal algorithm.
The simplest implementation for fuel trim corrections is (STFT + LTFT)/2 with both STFT and LTFT limited to 10% and the total also limited to 10%.