Fuel calcs

Official FreeEMS vanilla firmware development, the heart and soul of the system!
gearhead
LQFP112 - Up with the play
Posts: 120
Joined: Sun Feb 03, 2008 9:30 pm
Location: Chicago, USA

Fuel calcs

Post by gearhead »

Fred asked if I could start this. So, I did a bit of research on Speed Density calculations.

I do not know what variables are defined, yet, but wanted to start as a discussion, move to pseudo code and then C. I am not well versed in C at all. I did learn a few things, though, about these calculations. If we want true 0.001ms resolution, we need to carry 16 bit inputs, 32 bit calcs and output16 bit.

Also, scaling. Fred asked me a bout this a while back. We want to make sure that the scale of teh output makes sense in engineering units as well. This means we need to 'pre calibrate' the variable. With 8 bit variables, this would be 0-255 = 0-25.5ms. With 16 bit it is 0-65536 = 0-65.536ms> If I understand how the other variables are acquired, they are all 10 bit. So for the calcs to make sense, we need to get these all in the same scale so teh calcs make sense. I do not know if this has been thought of, but I recommend that all variables be 16 bit internally to be consistent within the code.

We will have corrections to fuel trim of which are all based on 100%. We can use 50% of the total range of 32768 as equal to 100% These variables are:
Accel(decel)
Warmup/ASE
EGO
Air Density
Voltage correction

We will also have a
base PW (reqFuel)
Opening time
VE
MAP
To calculate fuel PW

Megasquirt also uses Air Density correction and Barometer correction terms. I think the barometer correction is not necessary if the fuel load is calculated as a percentage of total load based on 100. IE, if barometer reads 90kpa, 100% is 90 kpa. 100 kpa is 111%. This should auto correct for altitude. Air density is necessary for heat soak requirements.

I'll start on something, but wanted to get this out for comment, first.

Gearhead
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fuel calcs

Post by Fred »

Thanks for starting the thread Gearhead.

Isn't this exactly how they do it in the MS code? The patented MS code?

We need to start from first principles. I'm not convinced a "base pulsewidth" is the best way to approach this anyway.

I'd like to see all the variables and processes required laid out and analysed such that we can show our "working" if we need to.

I realise that every ECU since 1974 has done the math and done it similarly to this, but we need to develop it on our own independently however difficult and/or tedious that may be.

For example, the map sensor reading comes in as a 0 - 1023 number representing 0 - 5v which needs to be transfered to a map reading through some function or other such that the core calcs can remain accurate regardless of 4bar or 1bar sensor.

Same for the bias/transfer charts for the Inlet Air Temp and Coolant Temp/Head Temp (not restricted to water cooled engines).

Same with battery voltage readings.

How these end up looking after that transfer process in terms of scaling and what that means in terms of range checking/handling etc, I don't know right now. I for one would like a full understanding of that before we put keyboard to code.

Thoughts?

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fuel calcs

Post by Fred »

Additionally,

opening time, no, injector dead time, yes (it affects both ends)

By air density I assume you mean air temperature? That is not a correction, it's integral to the equations.

Voltage correction shouldn't be required as the "injector dead time" will be directly mapped from a table to a time with no calculation to be done except a single ADD at the end.

You have forgotten that we are going to be using VE as VE and not some hack. Thus we need AFR integral to these calcs too (even if some users never use it).

Accel enrich, no, transient enrich, yes.

Transient, warm up and after start ARE corrections to something, but what? It might matter in some subtle way where they are multiplied or added in.

