Fuel calcs

[shameem]

Those equations are for ideal gas with idea flow - it might be a good starting point but it will never be perfect. For example - just the addition of water vapor (humidity) will alter the equation radically - since "R" and "P" are not same for air and water. Also altitude corrections would throw off the formula a great deal.... Not to mention the chaotic flow and back pressure propagation....

I guess this is why most modern engine controllers use Mass Air Flow sensor....

[austinbob]

EDIT :

The speed density does work. Corrections for humidy can be added.

The speed density does work. Corrections for humidy can be added.

My focus is on the motorcycle and there are no mass air flow sensors for motorcycles and probably never will be. The speed-density caclucation is an approximation to that.

However, all of this is mute if the processor isnt fast enough to calculate it.

I am not an expert in microcontrollers , that is one of the reasons I am here, I would like to learn how to program them, however, with a 40Mhz clock doesnt that mean that an instruction can be executed every .025 micro seconds or every 25 nanoseconds? I know for my motorcycle the crank position sensor at 6000 rpm would have a period of about 10 milliseconds. If the engine time scale is milli seconds and the processor time scale is nanoseconds then I dont thnk there should be a problem with doing the division. And if there were, that code could be optimized somehow in the assembler.

Very interested in what you guys reply to this.

Why he edited that out I will never know...

Fred.

[Fred]

I was discussing humidity with Sean the other day. I found this chart :



Which means that at 50C which is insanely hot and 100% relative humidity which is insanely wet you will be around 10% rich or so. Or do I read that chart wrongly/fail to understand the math/physics behind it?

Other than that, we can deal with it one way or another. Altitude/barometric pressure has a significant effect, but isn't a killer for most users, and if the ability to tune it out is there, shouldn't hurt anyone. I live close to water level for example and occasionally go as high as 1000m, but never much more than that. It shouldn't affect me much at all.

Is there anything else like humidity that is a pain/difficult to measure or infer?

Fred.

[austinbob]

Things like humidity correction could be added incrementally. It does not have to be present initially. I know from experience that speed-density works fairly well on my motorcycle without humidyt correction.

[Fred]

The speed density does work. Corrections for humidy can be added.

Can you explain how it is possible without a sensor, or only with a sensor?

However, all of this is mute if the processor isnt fast enough to calculate it.

It should easily be fast enough to do that and more, the fuel pulses are handled with hardware and ignition in software, although for a bike it could be worth reversing that for timing accuracy at VERY high rpm. We still don't know how accurate we can or can't be with ignition just yet as my code for that still has some known (and probably unknown) bugs in it. It should however be well less than 1 degree timing error at any rpm you can buy a real engine to spin at (not models).

I am not an expert in microcontrollers , that is one of the reasons I am here, I would like to learn how to program them, however, with a 40Mhz clock doesnt that mean that an instruction can be executed every .025 micro seconds or every 25 nanoseconds? I know for my motorcycle the crank position sensor at 6000 rpm would have a period of about 10 milliseconds. If the engine time scale is milli seconds and the processor time scale is nanoseconds then I dont thnk there should be a problem with doing the division. And if there were, that code could be optimized somehow in the assembler.

The only real interest in doing the math fast is the one of doing it often at higher revs and very close to the event at lower revs. All calculations are intended to be synchronous, however at some reason there just won't be time to do it for every firing event regardless of how good the code is. We can definitely make a functional ECU with what we have, but I'm a bit of a perfectionist, so would like to make it not only functional but also bloody good! :-)

I hope that answers your questions sufficiently. I have to apologise for the delay, but the lady made me go for a walk with her while I was writing this.

Fred.

[austinbob]

I would not be here if I wasnt interested in making something good. However , with engine control systems being a perfectionist can be a problem. It is better to think of the engine dynamics as a statistical process. There will be error in everything that is done.

[Fred]

Let me rephrase for you "pragmatic perfectionist" (I forget who I stole that from).

Fred.

[shameem]

Say the intake charge has 90% air and 10% water vapor - the MAP sensor will read an equivalent pressure (Pa+Pw) and the temperature reading is T.
The actual density equation in this case should be -
D= (Pa/Ra * T) + (Pw/Rw * T)

But we do not have "Pw" reading (from MAP) all we have is (Pa+Pw) reading - thats what i meant by changing equations....

Also since 10% of the volume is now taken up by non-combustible water vapor the volumetric efficiency changes a bit too (i think).

Temperature measurement at altitude is based on lapse rate -
T= T0 +L*height
and density equation at an altitude should include molar mass ......

Maybe i am just reading too much into this - maybe an approximation would work fine for most applications.....

[austinbob]

EDIT :

Change in ve.

The change in volumetric efficency is handled by the afr sensor. The afr sensor is used to correct the volumetric efficencies.

Not overly useful, but put back on principle.

Fred.

[austinbob]

I think it is best to start with a basic model. You can always extend it. The basic model would neglect humidity. Once you get the basic model controlling an engine then you can improve upon it.