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
 InvocationExp(arg)
 ParameterMethod Type Description
 argByVal  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

 This is a clever approach. I believe you need a differential pressure
 sensor with a static reference in the same environment as the pressure
 probe.  If an absolute pressure sensor is used, you will be
 taking thecube root of (MAP + ram pressure). MAP is normally very
 much largerthan ram pressure. Using a differential sensor (i. e.
 MPX 2050) wouldallow you to subtract MAP before taking the root.

 Victor Roberts

 Thanks Victor. We don't have a choice as the absolute pressure sensors
 are built into Tracy's computer box.

 BTW all standard aircraft
 air speed indicators and air data systems work this way. Static pressure
 is on one side of a diaphragm and dynamic pressure on the other.
 The movement of the diaphragm turns the needle that indicates
 air speed. Dynamic pressure is the square of forward speed.

 Also there is an error in my message above. Can anyone find it?

 Paul Lamar

 cube

 Cary

 And?

 Paul Lamar

 Paul, about "and?"  Actually it is not the cube of the voltage it is
 to the fourth power of the voltage plus an adder. Using the table
 posted yesterday I suggest the following. Add .85 to the voltage and
 take that to the fourth power to get CFM. Note the ,85 constant is
 to provide a slightly larger Cfm at higher airflows making a small
 leaning adjustment. The manual mixture control or wide band O2
 sensor will tune the  output.  If you divide the above by 13.352 you
 have pounds of air per minute. Multiply that by 60 and you have
 pounds of air per hour. divide that by 14.1 and you get pounds of
 fuel per hour. Divide that by injector pounds per hour 39 in my case
 to get percent of on time of the injector. That is then translated
 to pulse width by the flywheel teeth count.

 The math part of the above would look as follows

 Using variable Va as the amplitude of the MAF output voltage

 CFM= (Va+.85)*(Va+.85)*(Va+.85)*(Va+.85)

 Pounds per minute =CFM/13.352

 Pounds per hour = Pounds per minute X 60

 Substituting I get ( ((Va+.85)*(Va+.85)*(Va+.85)*(Va+.85))/13.352)*60

 Simplifying,Set Vb=Va+.85 and deviding 60 by 13,352 to get 4.4937

 And define Pa =Pounds of air per hour

 Pa=Vb^4*4.4937

 Step 2, calculate pounds of fuel per hour Pf= Pa/14.7

 Step 3. Calculate %  injector open time for a 39 pound per hour ford
 injector  = Pf/39

 For an example say the flywheel has 100 teeth on the ring gear, then
 pulse width is the %open time above teeth count. If the flywheel has
 137 teeth multiply the tooth count by 137/100 for the tooth count .

 The assorted constants for injector pounds per hour, baseline
 mixture and flywheel teeth can be defined by their equivalent
 constant which I will call Ce

 ultimately Pulse width is (Va+.85)^4Ce  which is the tooth
 count of the flywheel

 I view this as a conversion factor like changing  inches to  millimeters.
 With one analog to digital conversion for the MAF sensor, A second
 one for the potentiometer for manual leaning (using a  similar
 conversion factor for flywheel teeth) added to the above tooth count,
 and a counter for the ABS sensor.

 So what do you
 think
 george grimes

 I am happy to know that somebody is actually reading this stuff :)

 This is the error I made:
 "voltage is more or less proportional to the cube of the mass air flow"

 It should read:
 "voltage is more or less proportional to the cube root of the mass
 air flow"

 Therefor you have to cube the voltage out of the MAF sensor to
 get the proper injector pulse width. Piece of cake in ZBasic.

 Actually it could be anywhere between the cube root and the fourth
 power. ZBasic does not care. What ever the mass airflow sensor
 curve does that is the exponent you use. Say 3.5. It might not
 be a perfect curve but it will be close enough.

 In QB the syntax is "Pulse width times your constant = (Voltage)^ 3
 to 4"

 This is all opposed to a look up table which is a pain in
 the butt to tune. EGT based auto tune will do the final adjustments.

 The problem with counting the flywheel teeth for ignition purposes
 with the ZBasic is it is not fast enough. That is why I am using an
 external fly wheel teeth counter that updates the RPM count every .6
 seconds. That give the RPM in four digits to the nearest single
 revolution.

 ZBasic could count each tooth if that was all it had to do.

 Using the hardware interrupts in ZBasic to get around that
 is problematic as all sorts of routines and instructions disable
 the hardware interrupts. One of the critical ones is:

 ---------------------------------------------------------
 PWM
 Type Subroutine
 Invocation PWM(channel, dutyCycle)
 PWM(channel, dutyCycle, status)
 ParameterMethod TypeDescription
 channel  ByVal  ByteThe channel to use for PWM generation.
 dutyCycleByVal  Single or integral The desired duty cycle.
 statusByRef  BooleanThe variable to receive the
 status value.

 This subroutine begins or modifies the generation of
 a 16-bit PWM signal on the specified channel. The
 channel must have been previously prepared for PWM
 generation by calling OpenPWM(). PWM
 generation is performed using one of the [WINDOWS-1252?]CPU?s
 16-bit timers, the number of which varies depending on
 the ZX model. The table below indicates the output
 pin for each PWM supported channel.
 The PWM free runs with a given width and frequency until the next
 time it is changed. That frees the processor for other
 jobs.
 -------------------------------------------------------

 Hard ware interrupts  rapidly gets to be a real can of worms.
 That is why I am doing the critical real time stuff like determining
 RPM with the flywheel teeth and firing the ignition with simple
 external hardware like two Hall Effect sensors for a two rotor and
 three for a 3 rotor. The ignition can be advanced with an old
 fashion push pull cable like the Ford Model T. Easy to understand
 and fix.

 Here are some 3D's. I am going to use Hall effect sensors for the ignition
 rather than the traditional mag crank angle sensor as they are much
 cheaper
 and smaller. Therefor I can fire the ignition every ten degrees for
 40 or 50 degrees to improve the fuel burn is it works. I have
 already done a skematic and some R&D on that.

 The RPM flywheel sensor will be the same as the stock CAS or
 the ABS equivalent as hall effect sensors require rotating
 magnets.

 We are still in the planning stages here so a lot of suggestions
 for improvement will arrive once people start thinking about it.

 The $90 Atmel 1290 100 pin board is making it practical and it is
 working to the point where ZBasic software changes are now trivial.

 Tracy does this in assemble language software which is much faster
 but it takes years to be good at it. I want to make this simple
 enough so anybody can learn how to do it in a matter of weeks.

 Paul Lamar


 Hi Paul,
 Suppose you used two trigger wheels spaced say 1/4 to 3/8 inch apart, each
 with two or three "pins" on them. The pins could be 20 degrees apart and
 space
 the two wheels 10 degrees apart. You would have multi spark and redundancy
 in
 firing two ignition systems. The trailing firing off the 10 degrees
 "retarded" system. One par of pickups for each rotor.

 Dale Davies

 Of course we are talking here about simple mechanical  systems
 that do not use the processor for firing the ignition.

 If you mean pins are the same as tits that won't work.
 You need one tit and three Hall Effect sensors to fire
 a 3 rotor correctly. Each rotor fires 120 degrees apart.
 Both plugs fired at the same time.

 In the case of two trigger wheels you would
 need six hall effect sensors. The first set
 firing the leading plugs. The second
 set of three firing the trailing plugs.

 One tit on each trigger wheel.

 Other than that it is a good idea. Hall effect
 sensors are cheap. Adds ignition redundancy
 like dual mags.

 BTW As far as anybody has been able to determine
 there is no HP advantage to split timing
 the leading and trailing spark plugs so this system
 could be set up to fire both plugs at nearly
 the same time.

 Paul Lamar

 Paul,

