accel enrichment

[Sambas]

If I got it right it's now ready for testing. I'll do some testing later today. Should be avaible in 1.0.79 and also easy migration to 1.1.x.
Menus would look like this:
http://kotisivu.dnainternet.net/sakrkorh/vems/rpmvsamount.png
http://kotisivu.dnainternet.net/sakrkorh/vems/dotratevsscale.png

Any suggestions for gauges etc?

[rob@vems.co.uk]

Fantastic work Sambas!

That looks exactly what I wrote on the wiki page.

As for guages... I think the ulitmate would be a value that actually tells us the TPS change speed - then when reviewing the datalogs it would be possible to see what dotrate_vs_scale value you had when the enrichment occured, as it would this would then give us all the info to make reasonable accel enrichment changes.

[Sambas]

Atleast in MLV you can add Calculated fields ->Optional fields -> TPdot. max=255 min=0 for our system. Did the test run on my test engine and noticed some improvement on throttle response after some tuning.

[dnb]

Just doing this now...  I have found that the original scheme isn't too bad when the car is running, but is always too rich from idle.  A simple scaling of the pulse with RPM would be sufficient for me.  (I know my car is a bit of a special case given it's a big NA v8, so I'm prepared to accept the simple case won't work for everyone)

Remember what we're trying to achieve here:  Accel enrichment is there to "square up" transients - when the engine sucks the wall film off the inlet ports it needs to be replaced.   The removal of the wall film looks like it's  proportional to air speed and volume flow through the ports, and probably a whole load more things besides.  Air speed can be approximated by RPM and volume flow by TPS.  Hence I think we need a pulsewidth proportional to TPS, TPS_dot, and RPM.   The duration ought to be a number of engine cycles, so it has an inverse proportionality to RPM - eg we put in big extensions to  injector pulses for a short time at high RPM, and small extentions to the pulses for a longer time at low RPM. 

Also, I have yet to see an engine where TPS doesn't lead MAP [in time].   So TPS is definitely the prefered choice.  MAP could be used, but would carry much bigger lag, so the algorithm would have to be MUCH better at predicting transient responses.

[Sambas]

I was trying to release this yesterday but had some isp related problems, but now here it is
http://kotisivu.dnainternet.net/sakrkorh/vems/firmware_1.0.79alpha.zip
 Check changelog before trying

[dnb]

I looked for it last night after talking to Rob but couldn't find it...  Guess I know why now!  I'll try it tonight.

[Jorgen]

If I got it right it's now ready for testing. I'll do some testing later today. Should be avaible in 1.0.79 and also easy migration to 1.1.x.
Menus would look like this:
http://kotisivu.dnainternet.net/sakrkorh/vems/rpmvsamount.png
http://kotisivu.dnainternet.net/sakrkorh/vems/dotratevsscale.png

Any suggestions for gauges etc?

That enrichment model looks good. I have always suggested that we have a separate "tip-in from idle" setup but this covers "tip-in from idle" without any extras.

My previous estimate that a 4X4 table is enough was based on this idle area. I think tha we need 5-6 rpm sites without the special idle condition. If that would be simple to arrange it would be good.

I expect to have a loadsite just below idle and one at maybe 1300 rpm, where the AE in the idle loadsite is probably 3-5 times higher then the base transient fuel at 1300rpm.

AE is affected by load:
I think that a 3d table with load and rpm is not better then the 2D rpm table. I have always found that you always need a lot more acc enrichment if you tip-in from a high vaccum then if you tip in from almost ambient pressure. I always find that the correct AE for low loads will overfuel heavily if you tip in from, 80-90kPa to boost. This is most likely related to the fact that you have less fuel on the walls at high vaccum then you have at lower vaccum but with a limit above which more fuel is not puddling on the walls.

Considering the separate "tip-in from fuelcut" condition and the lower demand under boost I think that we need 5-6 loadsites for MAP as well.

