l2r99gst
What about the situation where load stays the same, but the conditions are considerably different?

For example, 20 psi in cold weather might give you a load of 2.6g/rev where in hot weather, it might take 25 psi to hit that same 2.6 g/rev load. You are now sitting in the same load cell, but have very different timing and fuel requirements. Thus, you still need to correct for these conditions in additional tables as well.

Also, your primary corrections for temperature is taken care of in a subroutine, and not in a map with the method I am talking about. It simply uses a density correction for the temperature compensation for fuel delivery. The IAT comp tables would be nearly flat, except for very high and very low temp conditions where you want to modify the AFR or timing advance speicifally because of that particular environmental condition. These corrections would also happen on the back end of the calculations. (i.e. enrich the AFs 5% and pull 2 degrees of timing above 100c coolant temps or 40c IAT)

My point is, why have a system that tries to build corrections into the main map but still have to rely on additional correction maps? Build a simple system that keeps corrections and primary mapping completely separate so you can avoid building in double corrections into your maps.

You could still produce a "load" parameter at the end to keep the rest of the ECU happy. Matter of fact, you pretty much will create that same load parameter on the back end anyway to calculate the IPW. That should keep things like EGR and EVAP checks relatively happy while having a more effective (IMO) solution to tuning.

 

That's where I think we basically disagree. The required fuel/timing will be very close in that example, because the mass airflow is the same and the resulting cylinder pressure is the same. The boost and temp are different, but the mass airflow is not. You may need a minor coolant temp or air temp trim, but the basic air mass per rev is driving what the cylinder pressures are.

AFR is just a ratio if air mass to fuel mass. Timing is just when to fire the plugs, needing less timing at higher cylinder pressures and more at lower.

 

Air flow is not a corrected value. Its a real, concrete value (mass of air entering the engine per unit time), and for MAP-based engine control, air temp and VE are both needed to make an accurate calculation of air flow.

The ECU already has algorithms to deal with air temp and engine temp variations, and by far the easiest solution is to continue to use those correction routines.

This is all kind academic though. The engine control algorithm is heavily dependent on load. Load is used in over 500 different calculations. Its easy to say that we can redo the fuel and timing maps to be read versus MAP or some other thing, but what you don't see are the 10s to 100s of other calculations based on load that go into creating the final fuel pulse, timing value, MIVEC setting, etc. Having some things based on MAP and other things based on load will only complicate tuning and result in unpredicatable response. The only practical solution is to calculate a load from MAP.

 

That is my point though, the correction must still be made due to the different detonation thresholds that will be encountered under those conditions. It seems more simple to me to do the correction in one map/subroutine where a change won't affect your main tables but is only an add on correction.

With the method you are suggesting, you are correcting for the density up front and working it into the tuning maps. Now your main table is sensitive to environmental conditions at the time of the tune. Any change in environmental conditions will move you around on the load maps, which will put you where you want to be for cylinder pressures. However, it will not put you where you want to be for detonation threshold under those conditions.

I do think we are splitting hairs here though and it's just a fundamental difference in preference, I suppose. In the end, your method and my method will both require compensation maps to deal with various environmental conditions.

 

That's pretty much what I figured. It would be nice to be in MAP on the main maps and I think provide easier tuning. However, when practicability meets ideals, in an open-source, time-donated environment, practicality >> ideal.

I'm just stoked to see this being looked at.

 

I don't want to grind away too much, but its not really a correction for air density so much as it is a correction for operating environment. When the engine or air get hot, the chance of detonation increases. It would be impossible to try to build this into a fuel or timing map without having a third axis for say air temp or engine temp. That's why these are separate corrections that come after the base values are calculated.

 

If writing an ECU from scratch, I would rather have fuel and timing as kPa vs RPM tables, with a compensation table for inlet manifold temp.

However, based on how all the MAF based ECUs I've played with work, the only feasible way to do it on the Evo is to replace the load variables with our simulated load based on MAP and temperature, compensated by VE. So we are emulating a MAF. Previously I've done this with a box of electronics I made much like MAP-ECU et al. The real nightmare was acceleration enrichment - a MAF sensor gets an inlet manifold filling spike which allows the ECU to have much less acceleration enrichment mapped in. As long as the asynchronous acceleration enrichment tables have enough clout to provide the dramatic extra enrichment required, there should be no driveability problems or need to add our own TPS comps.

Baro is a possible issue for those in the USA with wild variations in altitude that we don't get in the UK. Although we are reading MAP, the VE of the engine for a given MAP will reduce with increasing altitude because the wastegate will need to be closed further giving a rise in exhaust manifold pressure. With dropping VE at altitude, the engine will tend to overestimate the load, so will run retarded ignition and richer fuelling - this is in the direction of safety. I suggest that for a first attempt we ignore this and see how much of a problem it really is.

Temperature comp needs a light hand, and should not fully compensate for the theoretical change of air density of 10% per 10% change in absolute temperature - just as the stock ECU doesn't. This is because higher temperatures want to have less ignition and more fuel, and if the sensor is heatsoaked and you have a sudden rush of cold air you don't want to go lean.