By firing the leading and trailing together, I would think that would
significantly simplify the design.  Not sure how to do this, but couldn't
you use a repeater circuit to do multi-spark ignition?  Or, better yet, do
it with software.

Mark

Software is out of the question with ZBasic.
You cannot get accurate timing due all the stuff
going on the back ground. Four or five  Hall effect
sensors per rotor 10 degrees apart are the hot tip.
One rotating magnet is all you need.

This is a homebuilt MSD system with one spark
every 10 degrees starting at 20 degrees BTDC.
400 watts ought to be plenty. No guarantee on
spark plug life however. Try iridium.

I need to update 555 crank angle sensor 3 dwg to show
more HE sensors.

Paul Lamar



Paul,   I finally opened up the TI microprocessor computer programmer we
had suggested to us last year. It seems to require assemble language. There
is complete control of hardware interrupts as well as everything else. In
fact it works by moving individual character bits from one address to
another. The math seems limited to addition and subtraction and comparison
of one value to another.Basically multiplication is how many times one
number is added to itself as an example. This seems like a long cumbersome
process to actually get something done but the basis of all computer math at
the micro level.  I decided to sell this item on E-bay.

    I also took a look at the latest BX-24 series of one chip computer all
on a 24 pin package. Current price mounted on a breadboard is $49.  It is
programmed in basic. I downloaded specifications and features and can post
that if anyone can't find it on the Internet. It appears to have everything
needed for this project.

      Needing a current manual for basic I downloaded the z-basic you had
recommended. Everything needed in one download, and well documented. It
makes this as well as vertually any project possible without all the move a
bit to address f062 address stuff which has no place in the 21st century.
That wheel has already been invented in the 1950's and should be on the car
when you buy it. I suppose that makes me a high level language advocate.

      I am only interested in metering fuel and air into the engine without
other complications. As I remember programming and it is still this way in
industrial computing, a program is executed from beginning to end in
sequence. It can go back or forward to other functions as directed by loops
and conditional statements encounterd as the sequence of commands is
executed. The last line by conditional statement starts the nect scan or
terminates the program. It seems to me that the hardware interrups should
not be a problem for what I am thinking about doing.

        IMHO I see this as a linear program execution. First interupt looks
at the CAS going high to start execution followed by get MAF voltage and the
manual leaning voltage.. These won't be called or needed until the next
scan. Then the analog to digital conversion of these variables. At that
point data values are set for the calculation  of (V+.85)to the fourth
power*Ce. Which is the value of the PWM counter. Next step is The interrupt
for output to the injector driver MOSFET which loops until the count
terminates then a go to line 1 to wait again for the CAS to go high. The
input interrupts and output interrupts are each called only once and not
nested within each other.  I would use a separate CAS and BX-24 chip for
each rotor, a total of four of each for my four rotor all programmed with
the same program. One additional possibility is outputting the PWM value as
a voltage using the AtoD conversion and inputting that to a 555 timer to
fire the injectors. If the output is left as a series of pulses it might be
possible to use a four axis stepper driver board to drive the injectors.

   The question is does Z-basic handle interrupts only when called by the
program?  And secondly does it insert interrupt for things that are not
externally connected to the program being executed?  I don't see a problem
if it pools all points at the beginning of a scan and doesn't look again
until the next scan since the program completes during each scan.

george grimes

The problem with ZBasic and hardware interrupts boil down to
the fact you are dealing with multi byte numbers. Hardware interrupts
are disabled when that happens. They are disabled for a myriad of other
functions and routines. There is also a real time clock that
disables interrupts. Fortunately this can be turned off.

Goto http://www.zbasic.net/

Then scroll to forum >ZBasic Language>Jitter and
read the entire thread. Both pages.

The price I am willing to pay for the ease and speed
of programming in BASIC is a bit of extra hardware to do
the real time stuff.

I like all the I/O pins and 16 channels of A to D on the
Atmel 1280 PC boards. I/O pins and A to D's are like money. You
can never have enough.

Paul Lamar