Having a 2D load compensation table would probably work in most cases but the added flexibility of the 3D RPM/Load table is probably worth the effort.

Overrun fuelcut:
We also have a special case with the overrun fuelcut, when tipping in from an overrun fuelcut condition we need a lot more fuel then if we tip in from just above overrun fuelcut. When going into overrun fuelcut the walls will quickly be purged from fuel, this fuel has to be replaced when the fuelcut is removed again. This will have to be added to the AE if there is a tip-in.

Transient fueling will also be simplified greatly if the overrun fuelcut is delayed for a configurable time. 1 second would probably be a good fixed value.

Updating load based AE:
While tipping in the load (usually MAP) will change quickly. I THINK that the AE amount should be updated upward if the load table says so but that it should not be updated downward. I base this on the fact that if you do a tip-in from overrun fuelcut you really need all that extra fuel specified down at 20kPa, negating this with the low AE specified at 100kPa 0.1seconds later will cause problems.

As long as the decay is the same for all AE it would be enough to just compare the current acc enrich amount with the new one that is calculated, if it's higher it's applied and if it's lower it's ignored. If we need to use variable decay rates in the future I can only see that we need to make an array where all the different transients are calculated and where the biggest one is applied.

Meanwhile I'm looking forward to trying 1.0.79 with this new AE fuel stratergy in my car.

Jörgen Karlsson
Gothenburg, Sweden.

[dnb]

I did a couple of miles with 1.0.79 tonight.  Unfortunately it was only taking the car to my garage so the diff can be replaced (bearings dead) and new brakes fitted...

It's a considerable improvement.

[rob@vems.co.uk]

I'm waiting with baited breath for the 1.1 version so I can test it on the Nissan.

[Jorgen]

I have used the 1.0.77 version of the acc enrichment for more then 600 laps and maybe 5000km on the street this year and it can't be compared with 1.0.73. It's a lot more forgiving then 1.0.73 as a small delay (that was introduced by some kind of filter) was removed and as the decay and retrigg of the acc enrich was improved. The result is that you will have a much larger window for the transient fuel tuning, the more responsive acc enrich will allow you to run much less acc enrich while the smoother decay will allow you to run more acc enrich without drowning the engine. I have had no problems tuning really good transient fuelling on my track car.

With the 1.0.73 firmware that I ran last year the shortcommings of the acc enrich model was easily felt in the city and on the track.

Now it is impossible to feel any kind of problem with the acc enrich in 1.0.73 (except for the tip-in from idle that is only 5 times better then 1.0.73 when a 10 fold improvement was needed) but the logs show that it can be slightly better.

This new better model will require the dv/dt to be logged as it will be time consuming to tune the new acc enrich to it's full potential without this information.

Jörgen

[dnb]

I calculate dv/dT and rpm_dot after the fact.  It's not perfect, but it's passable.  It enabled me to get the 1.0.77 (and 1.0.78 this week) accel enrich tuned in a couple of half hour datalogs.

Just finishing the code for 1.0.79.  It's going to need at least double the datalog time because of the extra degree of freedom.

[Denmark]

Did  any of you make some "startup values", that will work to tune from?

Also the new MAT enrichment table, startup values?


Thanks,
Skassa

[rob@vems.co.uk]

Not yet, feel free to offer some of your own suggestions for values though

You could start by setting all four the RPM based duration values to the same value as your current single value.
Then tune the dv/dt percentages, and then adjust the RPM values to give the fuelling changes you require.

[Denmark]

I will gladly give my info out, but as i have not even tried it yet, its a bit difficult
I will give it ago, as soon as i get the triggerwheel mounted on my own subaru, as i now dont want to spend more time getting it to run with the oe triggersetup, as this seems alomost impossible.


Is there any reason, why i would not use 1.1.42 instead, and use the gearboost and otherstuff, when i´m going to run 36-1,
This looks like it would work.

/Skassa