2ndGearRubber

I've been looking into MegaSquirting my 99, but one thing keeps jumping out at me. When tuning, it seems as though the end user needs to spend a bit of time creating maps. For fuel, spark, etc. From what I understand, the ECU references these maps based on external air conditions, and then decides how to implement fuel and spark.

So, for an air density of 29mm/Hg (approx. air pressure at sea level at 0* C), the ECU would determine the density of the air with a sensor, and then reference the maps to decide spark and fuel requirements, correct?

When investigating tuning, I can't help but question why this method is used. When calculating the trajectory of a cannonball over a given distance, one could simply plug in a set of values into a formula, and calculate the answer backwards, since the desired outcome is already known. Couldn't the same approach be used for engine tuning?

I'm not sure if the stock mass air flow sensor would be up to the task, but couldn't one use an improved unit to deliver detailed air density information to the MegaSquirt? Then the ECU could calculate the correct fuel and spark ratios to create a desired AFR; assuming fuel octane, pressure, and spark characteristics remain constant. I'm not saying I would know how to write code for this, or even figure out how to derive the formula. I'm just a grease monkey who can't wrap his tiny mind around this whole "electricity" thing.

I doubt it would be as perfect as cell by cell tune by a professional. But couldn't be a basic tuning option? Or would this require too much computing power for the constant air fluctuations?

cr_sti

iTrader: (1)

Yep

You've confused pressure and density, as well as inches and millimeters.


You could tune as you describe if everyone lived at sea level, the temperature never varied, pump gas was identical, and all mechanical/electronic parts were made to and could maintain exact tolerances. Unfortunately, some intercoolers are more efficient than others, injectors vary, etc etc etc..

How about this, calculate where that cannon ball will land if I don't give you the mass or speed of the ball, the wind speed or direction, and all you have is gravity as a constant. . . Good luck

2ndGearRubber

Assuming one could gather information via sensors about barometric pressure, temp, octane, injector pulse, etc. could it work? Maybe take a conservative approach to octane (tune for 89, run 91) and such, kind of like reflash tuning?

At this point though, the cost of sensors alone would begin to approach dyno time.

Miater

You've stumbled onto a MEGAsquirt at this point. In which case you will tune it just as everyone else.

Faeflora

iTrader: (2)

Yup sure you could tune by formula.

But.

There are lots of variables that you will miss factoring in.

But

You can give yourself good starting points.

Or you could save the math and just copy someones elses settongs

devin mac

iTrader: (2)

The newer GM ecus like in the camaro are all equation based and table-less, if i am not mistaken.

Braineack

iTrader: (62)

autotune tunes by formula for you...

2ndGearRubber

Sounds good to me.

Joe Perez

iTrader: (8)

The idea of formula-based, rather than table-based computation of things like fuel delivery is not new. And as Devin Mac inferred, OEMs are indeed beginning to employ it.

It's also not necessary to assume that things such as air temperature, barometric pressure, and so on are constants, contrary to what cr_sti implies. In fact, these are the precise variables which, in nearly all existing ECUs, are already corrected for using a formula-based mechanism, albeit an extremely simple one. Taking air temperature, for instance, we might construct a formula which says "For every degree above 60°F, decrease the computed fuel by 0.x%, and for every degree below 60°F, increase the computed fuel by 0.x%." It's quite primitive, but it meets the definition.

The problem in using formulae, rather than lookup tables, to compute the base load numbers (base fuel, base ignition advance) is complexity.

In a table-oriented system, we can simply create a rough table of values, based on simple algebra or even just an educated guess, and then run that table on the engine to see how it performs. Assuming that the table requires correction, we can just adjust the numbers in the table until the engine is operating as desired. In the case of the fuel table in particular, this fine-tuning can be done for us automatically by the ECU in real-time, using a method similar to LTFT on an OEM ECU. The computer simply takes feedback from the EGO sensor, compares it to a table of desired AFRs, and says "Ok, I am running lean in this cell. Let me start increasing the value of this cell in 1% increments until the reading from the EGO sensor is identical to what I see here in this table of desired AFRs."

In other words, it's very easy for a normal person to do.

In a formula-oriented system, however, it is necessary to model the expected dynamic behavior of the engine to a very high degree of precision before you ever turn the key. Lots of finite element analysis using integral and differential calculus. This type of modelling is within the reach of automakers who employ large staffs of degreed and experienced scientists and engineers, with complex software and powerful supercomputers at their disposal. And even at that it is a highly iterative process, involving testing and adjustment to the software models which go far beyond simply increasing or decreasing the value of a number in a cell in a lookup table.

This is well outside the capability of your average car enthusiast with a laptop.


Which of course brings us to the question of cost vs. reward. I'm sure that there must be some benefit to this method of engine operation, or else OEMs would not be spending money to research it. On the other hand, table-based systems have been proven to work quite well over the past 30 years, both in the aftermarket and in the much more stringent domain of the OEM. I suspect that, within the aftermarket community, you will see little motivation to adopt any formula-based method of primary load computation until a compelling argument is made to justify such a massively complex undertaking.



This actually makes me realize something which had never really occurred to me before, at least not in these terms. The very earliest mass-marketed EFI systems, such as the Bosch D and L-jetronic systems of the 1960s and 70s, were by definition formula-based systems. They had to be, since they relied upon analog computation. The formulae, so to speak, existed in the form of resistors and capacitors hard-wired into comparators and oscillators, which might seem primitive to us now, but at the time still represented a viable (though shrinking) segment of mainstream computing in the commercial sense.

Techsalvager

2ndgear its the nature of speed density.
You can use Mass air flow with megasquirt if you want and it is way easier and faster to tune in a working engine then a speed density setup.

Both ms2extra and b&g ms2 firmwares support MAF based fueling.

Many, probably all OEM ecus still have failure modes to various types of setups, most new GM vehicles will have maf and map, can fall back to running speed density if it deems the maf is broken or if you disconnect the maf.

M2Ken

Electromotive has been doing this since the TEC-II days, they call it linear thermodynamics. MAP, Time on for Gama (TOG), Injector Offset Time (IOT), and there you have formula based fuel calculations.

Faeflora

iTrader: (2)

So if everything is in closed loop all the time, what about the closed loop performance inpact?

Is it nullified by fast processors and hysterisis?