One of the drawbacks to mass air flow sensors
is the voltage is more or less proportional
to the cube of the mass air flow while engines
need fuel directly proportional to the mass air
flow. This is handled in most modern  EFI's by the look
up table.

As far as I can tell the ZBasic function Exp()
can get the cube root so in theory no look
up table is required. It is similar to a manifold
pressure based EFI system were manifold pressure
is more or less proportional to the mass air
flow. Unfortunately therein lie the problems
we see in tuning as manifold pressure can be
affected by a lot of things.

Here is the ZBasicexp() function.

Type  Function returning Single
Invocation   Exp(arg)
Parameter   Method    Type    Description
arg         ByVal     Single  The power of e to be computed.

This function returns the Single value corresponding
to the value e raised to the specified power. The
transcendental value e, upon which the natural
logarithm is based, is approximately 2.718.
This function is the inverse of the Log() function.

A "Single" data type is in the range of
approximately ±1.4e-45 to ±3.4e+38 and 0.0

In QB the form is (xxxx)^.5 is the square root
of xxxx.

(xxxx)^.333 is the cube  root of xxxx.

.5 and .3333 are the exponents.

So the exponent can be selected to linearize
the mass air flow sensor voltage out put.

I'll try this in ZBasic shortly,

I intend to use MAF as the basic means of
determining the correct fuel flow adjusted
by EGT based auto tune.

This is going to make tuning simple if not entirely
automatic if it works.

Paul Lamar




One of my varied jobs for 25 years was to create the software that
processed telephone call data from digital telephone switches.
My personal goal was to make the software as fast and reliable as
possible.
My benchmarks and competition came from off-the-shelf software for
vertical-market software providers that catered to the telecom
industr

It was common for processing software to display a counter-variable,
a telephone number, or some other indicator on the computer monitor
to indicate progress in processing telephone calls.
May popular software packages used in small companies such as ours
would process data at a surprisingly slow speed; you could read the
data being echoed to the screen.
The reason for the slow processing is that a huge number of lookup
tables are were required before the days of flat-rate pricing or
free-calling that is popular today.
Tables were required for Customers, product packages, rates,
discounts, geographic locations, geographical coordinates,
mileage-rates, Time-of-day rates, cities, countries, circuits,
telephone trunking, PIN numbers, CallerID, CallingCard#s, 800 #s,
etc.
Modern caching hard-drives have made accessing data tables much more
efficient, but it still requires a lot of time because lookup tables
often require large indexes to be used to first determine where to
find the required data.

I was able to come up with a number of shortcuts to speed up
processing which might work well in your systems.
My last "production" version of an old-fashioned telephone call
processing program would process 20,000 calls/second on my old
laptop computer.
The key to many of my shortcuts used the native 'substring' function
that is part of every computer language. It is usually very fast.  I
timed all my procedures and subroutines using a stopwatch to make
sure I was always using the fastest method.

Here is an example:

Define a string of voltage characters as "0.50 1.00 1.50 2.00 2.50
3.00"
Define a string of CFM    characters as "   2.61   11.56   30.86
63.91  116.79  221.50"

To find the CFM which corresponds to a given voltage (let's say
1.50)
we can use a substring search function to find that 1.50 is the
third value in the the string of voltage characters
and therefore 30.86 can be found in the third set of characters of
the CFM string.

Admittedly, there is some algebra involved, and the < or  is
required in the expression to find intermediate values
but I can say for certain that the method is very fast.

I have huge libraries of procedures in my archives that I could show
any who is interested.

In some circumstances, a binary-search of a table is faster,
especially if the table is huge,
but it requires that the table being searched be either continually
increasing or continually decreasing.


Robin Berglund

Thanks for the ideas Robin. Some of those string
functions are built into ZBasic.

Paul Lamar