[help needed] Acceleration enrichment

It's all about the code!
Post Reply
User avatar
AndreyB
Site Admin
Posts: 14327
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Acceleration enrichment

Post by AndreyB »

Stable operation fuel control is good enough, acceleration/deceleration enrichment not so much. There are three algorithms in the firmware already - see http://rusefi.com/wiki/index.php?title=Manual:Software:Fuel_Control#Acceleration_Enrichment

Now the big question is what are the magic numbers which would work well since all the algorithms are asking for a lot of magic inputs.

Base log https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/2016-01-30_accel/2016-01-30_12.35.51_base.msl that's with no corrections
Image
Image


TPS based, random setting
https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/2016-01-30_accel/2016-01-30_12.45.18_tps.msl
Image
Image

wall wetting log #1 https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/2016-01-30_accel/2016-01-30_12.50.55_wall_film_1.msl
Image
Image

wall wetting log #2
https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/2016-01-30_accel/2016-01-30_12.53.56_wall_film_2.msl
Image
Image

Any ideas what should be the next round of settings to try?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14327
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Acceleration enrichment

Post by AndreyB »

I've realized today that the threshold I was using was so high because TPS noise was pretty high - first reason that was that TPS was using the fast unfiltered ADC, another reason was that in order to simplify TunerStudio integration I was throwing two bits of precision away. I've made changes to the firmware, now TPS is back to full 12 bit precision and it's now using the same averaging + ext averaging filtering.

New log https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/2016-01-30_accel/2016-01-31_19.03.10_tps_accel.msl - this log makes me thing that I should try higher 'length' parameter.

Image
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: Acceleration enrichment

Post by stefanst »

At first glance it looks like the Acfuel shot should be long enough. Are you sure the fuel cells you're hitting at the end of the accel (close to 100kpa) are properly tuned steady state?
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: Acceleration enrichment

Post by stefanst »

First of all, you should be able to get the car running well with just TPS and MAP based settings. IMHO the wall-wetting algorithm is the icing on top for the last 5% of perfection.

On my MS I use TPSdot based enrichment to deal with the initial "Tip-in" spike in AFR. MS doesn't even have a setting to set the length of that enrichment. I then use MAP based enrichment to deal with the longer term rise in MAP pressure and the resulting puddle of fuel building in the intake.

If you just blip the throttle in idle and get a lean stumble. That is something that should be taken care of with the TPSdot based enrichment. I tuned the MAPdot based accel by somewhat slowly rolling on the throttle- not just mashing down on the pedal, but a roll as you would do after apex, when you are close to the limit of traction. This should give you a lean region that lasts for a few hundred milliseconds. That has to be tuned out with MAP based.

Looking at your logs, you were doing some fairly aggressive movements of the throttle. These are the toughest to tune out and we may not have enough "magic" parameters yet in the software to deal with them real well. Use small-ish movements first and then take it from there.

The next magic parameters we could probably use is a calibration curve instead of multiplication factor for enrichment. A change of 10,000%/s may need dis-proportionally more enrichment than a change of 100%/s. This is in addition to threshold.

I also advocate another two settings for TPS-based enrichment:

1. Full-throttle scale over rpm
The lower your rpm, the more degressive your throttle gets. At idle, just opening the throttle 10% may essentially give you already 99kpa MAP, so for the purpose of acceleration enrichment tuning 10% TPS at idle rpm is 100% TPS.
-> a calibration curve full throttle% over rpm would be helpful.

2. The restriction to airflow that the butterfly creates is not linear with angle. The first few degrees of change in angle have a larger impact on flow restriction than the last few degrees. I would advocate for another calibration curve for TPSdot based on TPS start angle. This is not as important as the full-throttle over rpm scale and I don't even know, if any ECU currently in production has something like this.

For the MAP based enrichment I would suggest another adjustment: Taper. During the MAP-based shot you should probably not run the same amount for the full duration, but taper it down somewhat.

Of course how to realize this in code is beyond me!

For your current tune, I would try starting without TPS-based and increase duration and fuel for MAP based. Once you have that as good as it gets, use TPS-based to deal with the remaining initial lean-spike.

