I suggest if you are interested in this system you make
    a folder and drag over all the many future messages on this
    subject otherwise delete it.

 There are at least two ways to build an EFI program.
 The first and the simplest is to assume power is a direct
 function or RPM and manifold pressure. That is how a 555 system
 works. The injector is triggered once per revolution
 and the pules width is controlled the manifold pressure.
 The higher the pressure the wider the pulse... more fuel.

 See http://www.rotaryeng.net/simple-cheap-555.html

 To do that using a computer programed in BASIC is trivial.
 Almost a waste of the computer's power. I could write
 the program in about five minutes. Maybe a day at the most.

 The vast majority of EFI systems and that includes Tracy's system
 use a look up table to adjust the injector pulse  width for
 a given RPM and manifold pressure.  That gives a 2 dimensional
 table of several hundred entries. One could have a one dimensional
 table for say 75 different RPMs and modify the table values
 by the manifold reading. That would be say every 100 RPM
 for the rotary. I am not sure which system Tracy's
 uses. One can do a bit of math and interpolate between
 fixed readings. The same thing could be based on manifold
 pressure alone and adjusted by intake air temperature.

 The table is stored in EEPROM so it is always there even if
 the power is turned off. In ZBasic speak that is called
 persistent memory and there are 4000 bytes available.

 Fortunately ZBasic has 2 Routines that are highly
 useful in this sort of EFI system.
 PersistentPoke(value, address) and PersistentPeek(address)
 See page 182 of the ZBasic System Library  Reference Manual.

 The address is just the line number of a one dimensional
 table. The value at that address is a Byte data type
 being 0 to 255. See page 7 ZBasic Language Reference Manual.

 Poke can load the table from a file in your PC computer
 you generated with an editor. If you used two ZX computers
 such as Tracy does you could fly on one while adjusting
 the other using a NetBook and switch in the air. It helps
 if you have an autopilot or some one else to fly the plane
 and look out for traffic.

 Peek of course can read the file for a given RPM
 and use that number adjusted by the MAP to control
 the injector width.

 Peek can also be used to read out the file to your
 PC just to check up on what is in there in case you
 forgot.


 Paul Lamar

 Paul,

 Sounds interesting.  What would it take to read an output voltage from
 the
 O2 sensor, compare it to a voltage from a potentiometer circuit (knob
 on the
 panel controlled by the pilot), and PersistentPoke the appropriate
 byte as
 determined by current rpm?  That would be "auto-tune".

 Mark

 Now I having you thinking Mark :) Not much in terms of software.
 We have at least eight analog to digital converter pins to work
 with.

 IMHO it would be better to use a wide band O2 sensor. Of course that
 would die if you were forced to burn 100LL. If it were a sub routine,
 called up only once, when you first fired up the engine on the
 first flight using auto fuel, stored the MAP table in persistent
 memory and then never used again.... that would work.

 Perhaps using EGT would be better. Max EGT at all power levels
 which is almost peak power. See the attached charts. The leaning knob
 would then take care of cruise or richen it a bit for cold
 starting and peak power. War emergency mixture :)

 BTW As a compact user interface on the instrument panel I am thinking
 of using a rotating switch with 16 positions that will call
 up to 16 different programs. Autotune could be one of them.
 Interfacing with the NetBook another. Position 1 to 8 could be
 computer 1 and 9 to 16 could be computer 2.

 You then push a button on the switch to run the program
 and or switch computers. The program name would be NC milled into
 the bezel. IMHO that is an intuitive way for people to control a
 small computer.

 What do you think?

 Paul Lamar


Look at the analog devices ad 594 and 595 for thermocouple conditioning.
chris smale


Thanks for the tip Chris.


Paul Lamar
--


Mark,  Computer courses were manditory in engineerein at the university of
pitsburge in 1967 but I don't know how long before that. We used MAD
(michigan algorithmic decoding) as the language as freshmen on IBM 7090
mainframes and then fourtran 4 in engineering or cobal in the school of
business. These ran on the IBM 360 which occupied 3 floors on the building.
We wrote programs to optimize floor plan layouts, regression analysis of all
successful racing engines to come up with a starting point of bore to stroke
to connecting rod length for engine design. Mine dumped out a rotary valve
cylinder head which looked like large slotted camshafts running across the
length of the cylinder  head. ( that turned into a term project and later I
found a reference that rolls royce had used it on truck engines).
         We didn't have to assign addresses or shadow variables nested
functon blocks  (although we could if needed) because everything routine was
done by the compiler. Your first line would be compile fourtran (or
mad,cobal,sindue,pil or whatever) then you declared all the variables as
integer, floating point etc. That would be 84 to a line of code. (integer
a,b,c,fred,jack,bore,stroke) and if it was a long line just keep adding.
Then the actual code was written . Line number followed by conditional
statements, range of a loop, next line when the loop or conditions were met
out to 84 characters. This is radicaly different than C and C++ (the++ is a
computer joke since ++ is ised in C to increase the value of a veriable by 1
unit (fred++ would be fred's son). In C we write 12 to 20 lines of code to
do what fortran does on 1 line. This fuel injection program would be no more
than 3 lines of control code and a line to calculate fuel pulse width and
two more for spark and injection lead , then "end program" on it's own line.
      The programs had like C++ the option to start a line with * as a
comment line which is ignored by the compiler up to the next line number.
one might say "next line calculates pulse width based on input from lines
2.5.7"    Your code is compled in 3 steps. First all the variable names are
replaced with sequential numbers and well as the statements and all comments
are eliminated. Then all the sub program loops are "linked" and finally the
group of linked sections are converted to the executable file which the
computer uses. This process is non reversable since everything that made any
logical sense is eliminated by the compiler.  There are so many lines of C++
code that debugging programs (I like borland C++ debugger best) is
manditory. There are hundreds of thousands of lines in some programs. I
dispise C++ for it's lack of higher math ability which is limited to add and
subtract. Multiplication is multiple adds and division is a guuess, find
error and adjust until the error is not significant. Fourtran on the other
hand does trig and calculus and can develop unknown calculus equations
through programming.
      Sorry about the ranting it won't be repeated, I just find it
irritating that we must get bogged down in all this cryptic stuff rather
than just write the program. We also had error codes but they pertain to
your code not to the basics that are used on every last program you enter.

george grimes

Have you tried QB George?
I can send it to you in a zip file>

Paul Lamar