The IX JDM ECU I use already has a system for fuelling off the MAP sensor that Bez has documented on aktivematrix. As standard the compensations for temp, baro and VE are hardly setup, the car can limp home with it only. I understand that his patch basically uses this, disables the MAF sensor fault codes, has the asynch accel enrichment adjusted, and he has refined the VE part of it.

Re VE, with my box of electronics before I tried various 1,2,3d tables or algorithms. A big 3d table is a PITA to setup.

What worked REALLY well and was very simple, was an 8 points 2d airflow compensation table. Ignoring the details we don't need here for clarity, my box took MAP * RPM and shoved it into the ECU which applied a percentage multiplier at these 8 points. One lined up with idle, another few with cruise, another few with part throttle acceleration, and about the last three with peak torque to peak power. Closed loop trims were really tight and the car behaved like OEM in all conditions. As I say, the only real challenge was acceleration enrichment.

When I mapped it, I simply put in the fuel table the AFRs I wanted, and then set the 8 point VE table so that I saw on the wideband what I had in the table. After that I just tuned timing in the usual way. Both were setup easily as my logger painted the min/mean/max AFR and knock over the fuel and ignition tables. It was astonishing how easy it was to map and how well it drove. I had ongoing niggles... with the nightmare of acceleration enrichment which took months to get right and was ruined by changes in conditions. But I don't think we'll have this issue on the Evo as the OEM ECU has lots more accel enrichment tables we can change.

 

woooa lots of big replies I will read them indepth at work

One thing that keeps popping up is MIVEC.

Surely MIVEC is just another form of adjusting VE, therefore when you change MIVEC you would need to change your VE table - the VE table doesn't need to be based or scaled with MIVEC, it just needs to change as if you did a engine modification -
ie I ported my head, so my VE jumps up across the board.
same with MIVEC, i found that decreasing the MIVEC advance from 6000 - redline increased VE, so therefore I up the % in the VE table from 6000-redline.

Would that be a fair assessment?

Really the only 'issue' with MIVEC is it adds another layer of complexity to tuning the VE table...

 

Well using the g/rev axis method - when the air gets hot the g/rev is actually reduced. Thus timing would probably be increased.

Is this a bad thing? Or more importantly is this the wrong thing to do? Hotter air is more prone to pre-igntion, but that's hotter air with the same mass, what about hotter air with less mass? how does that affect the pre-igntion effect?

I agree its probably a good idea to have a coolant temp correction built in after the initial g/rev/rpm -> timing calculation has taken place - so that under extreme high coolant temps you can pull timing back a bit to protect the engine.

In regards to getting the ECU to use a 'new' load variable I don't think this will be too hard. I just had a quick look through the ECU for LOAD_RAW, LOAD_Baro, LOAD_Temp and LOAD_Baro+Temp and there isn't that many locations.

I haven't full thought through every implementation detail but worst case is we can write replacement Fuel and Timing routines, this might be a good thing...

 

There is a base load that all other loads are calculated from. I suppose the simplest answer here is to create a new "base" load from MAP, and then all other loads will be based on this. Whatever load (I forget if it is air temp compensated or not) is being used for ignition now will continue to be used. Takes all the guess work out of it.

 

Yeah but if our new base load is g/s or g/rev then its already taken into account temp - ie the new_base_load+temp is now double temp corrected.

Anyways that's not so important, I will work out the cheapest/easiest way of modifying the ROM once I have my IAT(CAT) in and g/s logging...

 

I am kind of newbie here, so maybe I am overseeing some important issues still.
But what about taking Z27W 4G15 or 4G19 JDM ECU and disassembling it? The only difference to EVO is the engine itself and it is MAP based, otherwise it has MIVEC, Turbo, but I am pretty sure that the the code would be helpful.

Basically if you are interested in the MAP controlled Mitsu ECU (non-MIVEC, non-Turbo, plain 4G15/4G18) I can provide this ROM to you.

 

OK - I think I fully understand the concepts of VE and Map/Temp derived mass of air.

Once this IAT arrives (Thanks again MR Turco) I will try and get some real numbers up and running.

I am leaning towards replacing all the load variables with one centralised variable that will be used in all the F+T maps.

Two questions on the VE table, some references I have seen VE > 100%, this doesn't make sense to me, the motor can't flow more air that's going into it?

Also can we start thinking about creating a VE table based upon logs from a MAF system? ie what formula can we come up with to populate the VE table at various rpm/map points based upon a MAF system?

 

can we use bez's map to maf scenario and log both the maf and the map emulated maf output? (factoring out the 10% offset we put to keep the ECU using MAF--still don't know exacly what he meant as i have no logs/ve adjustments/etc)then calculate the compensations later? might be ballparkish and not exact.

or did you want to come up with your own code?

i have not logged anything yet, so i don't know if the data will be pertinent. just a thought though.

 

Interestingly I have come up with a nice little formula to calculate grams per rev:

MAP (in Pascals) / Temp (in Kelvin) / ((1000/EngineSize (in Litres)/2897*1662.8944)

Now the above bit for a 2L engine translates to 287.0028 - What I will do because its a static formula is make EcuFlash code the 287.0028 by asking for an engine size.

ie I have multiplied it by 65536 to increase the resolution of the value... Seems to work pretty well.