Vary parameters and post logs. A description of what you're doing would help, also vehicle speed data. For example initial tip-in with the clutch in at a traffic light start may show different effects than rolling along in idle or close to it and then giving a little gas while already under load.
Roll along in high gear at idle. Then give it 10% throttle from there. Drop back to idle. Give it 20% and so on.
User avatar
AndreyB
Site Admin
Posts: 14327
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Acceleration enrichment

Post by AndreyB »

@ has stopped by last weekend and moved acceleration enrichment forward.

TODO: https://sourceforge.net/p/rusefi/tickets/314/
TODO: https://sourceforge.net/p/rusefi/tickets/315/

Here's how TPS to TPS table looks at this point. This table holds acceleration extra fuel for each "from previous TPS" to "new TPS" event,

Logs & tune: https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/2016-09-11_accel.7z
Attachments
20160911_tps2pts.png
20160911_tps2pts.png (32.79 KiB) Viewed 15184 times
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: Acceleration enrichment

Post by stefanst »

Just general advice for tuning accel enrichment:
You need to have your static behavior tuned properly before trying to tune accel enrichment. Meaning ALL the VE cells that will be used need to be tuned well. Otherwise you won't be able to tell, if your deviation from intended AFR is due to poorly tuned VE table or poorly tuned enrichment. Also voltage compensation for injector lag time should be close, since voltage may change with rapid changes in rpm and that will cause change in lag time which would mess up your AFRs as well.
User avatar
AndreyB
Site Admin
Posts: 14327
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Acceleration enrichment

Post by AndreyB »

@ would you be interested to improve the http://rusefi.com/wiki/index.php?title=Manual:Software:Fuel_Control#Acceleration_Enrichment page? It's behind the reality at least in terms of TPS/TPS table. I have someone asking what is the whole tps/tps thing about.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: Acceleration enrichment

Post by stefanst »

Made the requested edits to the Acceleration Enrichment Wiki.
http://rusefi.com/wiki/index.php?title=Manual:Software:Fuel_Control#Acceleration_Enrichment
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Acceleration enrichment

Post by kb1gtt »

Sweet and good job. I think it's very well written, I like down to earth talk which I think you did well.

One thing that might be a handy adder is some kind of description of when you should tune these parameters. AKA, get the static operation working properly, then deal with the dynamic situations. As well if you change the static parameters you should probably check and re-tune the dynamic parameters. Something like that might help people understand when it should apply.
Welcome to the friendlier side of internet crazy :)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Acceleration enrichment

Post by kb1gtt »

Oh also a quick comment, what happens with a cold engine, and wall wetting. Is that covered with the cold engine parameters and cold engine tuning? Or does that need to be taken into consideration here. I believe you generally tune such that you run a bit rich until warm, and then accel enrich just makes it run richer. However if you tune it to be too rich when cold, you could flood it on an accel enrich event.

Again, awesome job on the write up.
Welcome to the friendlier side of internet crazy :)
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: Acceleration enrichment

Post by stefanst »

Thanks for the kind words!
I'll take the suggestions and add what I can.

There are a few issues left that are rolling around in my head and I'm not sure how to deal with:

TPS-/EL-based accel: Should we calculate the delta based on engine cycles or time. Meaning TPS%/second or TPS%/crank rot?

The whole wall fuel idea: I'm pretty sure for small throttle openings TPS-based works best. But should we just switch from TPS-based to wall-fuel after a certain throttle angle, or blend in a certain region?

I'm pretty sure we'll eventually do away with MAP based enrichment and replace that part completely with wall-fuel.

How do we implement RPM scaling? I guess in reality the correlation between RPM and accel fuel requirement looks something like this:
Enrichment vs RPM.png
Enrichment vs RPM.png (10.27 KiB) Viewed 15075 times
So we should probably have another calibration curve that takes care of this.

Wall-fuel: Should we do something as theoretical as X-Tau, or something more tuning oriented, where we just offer a bunch of calibration curves where we estimate deposited and removed fuel based on a bunch of parameters?