EGO (if/when used) is a correction on VE/AFR alone or on final pulsewidth (which seems like a hack, but maybe is less of a hack because we don't know where the error is coming from).

If we max out two 16 bit words with 0xFFFF and multiply we get a number VERY close to max for the 32 bit long so we'll have to be careful with things anyway.

http://www.google.com/search?hl=en&q=0x ... FFFF&meta=

Right, someone elses turn :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
austinbob
DIP8 - Involved
Posts: 29
Joined: Fri Jun 06, 2008 3:46 pm

Re: Fuel calcs

Post by austinbob »

EDIT :
EDIT wrote:I know a little bit about the speed density fuel calculation.

Once you know the mass of fuel you can calculate the injector pulse width required to deliver this mass of fuel from the injector flow rate given in gm/sec.

This is from memory and I have not taken into account using the correct units throughout....
ORIGINAL wrote:I know a little bit about the speed density fuel calculation.

The mass of air is calculated from an equation that looks like this

massAir = DensityAir*VolumeAir

DensityAir = pressure/(R*temperature) where R is a constant

pressure is from map sensor
temperature is from air temp sensor

VolumeAir = Displacement*VolumetricEfficency

so

massAir = pressure*displacment*VE/(R*temperature)

VE is updated using an afr sensor

VE(n+1)= VE(n)*AFR_DESIRED/AFR_MEASURED

Let VE(n+1) = VE_CORRECTED

taking this into account...

massAir = pressure*displacment*VE_CORRECTED/(R*temperature)

Once the mass of air is known you can calculate the mass of fuel from

massAir/massFuel = AFR implies

massFuel = massAir/AFR

Once you know the mass of fuel you can calculate the injector pulse width required to deliver this mass of fuel from the injector flow rate given in gm/sec.

This is from memory and I have not taken into account using the correct units throughout....
I don't know if this is accurate or not, but I feel it wasn't right for him to remove this information so it can stay here now!

Fred.
Last edited by austinbob on Sat Jun 07, 2008 7:55 pm, edited 1 time in total.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fuel calcs

Post by Fred »

Thanks Bob,

The only issue I can see with doing things *exactly* per the text book is that divides are not our friend unless we implement fixed point libraries for each style of fixed point number we use or do the fixed point stuff explicitly during the calcs for each part. This is where the work/thought will come into it.

I think the front end at least for fuel flow and injector size will have to be cc/min or lb/hour to approximate the gm/sec figure. No one knows what their injectors are in gm/sec :-)

We also need to use fuel type (alcohol/petrol/etc) in the front end maybe and lambda instead of AFR internally to avoid issues when swapping fuels etc and keep it nice and generic from the start.

I'm not sure what the solutions to these issues are, but they must exist and we will find them :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
austinbob
DIP8 - Involved
Posts: 29
Joined: Fri Jun 06, 2008 3:46 pm

Re: Fuel calcs

Post by austinbob »

Why are divides not our friends? Are there no floating point number operations in the microprocessor?
austinbob
DIP8 - Involved
Posts: 29
Joined: Fri Jun 06, 2008 3:46 pm

Re: Fuel calcs

Post by austinbob »

I have a motorcycle. I know that injector flow rate for my injectors. They are 4.22 gm/sec.

If you know the manufacturer of your injector you can find the flow rate in gm/sec.
gearhead
LQFP112 - Up with the play
Posts: 120
Joined: Sun Feb 03, 2008 9:30 pm
Location: Chicago, USA

Re: Fuel calcs

Post by gearhead »

gearhead
LQFP112 - Up with the play
Posts: 120
Joined: Sun Feb 03, 2008 9:30 pm
Location: Chicago, USA

Re: Fuel calcs

Post by gearhead »

The fixed vs floating is what I was referring to as well. We do not want to have floating calcs if we can avoid it. With 16 bits of resolution, we do not have to, but need to split the value where we need to in order to get the value we need. Hence the 65.536 ms represented in code as 65536 or FFFF.

KeithG
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fuel calcs

Post by Fred »

That's correct Bob, no (efficient/hardware) FP math.

Gearhead : 65536/0xFFFF = 52.4288ms but close enough :-)

It's also artificially limited slightly for stability reasons but more than 50ms should be easily doable.

This is the sort of stuff we need to hash out in detail pre any code being written really.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply