@xxx.edu Fri Jan 6 12:24:46 1995 Date: Fri, 6 Jan 95 09:15:34 GMT @xxx.edu @xxx.za Subject: Majordomo file: list 'diy_efi' file 'archive_num_19' -- >From owner-diy_efi Thu Jun 30 01:37:31 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA29697; Thu, 30 Jun 94 01:37:31 GMT Received: from knuth.mtsu.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA29692; Wed, 29 Jun 94 21:37:26 -0400 Received: by knuth.mtsu.edu (Smail3.1.28.1 #17) id m0qJB85-000AWoC; Wed, 29 Jun 94 20:41 CDT @xxx.edu> @xxx. Lusky) Subject: Re: 16 x 16 lookup tables To: DIY_EFI Date: Wed, 29 Jun 1994 20:41:29 -0500 (CDT) @xxx.edu> from "Ciciora Steve" at Jun 29, 94 08:23:38 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1851 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Ciciora Steve writes: > Does anyone have any comments/suggestions to the above? Am I on the right > track? I'm not familiar with the details of interpolation, so I can't comment on that. However I do believe that an 8x8 map is very inadequate. 16x16 plus interpolation is what my EFI Techinologies ECU used. > In thinking about how a carb works, I would need a 'Modifier' for the EFI > equivilent of a choke on a carb (works off coolent temp?) and a modifier for > the accelerator pump (works off the rate at which the gas petal is being > pressed down). Besides for a ignition curve, what else would I need a lookup > table for? Okay, here are the curves that the EFI Technologies ECU I had used: Fuel (16x16) Spark (16x16) Temperature Sensor Linearization Injector Correction f(Throttle) Battary Offset Correction f(Battery Voltage) Transient Multiplier f(Watertemp) Injection Correction f(Air Temp) Injection Correction f(Water Temp) Spark Correction f(Air Temp) Spark Correction f(Water Temp) Injector phasing f(RPM) Except for the first three and the last one, all of those are multiplier tables. By that I mean the pulse width from the first two tables is multiplied by the value in the table for the given condition. In our setup, several of those curves were straight lines at 1 :). Acceleration encrishment uses a constant multiplier and a constant decay rate. There is also a minimum throttle position threshold for acceleration enrichment and a throttle position point for acceleration enrichment saturation. I believe accelration enrichment is scaled linearly between those two points (as a function of throttle position of course). Does this help any? -- @xxx.edu "Turbos are nice but I'd rather be blown!" 68 Camaro Convertible - 350 / TH350 80 Toyota Celica - 20R / 5spd >From owner-diy_efi Fri Jul 1 18:53:49 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA07995; Fri, 1 Jul 94 18:53:49 GMT Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA07990; Fri, 1 Jul 94 14:53:46 -0400 Date: Fri, 1 Jul 94 14:53:46 -0400 From: jsg (John S Gwynne) @xxx.edu> To: DIY_EFI Subject: basic fuel metering equations Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI -------- Before the discussion on lookup tables really gets going, I would like to make sure that I fully understand the basic concepts and equations needed to control the injector portion of this project. The following is a start on what I believe to be the relevant equations for a speed density system. If I'm not on track (check my math), please let me know and feel free to contribute. ************************************** 1 --- Injector duration Description of the control algorithm for injector duration. 1.1 --- Calculation of air flow: lb/hr of air The following describes the calculation of air flow (lbs/hr) as a function of the input parameters MAP, Ta, RPM 1.1.1 --- Constants and variables A_lb/hr: air flow in lb/hr MAP: Manifold Absolute Pressure (atm) (1 atm = 29.29 in (760 mm) of Hg) RPM: revolutions per minute (1/min) Sa: specific gravity of air at 0 deg C and 1 atm Sa = 0.0012929 gr/cc = 0.080713 lb/ft^3 Ta: air temperature (K) (T_in Kelvin = T_in Celsius + 273.15) Vd: engine displacement (ft^3) (i.e., 0.2025 ft^3 for 350 cu. in.) %VE: the volumetric efficiency 1.1.2 --- Equation A_lb/hr = (Sa) X (temp & pressure correction factor, assuming ideal gas) X (engine displacement) X (RPM/2) X (%VE) A_lb/hr (lb/hr) = Sa (lb/ft^3) * MAP/1 () * 273.15/Ta () * Vd/2 (ft^3) * RPM (1/min) * 60 (min/hr) * %VE () A_lb/hr = (661.4 * Vd) * MAP / Ta * RPM * %VE comments: - the 2 in Vd/2 is for a 4-stroke engine. - %VE is primarily a function of MAP and RPM. - (661.4 * Vd) is a constant for a given engine. 1.2 --- Calculation of fuel rate: gal/hr of fuel >From the equation in section (1.1.2), the fueling rate can be found as a function of air-fuel-ratio (AFR). 1.2.1 --- Constants and variables AFR: Air fuel ratio F_gal/hr: fuel flow rate in gal/hr Sg: specific gravity of gasoline Sg = 0.74 gr/cc = 46 lb/ft^3 1.2.2 --- Equation F_gal/hr = (air flow lb/hr) / (air fuel ratio) / (specific gravity of gas) X (gal/cubic feet) F_gal/hr (gal/hr) = A_lb/hr (lb/hr) / AFR () / Sg (lb/ft^3) * 7.481 (gal/ft^3) F_gal/hr = 0.1626 * A_lb/hr / AFR Substituting the above equation for A_lb/hr gives, F_gal/hr = (107.6*Vd) * MAP * RPM * %VE / Ta / AFR where (107.6*Vd) is a constant and %VE is primarily a function of MAP and RPM. While this is the basic equation needed to control the injector duration, the terms should be grouped and normalized in such a way as to make programming the CPU easier (i.e., the terms MAP, RPM, and %VE could be combined into one lookup table as a function of MAP and RPM). 1.2.3 --- Determination of AFR The air-fuel-ratio should be 14.7:1 whenever the system is operating in closed-loop mode with the oxygen sensor. During conditions of starting, cold engine, cold O2 sensor, or power enrichment, the system should be operated open loop. Open loop AFR depends on coolant temperature, MAP, and RPM. (need more info here --- need to define the controlling algorithm) 1.3 --- Additional terms -- Acceleration Enrichment, Deceleration Enleanment, and Close-Loop Feedback 1.3.1 --- Acceleration Enrichment (AE) In the prototype controller, AE should simulate the accelerator pump of a traditional carburetor. That would make it an additive term to the equation of (1.2.2) that would add a pre-set quantity of fuel as a function of throttle change. Additionally, it would have an adjustable "decay parameter" that would be similar to the hole diameter of the "shooter". In the future, it may be beneficial to include MAP and coolant temperature into this term. For now, I will just represent it as a yet to be defined additive function of AE. (need more info here --- need to define the controlling algorithm) 1.3.2 --- Deceleration Enleanment (DE) I don't believe this term is necessary in the first prototype of our controller. Ultimately this term will lean the engine during deceleration much as the acceleration enrichment term adds fuel during acceleration. It should have the same inputs as the acceleration term. 1.3.3 --- Close-Loop Feedback (CLF) This should be a multiplicative term representing the integrated error from the oxygen sensor. The conditions for when this term should be included are yet to be defined. Conditions to consider are cold O2 sensor, cold engine, acceleration, deceleration, power enrichment. (others?) (need more info here, need to define the controlling algorithm) 1.4 --- The overall fuel delivery equation. F_gal/hr = (107.6*Vd) * MAP * RPM * %VE / Ta / AFR * DE * CLF + AE In this equation, MAP, RPM, and Ta are engine parameters measured directly. (107.6*Vd) is a constant. %VE is experimentally determined as a function of MAP and RPM. DE and AE depend on MAP, TPS, and coolant temperature. CLF is a function of the O2 sensor input. AFR is a function of crank (starting), cold engine, and power enrichment. 2 --- Idle Air Control TBD 3 --- Spark Timing TBD ****************************************** This is getting lengthy... Will expanding this help anyone? Someone want to start an input/output description or a software description? John S Gwynne @xxx.edu _______________________________________________________________________________ T h e O h i o - S t a t e U n i v e r s i t y ElectroScience Laboratory, 1320 Kinnear Road, Columbus, Ohio 43212, USA Telephone: (614) 292-7981 * Fax: (614) 292-7292 ------------------------------------------------------------------------------- >From owner-diy_efi Fri Jul 1 20:18:35 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA08865; Fri, 1 Jul 94 20:18:35 GMT Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA08860; Fri, 1 Jul 94 16:18:33 -0400 Date: Fri, 1 Jul 94 16:18:33 -0400 From: jsg (John S Gwynne) @xxx.edu> Apparently-To: diy_efi Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI (Message jsg:191) Received: from wotan.compaq.com by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/lib/mh/slocal -user jsg id AA08327; Fri, 1 Jul 94 15:13:45 -0400 Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp (Smail3.1.28.1 #6) id m0qJnzI-0002e0C; Fri, 1 Jul 94 14:11 CDT Received: from bangate.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #8) id m0qJnzI-000pdAC; Fri, 1 Jul 94 14:11 CDT @xxx.com> Received: by bangate.compaq.com with VINES ; Fri, 1 Jul 94 14:10:55 CDT Date: Fri, 1 Jul 94 14:09:37 CDT @xxx.com Subject: re: basic fuel metering equations To: twisto.eng.hou.compaq.com!wotan!coulomb.eng.ohio-state.edu!owner-diy_efi Cc: @xxx.edu (John S Gwynne) Wrote: [article about injection equations deleted] instead of calculating mass airflow from rpm, shouldn't an airflow sensor be used? --steve >From owner-diy_efi Fri Jul 1 20:36:17 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA09132; Fri, 1 Jul 94 20:36:17 GMT Received: from knuth.mtsu.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA09127; Fri, 1 Jul 94 16:36:14 -0400 Received: by knuth.mtsu.edu (Smail3.1.28.1 #17) id m0qJpNe-000AWHC; Fri, 1 Jul 94 15:40 CDT @xxx.edu> @xxx. Lusky) Subject: Re: your mail To: DIY_EFI Date: Fri, 1 Jul 1994 15:40:13 -0500 (CDT) @xxx.edu> from "John S Gwynne" at Jul 1, 94 04:18:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1124 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI @xxx.com > Subject: re: basic fuel metering equations > [article about injection equations deleted] > > instead of calculating mass airflow from rpm, shouldn't an airflow sensor > be used? > > --steve Thats a classic debate. Mass-air based systems are generally easier to tune than speed-density system. However, a mass airflow sensor is a restriction in the intake path. Traditionally, mass airflow sensor have also been quite expensive. The aftermarket scene for 5l mustang has changed that for some sizes of MAF sensors, though. Still, the MAF needs to be roughly sized to the airflow requirements of the engine. >From what I understand at high flowrates the accuracy of MAF sensors is pretty bad. Bottom line is that MAF costs more and doesn't work as well at WOT... compared to well tuned speed-density systems. The question to ask is does the esier tuning outweigh its other disadvantages? -- @xxx.edu "Turbos are nice but I'd rather be blown!" 68 Camaro Convertible - 350 / TH350 80 Toyota Celica - 20R / 5spd >From owner-diy_efi Fri Jul 1 20:37:30 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA09216; Fri, 1 Jul 94 20:37:30 GMT Received: from eigen.ee.ualberta.ca by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA09210; Fri, 1 Jul 94 16:37:27 -0400 @xxx.edu> Received: by eigen.ee.ualberta.ca (1.37.109.4/15.6) id AA18936; Fri, 1 Jul 94 14:37:24 -0600 @xxx.ca> Subject: Re: basic fuel metering equations To: DIY_EFI Date: Fri, 1 Jul 94 14:37:22 MDT @xxx.edu>; from "John S Gwynne" at Jul 1, 94 2:53 pm Mailer: Elm [revision: 70.85] Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI > In the prototype controller, AE should simulate the accelerator pump of a > traditional carburetor. That would make it an additive term to the equation > of (1.2.2) that would add a pre-set quantity of fuel as a function of > throttle change. Additionally, it would have an adjustable "decay parameter" > that would be similar to the hole diameter of the "shooter". In the future, > it may be beneficial to include MAP and coolant temperature into this > term. For now, I will just represent it as a yet to be defined additive > function of AE. (need more info here --- need to define the controlling > algorithm) It's actually pretty important to have the 'shooter size' and 'decay rate' controlled by engine temperature. I've seen systems that have two accel pumps: one for delta MAP and the other for delta throttle. Ideally, you would model the fuel thickness in the intake manifold between the injector and valve, which would require air temp, manifold temp, manifold vacuum/pressure, and probably an estimation of the willingness of the air to accept the gasoline as a vapour. This is something for someone who has done research on this area... if you can model it, you don't have to spend as much time tuning... > 1.3.2 --- Deceleration Enleanment (DE) > > I don't believe this term is necessary in the first prototype of our > controller. Ultimately this term will lean the engine during deceleration > much as the acceleration enrichment term adds fuel during acceleration. It > should have the same inputs as the acceleration term. Exactly. Just acceleration enrichment turned around. It only adds about fifty or so lines in my code (assembler). Makes a big difference when you're coming out of a corner and you don't have to let the engine cough out the raw gas it sucked in on the overrun. > 1.3.3 --- Close-Loop Feedback (CLF) > > This should be a multiplicative term representing the integrated error from > the oxygen sensor. The conditions for when this term should be included are > yet to be defined. Conditions to consider are cold O2 sensor, cold engine, > acceleration, deceleration, power enrichment. (others?) (need more info here, > need to define the controlling algorithm) Actually, I've seen it done as a combined additive and multiplicative term. The short-term feedback (oscillator) is additive, the long term (block-learn) is multiplicative. I guess this simplifies control calculations... Most FI software I've seen has a lot of compensation for the temperature effects on the O2 sensor. A lot of engine control software attempts to predict the temperature of the exhaust and the exhaust system components to compensate for this. I thought it was wierd, too... -Dale >From owner-diy_efi Fri Jul 1 23:19:48 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA10870; Fri, 1 Jul 94 23:19:48 GMT Received: from aztec.al.bldrdoc.gov by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA10865; Fri, 1 Jul 94 19:19:38 -0400 @xxx.edu> Date: 1 Jul 1994 17:23:23 -0700 @xxx.gov> Subject: FW: basic fuel metering equations @xxx.gov Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI John Writes: _______________________________________________________________________________ Before the discussion on lookup tables really gets going, I would like to make sure that I fully understand the basic concepts and equations needed to control the injector portion of this project... (snip) ...This is getting lengthy... Will expanding this help anyone? Absolutly!! I'm suprised that this type of discussion has not come up before. Although I'm not as good of a writer as you, I have tried to point the discussion in this direction. Two of my attempts got completly scrambled by sending them from New Zealand. What I'm hoping is that we can lay out the project on the table (like your outline) and goups can work on sorting out small portions. Like calculating the density of air from MAP and intake temp. Or how to do a look up table. This way the project can be broken up into manageable chunks. Below is my first pass at explaining my understanding of fuel injection systems. Not as complete as yours, and mabe not as clear, but from a slightly different view point. Damn! I can't figure out how to 'cut and paste' text in Microsoft Mail, so I'll have to wait until tuesday to post my explanation of calculating air density. This is geting more into implementation rather than theory, but how are we going to scale the input sensors? We could scale them in software or hardware. The hardware method would be more universal but less elagant. What we could do is scale the MAP and temp sensors to output 0-5V in the range of interest (simple inst. amp circuit for gain and offset, can be done in one quad op-amp). The software black box will take MAP and Temp numbers from the A/D converter (of the range of 0->255) and convert them to a air density number of the range of 0->255 (arbatrary units). The reson for not using calibrated units is to keep maximum resolution in the minimum # of bits. It would be wastefull to measure temperature over the range of -50 -> 300 deg. F just because we can. Similar with MAP. The range of values I see for MAP/Temp are different for my engine/altitude than it is for your engine/sea level. The other way I see of doing things is the software scaling method. What we can do is use a 12 bit A/D converter and measure the entire useful range of the sensors (-50 -> 300 deg F and all). This 12 bit number can be scaled down to a more usefull range for the software. Or, heck, we could just do it all in floating point and not wory about range/resoultion! (joke) :-) Am I making myself clear enough or just rambling on? - Steven Ciciora >From owner-diy_efi Sat Jul 2 00:23:39 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA11055; Sat, 2 Jul 94 00:23:39 GMT Received: from eigen.ee.ualberta.ca by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA11050; Fri, 1 Jul 94 20:23:36 -0400 @xxx.edu> Received: by eigen.ee.ualberta.ca (1.37.109.4/15.6) id AA21141; Fri, 1 Jul 94 18:23:33 -0600 @xxx.ca> Subject: Re: FW: basic fuel metering equations To: DIY_EFI Date: Fri, 1 Jul 94 18:23:31 MDT @xxx.edu>; from "Ciciora Steve" at Jul 1, 94 5:23 pm Mailer: Elm [revision: 70.85] Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI > Or how to do a look up table. This way the project can be broken up into > manageable chunks. Below is my first pass at explaining my understanding of > fuel injection systems. Not as complete as yours, and mabe not as clear, but > from a slightly different view point. Damn! I can't figure out how to 'cut > and paste' text in Microsoft Mail, so I'll have to wait until tuesday to post ... > do is scale the MAP and temp sensors to output 0-5V in the range of interest >(simple inst. amp circuit for gain and offset, can be done in one quad op-amp). Most automotive sensors are designed to run off of +5 volts or so and produce a single-ended 0-5 volt analog signal. You can normally take this signal, run it through a simple R-C right to the A-D port. The only sticky point is the engine temp sensor (or other thermistors). They need a pullup resistor which depends on the manufacturer. I have the calibration for a GM sensor with a 1k pullup on it. It's at home, though, and I'm no there... > The software black box will take MAP and Temp numbers from the A/D converter > (of the range of 0->255) and convert them to a air density number of the range > of 0->255 (arbatrary units). The reson for not using calibrated units is to > keep maximum resolution in the minimum # of bits. It would be wastefull to > measure temperature over the range of -50 -> 300 deg. F just because we can. > Similar with MAP. The range of values I see for MAP/Temp are different for my > engine/altitude than it is for your engine/sea level. Normally, the range you see is no problem for anywhere in the world. MAP will usually be between 110 kPa and 20 kPa. An arbitrary assignment of 2 units per kPa linearizes to 0 kPa to 127.5 kPa, which is quite reasonable for natural aspiration. This can be trimmed in software quite easily. For turbo/blower applications... you be the judge. Just scale everything to be bigger.... :-) > The other way I see of doing things is the software scaling method. What we >can do is use a 12 bit A/D converter and measure the entire useful range of the >sensors (-50 -> 300 deg F and all). This 12 bit number can be scaled down to a If you use automotive sensors, they have been designed with the correct operating ranges already. Go with them! eg: Temp -40C to +150C, MAP 20 to 110, etc. Hmmm... good idea, but 12 bits in a car??? I dunno. Maybe 10 if you're lucky. If you're deciding on am MCU with on-board A-D, 8 bits is what you normally get in a package, and I haven't had much luck trying to go more accurately without expensive filtering. As it is, an 8-bit converter picks up enough noise that it has to be filtered in software. This is especially true of O2, which is a high-impedance signal. Also, MAP contains a lot of engine pulsations, which must be filtered out intelligently to avoid aliasing effects but also avoiding long lag times. Just filtering MAP is not trivial. Same with fast MAF sensors, so that's not an easy way out... 8 bits is a nice trade-off, as it also fits in half the memory that any other bit count takes... -Dale ÿ