Probably over-thinking things here, since we can get cars driving rather well, just based on simple TPS-based enrichment :)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Acceleration enrichment

Post by kb1gtt »

I know several OEM's use a blend of TPS and MAP. I understand TPS is better at low RPM, and MAP is better at high RPM. Then blended in between, and if things are to far out of wack, then check engine light triggers and you switch to limp home mode.

I've wanted to find (or make) an equation for your engine. Such that you can adjust some basic parameters and simulate an engine. If we had a math equation like that, we could probably find better algorithm mechanisms.

I'm not sure about the RPM vs time thing for the base unit of the maths. My gut tells me RPM based would be better. I suspect the reality is a blend of both, such that at low RPM you are more influenced by time, but at high RPM you are probably more influenced by air volume / flow rates. Is that what you are getting at with the RPM scaling thing?
Welcome to the friendlier side of internet crazy :)
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: Acceleration enrichment

Post by stefanst »

I think the X-Tau approach is essentially a mathematical model for how the engine, or at least the intake-tract behaves. I just don't know much about it.

Tuning is easiest when dealing with straight-forward tables. Like: When I do this the car goes lean, so under these circumstances I need to add some more fuel.
rusefi is not going to be the primary choice for OEMs any time soon, so the users will be more the modifier-crowd. And we looooooove to change stuff on our cars. A lot of that stuff in turn changes the needs for accel-enrichment. And therefore the most tuner-friendly approach will probably be the most successful.
For example I just changed my intake manifold and now my accel-enrichment which used to be spot-on is off in some spots. So now I need to correct. Checking my logs and seeing that lean-condition occurs 200ms after I increase throttle at a rate of 50%/s or more is easiest corrected when I have a table that allows me to adjust enrichment based on change in TPS and time.
I never tried to tune x-Tau with my MS, maybe I should try and learn...
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Acceleration enrichment

Post by kb1gtt »

The XTau was part of an MIT PHD thesis where the MIT fellow used MS because it was the most open thing he could find at the time. The fellow did a fairly decent write up on it found here http://www.megamanual.com/ms2/xtau.htm

I kind of agree with the table lookup approach instead of the math approach. Tables are more intuitive and more people are able to just kind of understand them. They are much easier for people to tune, and easier to implement. I also like tables because you can post process data doing the funky math, which then indicates what the table should be doing. Or you can simply gut feel your way though it. Then lets not forget that table algorithms remove the math from the live controller, which helps allot with system loading and software induced jitter. The lookup tables have very consistent software lags, which is handy for getting a stable tune. Granted the STM32 has a Floating Point processor Unit (FPU), so floating point math is very easy and fast for this series of processors. However for other processors with out an FPU the math approach is really hard and induces wild software jitter. So the tables approach is more portable, as you can choose processors with out FPU's. Any how, yes tables are good when you can do them.

Also keep in mind
-- Your MAP sensors typically have a 1mS delay.
-- There is delay as it takes some time for exhaust to get from your cyl to the O2 sensor. This is mostly determined by the diameter of your exhaust and the distance between the sensor an the cylinder. If you have a fat exhaust, and you mount your sensor in the typical location which is kind of far away from the engine, this could be 1 or 2 rotations before the gas has made it to the sensor. That amount of delay will vary with RPM.
-- NO2 has a delay as low as 300mS ish, and a WO2 has a delay of about 100mS to 500mS.
-- Your O2's are a kind of low pass filter, so short term transient spikes are basically smoothed out. You probably have short term spikes of both rich and lean conditions that your sensors simply smooths out.
-- As the O2 sensor wears in, the response time and accuracy change.
-- When you have rapid changes of the long pedal, the increase or decrease of fuel that the manifold air can hold will increase and decrease accordingly, which takes some time to get back to a steady state. There will be times when it's super saturated, and there will be times when it can absorb much more fuel. As well there will be times when it's happy to stay right where it is. These dynamic situations cause all sorts of things relative to the flame front which may result in a rich or lean burn.
-- Those situations can cause rich and lean all in one ignition event. However the various lags and low pass filtering smooths this all out for us.
-- It takes the sensor 5 time constants to be accurate, but at 1 time constant you are typically 70% accurate, so short term dynamic information can provide valuable data, but will have wild +/- tolerances.

