I can't tell you how cos it's above my knowledge to ''play'' with fuel maps but as you know how why dont you work with those fuelling(IQ) limiters which are FT dependant?Quote:
Originally Posted by td5howard
Printable View
I can't tell you how cos it's above my knowledge to ''play'' with fuel maps but as you know how why dont you work with those fuelling(IQ) limiters which are FT dependant?Quote:
Originally Posted by td5howard
There are no fuel temp dependant limiters.Quote:
Originally Posted by sierrafery
The closest things are the two fuel density compensation maps which increase fuelling to compensate for reduced density with increasing fuel temperature. They effectively limit IQ above a line that runs from 100mg/fire at 1000rpm to 60.00 mg/fire @ 4200rpm IF and only IF the that amount is being requested via driver demand and allowed by smoke and torque limiters.
If Stephan is making duration map mods only then he's unlike to be running into the density compensation upper limits.
The map I'm thinking about in particular sets the upper limit for MAF aircharge in mg/stroke. If the limit is exceeded the ECU switches across to MAP/IAT fuelling and uses what is basically a EU2 fuelling strategy. If there is a substantial difference between the aircharge calculated from MAF/RPM and the value from the MAP/IAT then it's going to cause very weird behaviour when the ECU switches.
Fuel temp corrections are not the problem. I don't do ghetto style eurotuning. :-) ID is TRULY extended to 70mm3 column and nothing else in ID maps is changed. 70mm3 is roughly 57mg which is below 60mg temp correction limit. The result is what to be expected - with 1.3bar boost and A/F limited to 17 (EGT is less then 900C) Disco puts down 95-100KWt, compared to 60-65KWt with stock map. I am using GTechPro with car weight of 2500kg, Cd=0.6 and frontal area of 3.8m2 (truck is lifted 5" and runs 35" rubber). OEM map results are very well correlated with what I've got on Superflow 4wd dyno - 92.7whp with 43hp power loss. Dynoruns were done with no maf, four lifters shot and on injector under fueling by 25% in 3d gear due to slipping fancy expensive like hell high performance gold plated clutch setup from Europe which had problems handling 500+ Nm. So, you get 40% more fuel and you get 40% more power. Fare enough. I raised boost to 1.3bar only to keep A/F above 17. There are maf flow limiting maps - there were raised to 2500mg, so they are irrelevant for all practical purposes.
May be I was not clear enough in describing my experimental findings. I'll try again. There is a magical number of around 650kgh where ECU freaks out. It does not depend on rpm range (exept revving with no load), it does not depend on maf model used, it does not depend on maf output voltage. If you do not beleive me make a simple experiment. Change the maf table so that you leave it original up to say 2.5V and then rump it up to 700kgh at 3V and all the way to 5V. Once you are done see what happens once you start driving.
This is it Paul "If there is a substantial difference between the aircharge calculated from MAF/RPM and the value from the MAP/IAT then it's going to cause very weird behaviour when the ECU switches." It's quite fitting to my experimental findings. I maxed out the upper limit. I have several logs to see how different maf and map flows. By the way the formula that you got from the code for map flow assumes 103% VE and stock maf flows are greater then map flows. Stock maf is overfueling by 10-15% then.
On a separate note. Do you think that if I zero out the upper maf flow limit then I'll be running on map fueling with no weird delays after the start up? Why is then maf is not present the map fueling is subpar? I wish I had the processor programming knowledge of yours. :-)
Stepan
One more question Paul. I encountered the following issue with the Pierburg maf - NANOCOM flow variations up to 15% at idle. Pierburg needs 5V reference voltage and I provide it. maf output is stable like a rock over time - 2.01 to 2.02V with supply voltage variations between 12.5 and 14.3V. If I go back to OEM maf NANOCOMThe NANOCOM shows anywhere from 45 to 62kgh. If I go back to OEM maf NANOCOM shows 57-59kgh. In this thread you mentioned that ECU corrects maf signal for supply voltage variations. Is it so? If it is then it explains my observations. I guess I have to compare variations in supply voltage to NANOCOM flow numbers. Would providing ECU with the stable 12V supply solve this problem?
Is there a way to make maf irrelevant for Eu3 fueling?
Stepan
900c EGTs??? [emoji15][emoji15][emoji15]
900С EGTs are not on a constant basis - only 4th and 5th gear pulls to 5000rpm. Cruising in 5th at 140kmh sees around 600-700C sustained and it's been this way for the last 70Kkm. ;-) Around 180Kkm I lost dreaded oil pump bolt and third cylinder. Autopsy showed that the motor was in perfect condition - bores had hone left on them, halfs, piston rings ... you name it. This motor had a terrible life from the 30Kkm and up - constant molestation and sexual abuse, running 2 bar boosts, EGT's of 1000C and up, two runaways and for the last 70Kkm of its life putting down to pavement 210hp (best of eurotuners see 160-170 whp). Never blue a head gasket, warped an exhaust manifold or overheated. Blown "bespoke" intercoolers, "bespoke" turbos, shredded to pieces flywheels/clutches, drivetrain - had it all, but not the motor. Sorted it all out - it's bullet proof with junk yard parts (not quite junk yard, but you get the drift). ;-)
Too many questions!!
650 with MAF sounds like it might be problem of your own making.
I've done a mod for the MAF that extends range above 680kg/hr which works on the EU3.
The ECU corrects for variation in the ADC 5V reference voltage, rather than supply - saying otherwise was an error on my part.
I believe mm3 is incorrect. The LR System Constants document I've seen consistently identifies fuel units as mg/fire.
The plot below shows driver demand, smoke and torque limit values, and the resulting IQ request in the top half.
You can see in this case the IQ requested is slightly higher that driver demand. We know from LR docs that all these values are mg/fire.
The bottom half shows RPM, IQ request, Inject Advance, and Inject Duration.
This is live data from my EU2 recorded yesterday. The processing code is basically the same in the EU3 maps, so point holds...
Attachment 129436
The IQ request is modified by fuel density compensation but is essentially what is passed to the ID maps as the x-axis value.
The point highlighted by the cursor in the plot above shows 3014 rpm, SOI advance 4.4 degrees, IQ request 35.34mg and inject duration 1614 microseconds.
If the ECU is converting to mm3 the IQ request used in duration map should be 35.34 / 0.835 = 42.32mm3.
I have a matlab script that replicates the Td5 map interpolation code for individual tables - because I'm too lazy to do this stuff by hand.
3014rpm 35.34mg
0 degree duration: 1666
5 degree duration: 1610
3014rpm 42.32mm3
0 degree duration: 1866
5 degree duration: 1803
Even without interpolating between the 0 and 5 degree values to find the 4.4 degree advance you can see that the durations you get from using 42.32mm3 are not even close to what the ECU delivers.
And yes, you can disable the MAF in EU3 maps.
At this point of time I have only given that information to Gary Wood at Alive Tuning, as he requested it for a clients td5 race truck.
The fix requires altering the program code in the variant map, so it's something that will crash the ECU if not done exactly right.
Ok Paul, let me leave this maf issue for a minute - I'll do runs over weekend and see what's up. Difference between mm3 and mg in ID tables is much more important, at least for me. EU2 data that you provided with your wonderdataloggingmashinefromhell are quite convincing. I have the Holy Bible of MEMS EU3 navigation (:-)) that says the following regarding ID maps (17x10)
du_fuel_pw_cam_ang_1
du_fuel_volume(mm^3/fire) (column header)
mc_engine_speed(rpm) (rows header)
Is there any difference in how the code addresses ID tables between EU2 and EU3 variants? I.e. is it possible that EU2 uses id's for mass, and EU3 for volume? If not, then this is mistake by Lucas and simply the greatest news for me.
Stepan
Hi Stepan,Quote:
Originally Posted by td5howard
I don't have the "holy grail" and beyond a system constants list that was posted to a spanish forum recently I have only freely available information like RAVE plus many years of my own work to go on.
If you have the "holy grail" you don't need my help. If you do want further assistance email me, and we can discuss information exchange.
EU3 code is an extension of the EU2 code, not a complete rewrite.
Where there are differences the focus is on finer control over parameters rather than fundamental changes.
cheers
Paul
