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.
------------------------------__------------------------------
Sub Main()

Call PutPin(12, zxOutputLow) ' pin 12 CAS 1 will be at logic zero
Call PutPin(13, zxOutputLow) ' pin 13 CAS 2 will be at logic zero
dim x as long
'check and wait for CAS
'do
for x = 0 to 3000000 'develop only
If (GetPin(12)=1) then
Call rotor1
end if

if (GetPin(13) = 1) then
Call rotor2
end if
'loop
next x 'develop only
end sub 'main


sub rotor1() 'it is 22 degrees BTDC
Call PutPin(14, zxOutputHigh) ' trigger ign rotor1
dim add1 as integer
dim add2 as single
dim add3 as single
add1 = GetADC(82) 'MAP sensor val must be an integer
add2 = CSng(add1)
add3 = add2/10.23

'injection
' prepare for 100Hz Fast PWM using channel 2
Call OpenPWM(3, 250.0, zxFastPWM)
Call PWM(3, add3) ' generate PWM with
Debug.Print "  = " & CStr(add3);
Call PutPin(14, zxOutputLow) ' turn off ign trigger
end sub 'rotor1

sub rotor2() 'it is 158 degrees ATDC
'Debug.Print "rotor 2"
End Sub 'rotor2

------------------------------__----------------

Paul Lamar

Paul,

I did some reading about ZBasic and your code. I think there is at
least one place that needs to be modified.

In your code you call PWM to generate the pulses automatically, and
then changes the duty cycle and duration to account for rpm changes.

I think it is better to use a function similar to PulseOut. This is
because PulseOut is not recursive, so it cannot have cumulative timing
error.

However, PulseOut stops all interrupt, therefore it may be necessary
to write a different subroutine to generate the pulse.

I envision getting trigger by CAS, add a delay, and then generate a
pulse. Since the pulse is generated like a 555 timer, we can trigger
and forget, and start waiting for the next CAS. This way, the delay
from CAS to pulse is always under control, and CAS to CAS pulse can
vary slightly between each revolution and the timing will still be
correct.

I have not had time to analyze other issues yet, but it may be
possible to use ZBasic after all. What we need is a simulator that can
vary CAS input timing and see if the CPU has enough mips to take care
of the software at the worst case. Last time I used a MPC by ST
Microelectronics and their IDE has a simulator that I can use to
generate all kinds of condition as input to the software. I don't know
if ZBasic has this feature or not. I will try to find out.

Henry Nee

Glad to see you are taking an interest in ZBASIC. IMHO it is the
easiest to learn and the quickest to write. As long as it is fast
enough. I think it is if you don't try to do too much.

Here is a simple CAS simulator I built up on a bread board.

Paul Lamar

 Paul,


FYI  I can send Paul a few hundred bucks to buy stuff for all the
different developmental projects everyone is working on if it would
help.  Feel like I should do something to contribute to the cause and it
won't be my intelligence.  Let me know Paul.   BTW  Red Tails is great.
Van Vannoy

I'll give it to Ed as he has fronted the money on the new gear box design.

Paul Lamar