programming for a MAF based system

[les]

Perry,
I was under the impression that the MAF sensors , because of the way the
air 
molecules are being measured by the hot wire, already compensate for the
thin air encountered at altitude. 
Also, my whole reason of going to MAF instead of speed density was to
avoid
the whole VE mess. You need VE for a speed density system, because it
has no
idea of the actual grams/sec air going into the motor. It only has a
'guess'
that when combined with the VE at a particular RPM results in a more 
accurate air intake amount.

I'd like to richen the mixture under boost, and I think I can do that
based on the table that I would use for the MAF, with an rpm lookup.

My system will run a turbo air-cooled VW engine, and for now I want to 
keep the ignition out of ECU, or maybe just provide an analog voltage to

a Crane ignition system, to retard under load. Keeping it as simple as
possible means that I would actually build it, and it would still be
better than a carb, I would think :-)

My biggest concern is that I don't know the output curve for the Bosch
MAF I have. I can always get the engine running at idle by adjusting
a rich-lean knob I would have as an analog input to the ECU, as a tuning
aid. But I don't want to have to define the curve by a trial and error
method, all the way up the curve, it's too tricky. maybe I can assume
it's a hyperbolic curve, and start with that?

Thanks for the info, I'm learning more each post!

-Les



> -----Original Message-----
> From: owner-diy_efi at diy-efi.org 
> [mailto:owner-diy_efi at diy-efi.org] On Behalf Of Perry Harrington
> Sent: Tuesday, March 26, 2002 12:12 AM
> To: diy_efi at diy-efi.org
> Subject: Re: programming for a MAF based system
> 
> 
> Hello,
> 
> I'm new to the list, so if you're perplexed as to who I am, 
> that's why.
> 
> For a MAF system you want MAF, TPS, ACT, BAP, ECT, ISV, and 
> RPM. Here's the reason:
> 
> You want to reference MAF to RPM to infer VE.  Once you know 
> VE, you can key in a table, just like MAP does.  The other 
> reason is because you can make an even simpler inference:  
> Have a global that defines your lb/hr per HP.  With the MAF 
> vs RPM you can calulate realtime HP and use that to simply 
> find your base fuel pulswidth.
> 
> This makes for very simple integer math with table lookups if 
> you want.
> 
> Then add the O2 sensor to fine tune the mixture.
> 
> The other sensors I'd use are BAP (baro), constantly to 
> adjust for altitude, ACT for additional spark advance and air 
> density, and ECT for input to lean/richen the mixture so as 
> to obtain the desired engine temp. The BAP is important 
> especially on turbo cars, because turbos were intended for 
> altitude compensators.
> 
> Ford uses the ACT for advance, ECT vs VE for AFR, and BAP to 
> compensate for altitude.
> 
> I postulate that it is possible to design a fuel injection 
> computer and program that will tune an engine without user 
> input, just give it gross values and it'll fine tune it.  The 
> only thing I'd add to do that is an engine mounted 
> accelerometer and MAP sensor.
> 
> The accelerometer would be used to sense the roughness of the 
> engine, and the MAP to sense vacuum; so you can adjust the 
> mixture like you would with a conventional vacuum gauge.  
> Find the mixture that provides the smoothest idle and highest vacuum.
> 
> --Perry
> 
> On Thu, Mar 21, 2002 at 03:15:38PM -0500, Eric Fahlgren wrote:
> > les wrote:
> > > 
> > > Can someone point me to any hints for how to approach the 
> algorithms 
> > > for fuel calculations, as they apply to a mass air flow measuring 
> > > fuel system?
> > > 
> > > At first look, it seems that all the 'normal' variables 
> needed for 
> > > MAP systems just drop out of the equation. I suppose that I still 
> > > need a 2d map , to allow for richening under boost, but it just 
> > > seems too simple. I mean, other that for idle speed needs, rpm 
> > > doesn't even seem to enter the equation. Air mass is air mass. I 
> > > understand that the MAF is not linear, but a simple lookup table 
> > > should fix that.
> > 
> > Les,
> > 
> > Are you working with a true _MASS_ air meter, not an AFM which 
> > produces some uncorrected value?  In that case, just have a 1D map 
> > which relates mass to AFR and from that calculate a pulse 
> width.  If 
> > not, you need temperature correction (at least) to get 
> mass, then use 
> > the table.  Should be pretty simple compared to the 2d VE tables 
> > usually used with speed density.
> > 
> > All the usual gamma terms still apply same as with MAP systems, 
> > acceleration enrichment, cold start/warmup and so on.
> > 
> > Eric
> > 
> > ----- End of forwarded message from owner-diy_efi at diy-efi.org -----
> > 
> ----------------------------------------------------------------------
> > ------
> > To unsubscribe from diy_efi, send "unsubscribe diy_efi" 
> (without the quotes)
> > in the body of a message (not the subject) to 
> majordomo at lists.diy-efi.org
> 
> -- 
> Perry Harrington             Linux rules all OSes.            
>    APSoft      ()
> perry at apsoft dot com 			                
>  Think Blue. /\
> 
> Those who would give up essential liberty to purchase a 
> little temporary safety deserve neither liberty or safety. 
> Nor, are they likely to end up with either.
>                              -- Benjamin Franklin
> 
> ----- End of forwarded message from owner-diy_efi at diy-efi.org -----
> --------------------------------------------------------------
> --------------
> To unsubscribe from diy_efi, send "unsubscribe diy_efi" 
> (without the quotes) in the body of a message (not the 
> subject) to majordomo at lists.diy-efi.org
> 
> 

----- End of forwarded message from owner-diy_efi at diy-efi.org -----
----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org