All of these delays and sources of error in your readings means that your O2 sensors should not be used for fast AFR changes or tuning. I seem to recall these various errors are why OEM's use the short term trim and long term trim. So when you see a short term lean blip in your tuning logs, it probably means that a much larger lean condition happened. However as @stefanst noted that does not matter, what does matter is the butt dyno measurements. If it does not stall or lag, then you are good. As well if you tune the transients to be theoretically rich, that's also a better place to be at. I would think you would tune until you start to feel a lag, then increase fuel by something like 10%.

A reasonably famous test was preformed, where they published several results of O2 sensor systems. It indicates a common response time was between 100mS to 500mS for a variety of WO2 sensor systems. I recall at the end of the day the innovatemotorsports dithers the cell current. By creating this dithering current they can speed up how fast the cell responds, which means they get a faster reading. However even with that technology, they are still something like 100mS response time. Some people claim this dithering fatiques the sensor and shortens it's life. So who knows if that's OK for OEM, but the after market is looking for out of the box performance, so who knows what to expect. Shoot out link below.
http://www.innovatemotorsports.com/resources/FM_WB_Shootout.pdf

I really don't tune much, but for me, if I were going to tune, I would follow these general steps before attempting to use O2 data.
-- Warm up engine such that CLT is warm for at least 5 minutes
-- Then drive it normal for at least 5 minutes to warm up the exhaust
-- I would only tune based on AFR when you are able to keep a fairly stable load and RPM on the engine for 5 seconds or more.

I know that autotuning software often tunes each cell in less than a second. I would not trust the sensor reading at this condition, as it would have a +/- 15% error. I would tune for the static first then deal with the dynamic separately. Trying to tune the static while dynamic stuff is happening is going to cause a bunch of head aches, which will probably result in ECU's tossed across the room.
Welcome to the friendlier side of internet crazy :)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Acceleration enrichment

Post by kb1gtt »

I finally found a page I was looking for. It appears the original web page is not currently working, but it still exists on waybackmachine. See attached PDF copy of this web page https://web.archive.org/web/20130513164246/http://www.ecotrons.com/ALM_VS_LC-1.html where Ecotrans reviewed some WO2 systems. I recall the LC-1's claim to fame was a faster response time because they were dithering the O2 cell current, which can be seen on the output noise. The ALM uses a CJ125 to extract the signal. At the end of the day, it appears that the Bosch chips are the fastest and most accurate device out there. Any how the posted web page notes many things like this graphic.
ALM_vs_LC-1_rich_to_lean.JPG
ALM_vs_LC-1_rich_to_lean.JPG (275.19 KiB) Viewed 15040 times
PDF copy of web page archived here
ecotrans_WO2_response_time_webpage.pdf
(8.45 MiB) Downloaded 340 times
Welcome to the friendlier side of internet crazy :)
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: Acceleration enrichment

Post by stefanst »

Thanks- interesting stuff!

I was aware of O2 sensor delay due to many reasons, but this is the first time I see it quantified. A few years back, when I started tuning my car, I actually did some testing to characterize the delay of my setup by intentionally leaning out at static conditions and observing how long it takes to propagate. This gave me a few clues, but isn't very precise since it's hard to drive a car completely steady. I really need my own roller-dyno....
Or maybe put a narrowband sensor right next to my wideband and use that for closed-loop control of AFR and record the time difference it takes the WB to pick up the same change.
But then again, my car runs pretty well without all that, so this is one of those "I'd like to when I get around to it" projects.
User avatar
AndreyB
Site Admin
Posts: 14327
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Acceleration enrichment

Post by AndreyB »

kb1gtt wrote:
Fri Nov 11, 2016 5:57 pm
wall wetting
I could not find a thread designated for just wall wetting so I've started https://rusefi.com/forum/viewtopic.php?f=5&t=1481
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Post Reply