Hi All.
I seem to have a problem with accel enrichment , when the car is cold, as the car is bogging really bad, when i touch the pedal , when the car varms up it goes away,
So i would like to know a starting value in :
Acc cold multiplication factor (%) = 100
Cold accel added amount( -40c)(ms)=15.0
The numbers i have written is what i have now, but would like to know if You guys up the first value...
Thanks,
Skassa
I think your overfuelling it with 100% enrichment
try and take out until your good,
I have 0% in there and it might need more to be honest. But itÃ,´s only at idle where itÃ,´s bad normal driving is good while cold,
as you are running more fuel with warmup enrichment.
Thanks,
So you think i need to lower the mutiplication factor, i just found this on wiki, were itÃ,´s apperently is jorgen recommended settings, were itÃ,´s at 120%, and 0 in the cold accel added amount.
http://www.vems.hu/wiki/index.php?page=MembersPage%2FJimW
I will give it a try, so ican check it tomorrow.
Thanks,
Skassa
I did the recommended settings, and it drives like oe when cold, so this is great :)
Thanks,
Skassa
Do You guys, also have a problem when the car is in neutral, and you want to rev it fast, itÃ,´s like there is a delay on the engine response,
That can be alot better with more fuel, but the when the car is being driven, itÃ,´s to much accel enrichment.
Do any of you have a sulution to that?
Thanks,
Skassa
tip-in fuelling off idle is a really weak point. It would be awesome if we could scale enrichment by RPM and TPS change speed, I've asked for it, we even had something that we tested but I'm not sure what happened. All we need is a 4x4 table...
Ok here is a theory of operations I have been thinking about.
Y axis - "dv/dt"
X axis - "rpm"
values in table are Gve values from the fuel table based on the KPA axis,
i.e when you move the throttle letÃ,´s say 20 dv/dt and at the current rpm there is a value in the cell of letÃ,´s say 80
What happens is that when you move the throttle that KPA valueÃ,´s calculated PW value is instantly selected ( assumed KPA ) for accelaration enrichment.
So using this there is a chance of using preemptive KPA value selection.
Ok.
Here is the accelaration enrichment table
(http://myndasafn.bmwkraftur.is/d/63001-1/accelaration.gif)
Here we see that there has been a dv/dt of 18..
RpmÃ,´s are 2500
The value in the cell is 80.
The ecu uses that 80 as a KPA lookup from the VE table
(http://myndasafn.bmwkraftur.is/d/62998-1/vetable.gif)
Here we see that in the 80kpa and 2500rpm there is a VE value of 79.
the ecu would use this as assumed current MAP value while the actual map value is below (map delay)
itÃ,´s used until the actual MAP value reaches it or a set time perhaps.
Bear with me, i may be talking crap
I found that MAP changes almost at the same rate as as throttle. Question, why have a look up table when the MAP responds almost at the same rate? Would it not be better to have a table dv/dt x rpm and the bins used as an enrichment value biased to 100% (no enrichment) Then there only needs to be a time constant for acceleration enrichment duration.
As for deceleration enrichment, im not sure at all, if you could use the same table with a negative dv/dt, where the value enrichment becomes enleanment, IE instead of adding 10% its subtracts 10%, but uses the same table value??
map and tps change rates are different between engines.
In any case we need a table.
And stat. This throttle response is just making the using of vems horrible to be honest.
Okay I've written up a very simple method of acceleration enrichment.
http://www.vems.hu/wiki/index.php?page=GenBoard/UnderDevelopment/AccelerationEnrichment
Would people please go onto that page, click Edit and at the bottom before the line please put your UserName, that you too need this feature, as your engine shows the same enrichment issue.
It is then possible that we may be able to get a change made to improve the system - its not like we're trying to do something counter productive.
I had real problems with acceleration enrichment on the Mini 1400 SPi, and that would have to be the worst situation anyone could encounter, regards manifold design. I tried both MAP and throttle settings and they both reacted in the same manor. Data logs show that MAP is almost an exact trace of TPS where 'rate' is concerned. if MAP rate is the same as TPS rate, havin the TPS table look up the MAP in the VE table is pointless as it will be at that point anyway?? ???
I think there deffo needs to be a table, perhaps not a 16x14, but something that, as Rob said earlier, is RPM based. I would also like to see the enrichment biased to 100%, making it easier to understand how all these 'extra' bits work into the equasion. 100% being the VE value and unchanged (zero acceleration enrichment) 110% being VE value +10% (10% added of VE value) and 90% being -10% ( 10% subtracted of VE value) There still has to be a time constant as its this that differs from engine to engine.
It would be good if the table showed the bin thats active as in the spark, lamda and VE tables, that way you could tune it on the dyno quite easily, constant conditions and repeatable. It doesnt have to be perfect, a tollerence of rich would be acceptable.
Im just curious as to how OEMs do it. Taking for example the Rover Mini SPi, these left the factory either as 53bhp or 63bhp, after tuning the engine considerably 100bhp is achieveble with only a mild cam, this also includes increasing capacity from 1275cc to 1399cc, yet the standard ECU, as long as the injector size is increased, still manages to fuel the engine pretty close to how it left the factory. Its nearly a 100% increase in power yet the acceleration enrichments and warm up enrichments dont seam to give any issues. Perhaps they are VE biased, in that as the adaptive VE values change so does the warm up and acceleration enrichments.
Again, I may be talking crap.
We need something thats is not too complicated, but at the same time not too simple as the thing we have
Please add your name to the wiki page and we'll try and flag this to the developers.
Done mate ;D I was busy typing away as you posted both times :D ;)
Just to tie in with this http://www.vems.co.uk/forum/index.php?topic=184.msg1793#msg1793
:)
done:)
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/rpmvsamount.png)
http://kotisivu.dnainternet.net/sakrkorh/vems/dotratevsscale.png (http://kotisivu.dnainternet.net/sakrkorh/vems/dotratevsscale.png)
Any suggestions for gauges etc?
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.
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.
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.
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 (http://kotisivu.dnainternet.net/sakrkorh/vems/firmware_1.0.79alpha.zip)
Check changelog before trying
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.
Quote from: Sambas on October 06, 2008, 09:53:02 AM
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/rpmvsamount.png)
http://kotisivu.dnainternet.net/sakrkorh/vems/dotratevsscale.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.
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.
I'm waiting with baited breath for the 1.1 version so I can test it on the Nissan.
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
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.
Did any of you make some "startup values", that will work to tune from?
Also the new MAT enrichment table, startup values?
Thanks,
Skassa
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.
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