Paul,

  I have a thought on a more advanced Engine Controller for the Rotary.

  I would like the engine to be able to adjust automatically to changes
  in operating conditions. In the current EC3 setup, MAP is used to
  control the proper amount of fuel, and it takes a lot of
calibration  before a conversion is done properly.

  Now what if we can monitor a MAF sensor? If we know the air mass at
  any given time, together with rpm and displacement, we can
calculate  how much fuel to squirt into the engine. Since Air mass
changes with  altitude, the engine can automatically reduce fuel consumption
  accordingly.

  To make programs simple, I propose a push button to fine tune the
  leaning process. I assume that on the climb, we can let the engine
run  a little rich, so we can settle for a simple loop similar to an
open  loop mode in the cars, but once we are at our cruising
altitude, we  can push a button, and my monitoring CHT and EGT, we
can program the  EC to do an automatic cycle to find the best lean point.

  On descend, we can either automatically take the best lean mode out
  and get into open loop mode by monitoring the MAF, (Air becomes
dense,  while rpm is constant and volume of air is constant).
Alternatively,  we can add one more button to manually get into open
loop mode.

  Henry Nee

  Sounds great Henry. What are you going to write it in?
  I would like to see ASM as there is a one to one between what you
tell it to  do and what it does. Also you can control time down to
the nano second.  Perhaps you have someone over there that can do it
in ASM  and comment it in English. I can help with the cost up to a
few hundred. If  it is done in high level language perhaps the
comments can be correlated  with the ASM listing.

  BTW are you back in China? Ed wants to buy some ceramic bearings
for our new  PSRU's

  We have your Chinese address unless it got lost in the last
computer glitch.  I am now using Ubun 10.04 and I like it better
than Fedora 7 but there is  still room for improvement. It keeps
bugging me on the bug fixes. Shall I do  it? I have the second hard
disk working so I will back up everything first.

  Paul Lamar

I am still here stateside. I am scheduled to return by the end of
this month. I think everyone in China is off due to Chinese New Year
so no point in trying to buy anything until end of this month.

IMHO, Some Assembly, and some higher level language. I like Pascal,
but C may be easier to write. I don't know if Basic has the
performance to do floating point math efficiently. I think we need a
Basic Compiler so we can pre-compile the code then it should run much
faster. I like a lot of timing margins so that there is enough CPU
cycles to deal with unforeseen event combinations.

I am not sure what language it is going to be, but I am sure assembly
will be part of it so thank you for your offer to help. I might
actually need you to try this out on your engine first as I have
nothing to test it yet.

I am hoping to do this with a ladder diagram. Ladder diagram is used
widely in control systems because it makes it easy to isolate
feedback signals from contaminating the inputs.

Let's assume that we can run to 12,000 rpm on a rotary (For those
needed extra horse power and have the money to use light weight
rotors), that will be 200 turns per second, or 5 ms per turn. I think
I can handle all the calculations in that time. The problem is that I
may not have enough time if I have to squirt to each rotar. If I
remember correctly, I will have to squirt into one chamber per turn
per rotor, so in a two rotor system, I have 2.5ms to get the job done.

Also, I think it is necessary to have a real time system so squirt
and ignition timing needs to be more precise. My feeling is to use a
second processor dedicated to do just that, and it will get the
squirt duration, and ignition time values from the first processor running
ladder diagram software. Of course the second processor will be in a
simple loop and can be as simple as the basic program you have
suggested in the past, Or we can write it in assembly and be even
more precise.

The idea of using two separate processor is to have an isolation
between the real time processing done by the second processor, and
the "not so real time" processing done by the first processor. In
"not so real time" I mean it is not going to hurt us if we miss one
cycle and use an old value instead of a new one on fuel and ignition
as engine may not have changed that much in speed over 2.5ms,
 therefore timing is still OK. And this is only a potential problem
during initial spooling up of engine speed.

Once we separate the tasks into two processors, we eliminate one
major concern I have with processors, that is multiple events
happening at the same time, and the resulting lack of processor
power means that calculated data can feed back into the input and
causes unforeseen conditions! So separating the job to two separate
processors has the advantage of a more reliable software system than
doing it all in one unit.

I would also like to add two backup processors, one on the main loop,
and one on actual squirting and ignition timing control, and have a
manual switch to switch control from one to the other when needed.

Between the processors, I would use a I2C bus to pass the output of
the ladder diagram to the second processor. I think it is easier to
interface this way than to use a low cost 555 with this approach.

Henry Nee

Henry, take a look at ZBasic.
It is fast, very easy to learn  and compiled.
http://www.zbasic.net/

I have done a lot of work with it and it is very readable
and easy to start using.

The $100 board is a bit over kill I/O wise  but hey it is cheap enough.

Crude out line stub EFI for CD ignition and injection.

Paul Lamar


I know this is not exactly the same, but I think Henry has a point. For
liquid measurement we use turbines with six blades. On the smaller ones the
K-factor is very high. The 1/2" turbines have a pulse count (K-factor) in the
neighborhood of 3-4 million pulses per Meter cubed. That is 264.172 gallon US.
The older totalizers that convert pulses to a volume will not do the math
quick enough so we use a divisor. This way it does the math only on say every
tenth pulse and you move the decimal over one.
On an AC engine the fuel requirement will not change drastically in 10 revs
which makes the calculation time a little easier. Then it is just how much
each rev and the spark.

Dale Davies