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

  Paul,

 I have a wide-band O2 and run 100LL.  Burning 100LL may cause it to be a
 bit
 slower in response time, but it works just fine for my purposes.  The
 problem I've always had with EGT is that I can never know which side of
 peak
 I'm on.  With a wide-band there is never any question.  So, how does the
 computer know which way to go (rich or lean)?  Also, I've had a couple of
 EGT probe failures.  Maybe that's because of the higher EGT's of the rotary
 engine.

 BTW, I ordered a ZBasic book from Amazon yesterday.  Hopefully, it will
 take
 a more logical approach than the ZBasic.net manual, which is more like a
 dictionary than a manual.  There was only one to choose from.  Is ZBasic a
 big secret or something?  What gives?

 Mark

 Easy. Richen the mixture. If the EGT goes up you are on the lean side.
 If the EGT goes down you are on the rich side. Computers are good
 at that sort of thing.

 Wow! I am surprised there is a book. Amazing. ZBasic is not exactly
 a house hold word. I know Don is doing well as I met him in Oregon.

 I am working on a stand alone index for the lib ref manual. Or rather QB
 is doing it. The Linux version of the pdf viewer allows one to cut
 and paste text out of a pdf. I'll upload it when it is done.

 Paul Lamar


 Paul,

Right now I need a "Dick and Jane" type book.  Once I practice and see how
things are supposed to be done, then I can start getting creative on my own.
 Hopefully, this book will be a good starting point.  It was only $12
(used), so I don't have a lot at stake.  If that doesn't do it, then maybe
there is a "QBasic for dummies" book that I can get to cut my teeth on.

Mark

I hope it is better written for non computer gurus than the pdf docs.
I have trouble understanding ZBasic because it was obviously written by
some person going though computer science courses or a C programmer.
I know Don wrote it in C ++.

I am self taught as there were no computer classes back in 1975. C did not
become popular until the mid 80's. I think it was first written
in the early 70's for UNIX. I had a BASIC programmable calculator loaned
to me for a few years in the early 70's. It was made by Friden, Wang or
HP as I recall. It kind of looked like this HP except it was bigger.
The size of a kitchen stove.

BASIC was heavily criticized by computer professors. Ostensible because
of it's lack of "structure" and its slowness. I suspect it made
them redundant as it was too easy to learn :) The truth is a BASIC
compiler can generate machine code that is just as fast and just
as small as any other computer language with the possible exception
of assembly language. QB is anarchy while ZBasic like C is closer to
Communism or Nazism :)

Paul Lamar