Subject: Computer EFI
From: Rotary Engine
Date: 7/18/2011, 9:53 PM
To: AAA Put this in the To box

There seems to be more interest in this for aircraft use.
Some people I know are trying to implement Megasquirt (I think) on some
experimental aircraft using the traditional air cooled aircraft engine.

It can be done but I am not comfortable with Megasquirt.
Currently it seems Ä? it has evolved to be all things to all car engines
while
the aircraft engine needs are more limited.

It also relies on feedback from an O2 sensor which does not work well on
100LL. Yes I know there is a move afoot to replace 100LL but that has
been
talked about for the last ten years with no real movement. The lead
emitted
is a phony issue and not a real problem.

The aircraft application needs more display of engine parameter and
historical data acquisition. In other words what is the engine doing now
and
what was the engine doing for the entire flight.
In other words it needs to be combined with an engine monitoring system.

Also Megasquirt is not well documented IMHO.
For example here is a so called flow chart of the main program.
What is missing in most cases is how, when and why.


Set up Phase-Lock Loop, RTC, Serial, Interupts
Initialization of Ports / Variables
Sample MAP sensor and save as Barometer
Copy Configuration and VE variables from Flash to RAM
Copy Flash Burn Routine from Flash to RAM Main Loop:
Perform Table Lookup for Barometer and Air Density Correction
Perform Table Lookup for Coolant and MAP Linearization
Determine if in Fast-Idle Mode
Compute RPM, Determine if Engine is Cranking or Running and
Flood-Clear
Calculate Warmup and After-start Enrichment
Calculate Acceleration Enrichment/Enleanment
Calculate EGO Enrichment
Calculate VE from 2-D Table Interpolation
Compute Total Enrichment Value (Accel, Baro, Air Density, EGO,
and
Warmup)
Compute VE Contribution
Compute MAP/Baro
Calculate REQ_FUEL
Calculate Battery Voltage Compensation
Calculate Final Pulse Width
Goto [back to] Main Loop


Yes the info is there in the C source code but C is the fundamental
problem.
One must be an accomplished C programmer to really understand what is
going
on. I am not. There is a lot of controversy about this but IMHO C is a
terse
and cryptic language. C was invented back in the days when one used a
teletype machine to talk to and program computers. That was 40 years ago.
Computers are a million times smarter than they were in those days.
You should be able to tell the computer in plain English what you want it
to
do. I am not saying voice recognition here. Just be able to type it in.

What do you think about this?

Paul Lamar


Megasquirt runs happily open loop - no O2 sensor..

There's a learning curve with C. And then some people write crappy C
code,
that can be very obfuscated. It's very powerful and efficient, and if
well
written, not too bad to understand. Ä? I like that the C compiler is so old
and well developed. New languages might not be as well debugged.


Matt-

"There's a learning curve with C." No kidding :) There is a version of
BASIC
that is evolving into a standard for machine control. Depends on how you
define efficient.

http://en.wikipedia.org/wiki/BASIC_Stamp

"The BASIC Stamp is a microcontroller with a small, specialized BASIC
interpreter (PBASIC) built into ROM. It is made by Parallax, Inc. and has
been popular with electronics hobbyists since the early 1990s due to its
low
threshold of learning and ease of use (due to its simple BASIC
language)."


Paul Lamar


Paul,

Megasquirt is well documented for it's purpose. I suspect well over a
1000
vehicles are running the megasquirt, so pretty large acceptance.

What you are missing with the megasquirt code is Al Gippo's comments. Ä? Al
did the math (who, what, where, when), and Bruce did the coding (How)
that
you listed out. Ä? A lot of the original material is no longer posted
(there
was a ton of questions on how the formula's were derived...
but the goal was to just get a simple, easy to tune fuel only system, out
to
enthusiast). Some of the simple explanations are still here:
http://www.megamanual.com/v22manual/mfuel.htm

The original project was John Gwynne's efi332. Ä? We used a 68332 system
for
fuel and spark, and a bunch of control. Bruce Bowling felt that system
was
way too complicated, and felt the 6808 was easier to implement for a fuel
only system that became the mega-squirt.
Lot of the documentation is still on the web here:
http://www.diy-efi.org/efi332/faq.htm
http://www.diy-efi.org/efi332/equations/algorith.htm -- Section by Al
Grippo

Tom W

Hi Paul,

C is often referred to as a "portable assembly language." Ä? It is "close
to
the metal," and so can be cryptic. But, for interfacing with devices and
manipulating memory directly (often required when interfacing with
embedded
systems and sensors), it is a reasonable language. Ä? What I think is
missing,
is a more abstract layer on top of the device-dependent interface code.

You can imagine a layer of C code that talks with the controllers and
sensors, but a more abstract layer of code above that in which the logic
and
control flow is defined. Ä? I have seen in recent years an increase in the
number of projects in which a powerful scripting language calls out to C
libraries. Ä? This may be what you are looking for. Ä? An example
implementation
might be a Python scripted "Main Loop"
calling out to C libraries for sensor readings, etc., but all the complex
decision logic is made in Python (or Ruby or Perl, etc).

What you are describing when you talk about using "plain English" is a
domain specific language. Ä? Computers require precise instructions and
will
do exactly what you tell them to do, for better or worse.
English is too abstract and context-sensitive for precise control. Ä? A
language optimized for the ECU domain might be an interesting project,
but
is a difficult undertaking. Ä? A good compromise, though, would be a well
defined API written in a high level scripting language that reads a
little
like English. Ä? Python suites that purpose quite well.


A little googling revealed the presence of Python on embedded systems and
single board ARM computers.



http://stackoverflow.com/questions/240996/anyone-using-python-for-embedded-p
rojects



I also found 1 open-source ECU system under development, FreeEMS (appears
to
be written in C):

http://freeems.org/


I wonder if there is enough interest to start an open-source (hardware
and
software) project for an aircraft ECU based upon modern computer
languages
and single board ARM computers?


Regards,

Mark Hagood

The problem for me with C is what do I do if I want to add an engine
monitoring display on the front panel? I am real good with 6800 assembly
language but I refuse to learn the cryptic C when I know it can be done
in
BASIC. Of course assembly language is a REAL steep learning curve for
most
people. It also consumes months if not years.

Paul Lamar

Paul,

One of the best programmers I had working for me had a Masters in English
Literature. Not only did he write some great weekly status reports, but
his
code was very well thought out and written. Yes, even in C and C++. Ä? He
would discuss the structure of a written sentence, then compare it with
written code. Ä? To him the key was is just understanding the rules, and
following them.

My son has been playing with the Arduino family of boards. Very simple
syntax, but it can produce wonderful results. He wanted a display for his
240SX. Ä? He has the GPS, data logging to SD card, and display up and
running.
Total time to write the code to do that was one afternoon! I had the GPS
module from a previous project, and remember writing code in my spare
time
for a few months to get done what he accomplished in an afternoon!

I noticed Digilent has a couple of MicroChip based Arduino boards, which
have much more computing power. For simple "one off projects" using the
easiest to implement and document software does make sense.



http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,892,894&Prod=CHIPKI
T-MAX32

Note the $49 price.

Tom W

I don't think Chaucer helped :) I hated English Lit :)

That looks like worth buying one and fooling around with it.
Certainly looks like there is a lot of competition for the embedded
market
now.
-------------------------------------------------------------
* Microchip PIC32MX795F512 processor
o 80 Mhz 32-bit MIPS
o 512K Flash, 128K RAM
o USB 2.0 OTG controller
o 10/100 Ethernet MAC
o Dual CAN controllers
* Provides additional memory and advanced communications
peripherals
* Compatible with existing Arduino code examples, reference
materials and
other resources
* Can also be programmed using Microchip's MPLAB (along with a
PICkit 3 and our PICkit3 Programming Cable Kit, seen below)
* Arduino? "Mega" form factor
* Compatible with Arduino? shields
* 83 available I/O
* User LED
* Connects to a PC using a USB A - mini B cable (not included)

-------------------------------------------------------------------------

So far I have been fooling extensively with the ZBasic product.
Tons of I/O. The ZBasic language is very fast. As I recall it can pulse
for
one micro second.

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 'Mazda crank angle sensor.

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

http://www.zbasic.net/

I'll get one of these chipkit boards and see if I like it better.

Microchip has much better support than Atmel.

Paul Lamar


Hi All,
I am new to this list, but I actually work in the automotive industry at
an
OEM. Ä? I don't work on Engine ECU's everyday, but I work with ancillary
controllers for other areas. The basic functions for control systems are
the
same.

I am thinking about an embedded Aircraft worthy system myself. Ä? The EC3
system looks good, but the lack of a serial interface is a bit of a
concern.


I looked at Megasquirt. Ä? It looks very interesting, but frankly fine on
the
"Ground". Ä? In the air, I would have many reservations

as there are lots and lots of opportunities for failure in software
driven
platforms. Ä? Additionally, companies like Bosch have teams of people
working
on Engine ECU's.

I am leaning towards a different approach which would be cost effective
and
also be supported by professional engine management people. The platform
that I am looking at is called a Mototron by MotorHawk control systems.
http://mcs.woodward.com/products/ControlCore/ECUhardware/The specific
unit is
ECM5554-112. Ä? It comes with a core OS that is tailored for this type of
application.

The tools needed to develop on this platform can vary, but are readily
available. Ä? The platform has 3 CAN buses and an RS485 bus, which makes it
ideal for connecting to a Glass Cockpit and EMS.

The platform comes with development and production components that can be
used to create an Aircraft worthy system. Ä? It is also set up for a wide
temperature range -40 to 105 C and comes in a cast aluminum frame.
With the right expertise, a pair of ECU's can be put into a redundant
system.I am thinking of working towards this goal

In terms of cost, they are less than $500, because they are produced
under
various brand names for production automobiles with unique
implementations
for different engines.


If there is any interest in working with me on adapting this to run a 20B
or
13B, I am very open to it.

Thanks,
David Goings

David,

On the Woodward ECUs, they are excellent products. Ä? You will need to
write
all your own code. Ä? The TPU functions in the MPC500 family devices can
also
act as a limp home home to fire injectors and pulse ignition if the main
ECU
isn't running. Ä? At Bosch we had a separate IC to do that function, but
admitted you still have a single injector or ignition coil driver.

Way back when I did the design review on the MPC555 version of the
Woodward
box when I was at Motorola. We used it for Ä? a demo at SAE Convergence
using
a ADI "hardware in a loop" box. Great Demo, and a few of the ADI folks
went
on to form a software company that become Mototron, that was later bought
by
Woodward Governors. Ä? Great folks to work with and I still point customers
who need a ECU solution towards them as a turnkey hardware + software
solutions.

One of the fond memories was inviting the Apps team for "lunch and learn"
for Pizza and tore down an automatic transmission in my kitchen! Yes, I
was
divorced at the time, and we were working with Matlab and ADI hardware
and I
am a "learn by doing" person, and we ripped apart the transmission. Ä? It
was
much easier to understand how electronics could replace manual shift
bodies
this way, and great
insight for the team.Like I said, great group to work with. Ä? I was
just
doing
too much travel, and decided to move to another company and limit my
travel
as I had remarried and didn't want to repeat past mistakes. Ä? Irony is I
could still code up the Woodward boxes, but as it is I just don't have
enough hours in the day and would like to finish my Bearhawk first. Ä? It
was
interesting to note some of our demo projects did make it into production
some years later (One of my '98 designs was in the dealership in '06...
pretty cool stuff!)

Small world trivia... met you in a meeting at company doing In Flight
Entertainment. Ä? One of the key issues was loading all that data into a
portable device! Ä? Guess how much firmware is in a car today, so the
problem
still exist.

Tom Walter



Tom,

Small world indeed.Are you still in the area??I actually work down
the
street from the old In Flight company.

It would be good to chat about the Woodward unit.

David

I got a question guys. How is this thing programed?

Paul Lamar


Paul,

I am just getting into it. One option is MotoTune. Ä? I don't know the
cost.
Other options are tools like Simulink or Target link, which is model
based.
Avoids the coding at hand level.

These tools might be expensive. I have access to them right now at no
cost.
As I know more, I will share.

One thing about them, it was designed for harsh environments like marine
applications(Sea Salt, -40C to +105C), so aircraft use is well within
spec.

Couple of specification notes on the ECM-112-0904:
9-16Vdc,
3 Can buses
1 RS-485 Channel
4 Oxygen sensors
2 Knock Sensors
1 Emergency Stop
33 Analog sensors
VR and Digital Engine Ä? Position sensor (Crank and CAM) inputs
8 Injectors controls
8 spark triggers
1 Tachometer
14 Low Side Driver Outputs
1 Digital Output
1 Main Power Relay Driver Output
2-H Bridge Outputs

As much as I like the smell of Solder! Ä? (Just Kidding), this compares
very
favorably to a Megasquirt project.

-- David



The "code free" development tools are expensive. Ä? Often college students
will have free access to them, so it would be possible to have code
generated using those tools.

When I headed up the Powertrain Applications Group at Motorola
Semiconductor, the various tool vendors provided the tools for no charge as
they loved it when I was familiar with the tools and could assist their
customers. Irony was Motorola had their own software group (Code Warrior -
GNU based) tools, but I liked using Greenhills Tools as that was what a
couple of customers were using.
Made it much easier to send "try this code" and have it compile for them.
Software development is a trade off between time and money, better the
tools
and easier to learn and use, the more productive the developer was (biggest
item...
turn off the phone, and no interruptions!)

Today, since I don't have access to those nice tools. I would be using GNU
C
compilers (I can hear Paul groaning), with a simple RTOS like eCOS. eCOS
would be fine for private personal use, but not if you were selling the
code. Ä? There is a learning curve, but many of the subroutines are online
and
it is very possible.

For documentation on the woodward box, there are still Wiki Articles from
New Eagle (which became Mototron) online here:
http://www.neweagle.net/support/wiki/index.php?title=Engine_Control_Modules#
Powering_the_ECM-5554-112-0904_.28PCM0904.29

Link to the box David G. mentioned:
http://www.neweagle.net/support/wiki/index.php?title=Engine_Control_Modules#
ECM-5554-112

Please remember Mototron makes their money selling software and turnkey
solutions. Ä? While it would be tempting to undertake writing code for the
module,
supporting it is a huge time sink. I've seen many project that just could
not be sustained due to cost involved is supporting it. Ä? Megaquirt being
one
of the few that has actually thrived over time, but many other projects saw
light of day for a Formula SAE project, but nothing afterwards.

The Woodward boxes are nicely designed, and recommended. Ä? If someone has a
commercial (i.e. 10 to 1000 ECU's needed, and funding, I'll send you a
contact at Mototron to head up the project. Ä? Just be aware more companies
are realistic that they need 6 people on a team for a year, and realize
that
is over $1Million in development cost... or could turn to Mototron for a
cheaper solution). Ä? It does make Real World Solutions $800 box seem like a
bargain in comparison.

Now if I can get my college age kids to write code for room and board, it
might be viable. Actually with the tools I had for simulation, code
generation,
hardware in a loop, it was just a blast!For an EE who is looking to
expand
their knowledge, and possible relocate to Michigan, writing your own code
for the MPC555 would be a huge plus on your resume.

Tom Walter


Tom.
How about a Megasquirt port to the Woodward box.
David

Are they both programmed in C?

Paul Lamar

Paul,
Yes , Ä? I the operating system doesn't care as long as the binary (Assembly)
is done in the instruction set of the processor. In this case PowerPC. The
Green hills compiler mentioned earlier is a C compiler.
David

Well that disqualifies it for a project on here as I cannot expect
a number of people to learn C. I was hoping to get a fair number
of people involved.

Paul Lamar

Paul,
C, C++ is not that hard. Ä? The community college will teach enough of it to
a
person in 1/2 a semester. Ä? Like most things, it's just a matter of
wrapping
the mind around the paradigm. Ä? No I'm not volunteering. Ä? Too much
schoolwork. Ä? I haven't flown my puddle-jumper since Christmas.

Oh, by the way, I made a website chronicling our aviation exploits for a
technical communications class, it's pretty rough and needs improvement,
but
it made the grade. Ä? With your permission I'll post it here.



Chris Cosman

OK sure. Post away.

One does not need a course in BASIC Young children have learned it on their
own. I can have somebody programming in BASIC after a half hour.
Once one gets the idea it just becomes a matter of looking up
plain English commands that do what one wants.

Paul Lamar



Why does one need to learn to do C programming in order to run
Megasquirt?  There are tools available to tune the system.  The only
reason I can think you'd need to actually write any code is if you
can't leave the thing well enough alone.  I guarantee that 75% of the
Megasquirt users don't know a lick of programming beyond running their
DVR.

It's perfectly reasonable to use Megasquirt as-is, and then install a
"dribbler" system in the manifold in parallel.  If Megasquirt
craps-out, pull the breaker, open the fuel valve for the dribbler, and
limp home..



Matt-

Well true Matt but Megasquirt is not a good match for aircraft
use. One needs more info on the engine and Megasquirt does not have
an instrument panel display.

Check out this device. It is definitely a step in the right direction
for us.

http://www.andersonee.com/
http://www.andersonee.com/page6.html

The input to this device mostly comes from Tracy's  EFI system.
In order for this to function the fundamental source code of
the parent EFI system must be modified to support devices
like this.

Paul Lamar



Megasquirt has long supported Megatune - using a PC interface.  This
allows logging and real-time display of all of the sensor inputs and
normal operating parameters.  There is now also a Megaview which seems
to provide a somewhat more flexible and powerful version of control
than does Tracy's system.

Megaview:

http://www.diyautotune.com/catalog/megaviewi-unassembled-kit-p-95.html

Here's a megasquirt display designed for Linux (Ubuntu):

http://megatunix.sourceforge.net/screenshots/runtime-display-tab.php

Showing trailing plugs on a rotary:

http://megatunix.sourceforge.net/screenshots/rotary-trailing-tab.php


Matt-

Matt-

Yes but it is not an instrument panel display with all the fuel burn
and other engine monitoring stuff. Requires a PC in the cockpit.
It is also doubtful it has time to send the info to the PC
at 8000 RPM. There are faster processors out there than derivatives
of the 6800.

I am looking for something anybody can program and add new ideas
with out learning C.

Paul Lamar

-- I am lurking in the shadows checking in on occasion for any development of
the
555 system. No programs at all, can't be any simpler. But belive it has to be
built tested and worked out the bugs. It has great potential, and belive it
might not be too bad of an idea to revisit it.

I am not in a position to build and spend the time debugging, and develop it,
but similar 555 systems are sucessful systems, ( Light speed engineering),
so the fundamentals are all there. It's safe and have inherent redundancy, , one
module burns.. it will run on the others,  it's cheap....that will get the
attention of many, and it is easy to replace or fabricate modules.

One mixture control in the cockpit and that's it....its a system that is easy
to....well.... understand and operate. Pilots have adjusted their fuel for eons,
and the only learning curve here is how to turn a knob, the possibility to
automate that too is very high, and belive it already have been done.

Can be made sequential as well as batch fired, depending on trigger
arrangements.

No codes, no program no computer language, very short learning curve, and the
user don't have to spend class in community college learning how to write
languages. No interface compatibility problems.


No memory, thus not able to crash.

And...the system have already proven itself as a performer in a very similar
product, where it has acheved a long number of  record flights.

For cars this system probably sucks, it's too simple,, but for airplanes, car
systems sucks, they're too complicated, by the nature of the beast, car systems
have to be complicated.

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

This 555 system is already a proven winner....and all this for, perhaps 150-200
bucks in material.

Roger


I may be mistaken, but to my knowledge, the 555 system has not been proven.
Anyone on here running a 555 controller for their fuel system?
C. Smith


Yes it is commercially available, it is a further developed product based on the
555 system, it is sold by LightSpeed Engineering.

There might be proprietary elements in that system, and exactly what he has
done, I guess the only way to find ut is to reverse engineer it, but that will
probably lead to legal questions, but the basic concept of his system is the 555
system, so as far as having a 555 system as a proven product, yes it is. I don't
know really what he is asking for his system, but a fair guess would be that
1000 bucks will not cover it.

It has done some record flights, and have been exceptionally successful in CAFE
races, where efficiency is paramount. I do belive that it has flown in Reno too,
I am lesser aware of how successful it is in that arena though, but all in all
it shows that it works wonderful. It is flown regularily on GA experimental
aircrafts.


A VariEze have flown with it, from Ca to Florida, on one standard tank, non
stop, with that system, so all in all, it has very good potential.

Paul Lamars system and LightSpeed engineerings FI system is not the same
product, but they are both based on exactly the same principals, and therefore,
my thoughts here is that Pauls system, need to be built, and tested....knowing
that a commercial product is already out there using it, it therefore have an
already proven concept.

As it is such an extremely simple system, and so cheap to build, I figure that
any possible bug, will be fairly easy issue, compared with a system that takes
seventy eight  pages just to describe the scematics, and laptops have to be
involved, handbook ( if there is one) that looks like NY citys phone book,  plus
data language has to be involved and...on and on. I have been following the
efforts on all the other complex systems....it's endless ...there is always
something that needs to be dendered to.

I just think that this 555 system, is a system that can be brought to a
useable and workable product.....this lifetime.

Roger

I suspect Klaus has gone over to Megasquirt.
There are bipolar and CMOS 555's. I think Klaus used
the bipolar. There is a huge difference.
Pulse width verses control voltage. The
CMOS version is liner while the bipolar version is highly
non liner with a very limited dynamic range.
http://www.rotaryeng.net/simple-cheap-555.html

Paul Lamar


I looked at the lightspeed website. They are selling CDI systems not fuel
injection controllers. Nothing in there about 555 timers. It is making quite a
leap in thought to say these are 555 based.
The 555 EFI is a viable concept, but far from proven. Not flying in anything.
C. Smith

He is not selling any EFI yet as far as I know
The info actually came from me from what Klaus told me several
years ago. He denied the use of 555 but not the 556 which is a dual
bipolar version of the 555.  Klaus is not an electrical engineer.
Paul Lipps designed the system for Klaus. I have never talked
to Paul Lipps about it.

Paul Lipps is an electrical engineer who is fond
of analog solutions. Klaus flew the system for a couple of years
on his O-200 Variez. As a matter of fact it may still be on there.
I don't know why he abandoned it for the Megasquirt (I think) on his
O-360 powered Long EZ. (Not flown yet.)  Perhaps Klaus and Paul Lipps had a
falling out. One possible scenario.

BTW Klaus used to lecture me on the evils of computer EFI and now he is
experimenting with it:)

Paul Lamar

I e-mailed about a year ago, and Klaus told me then, he sold these units...he
described in pretty much detailed of all the features it had, and how it have
been used in all kinds of applications, he mentioned quite a few.......the
555 as such ,  was not mentioned in my conversation with him...but had the info,
from a blog some time ago, ...I think it was Paul that told that Klaus system
was a 555 system, ....but I guess information have been going around back and
forth, and eventually assumptions set in and a wrongful picture was
painted......556 became 555 somewhere....ah.. who's counting???...something got
confused somewhere along the line.....oh well....doesn't matter.


From the info I got, it was all a duck then,... this 555 system have no
commercial similar product...so that takes away from the discussion the notion
that this is a proven product.....

Ah ok.....I reset my calculator then.

Who said what,... is a meaningless debate...looking at it now..... where do we
stand on the 555 system?


Still despite that there has been a confusion of earlier use of it, I don't
think it takes away from the 555 system the fact that it is simple, have no
memory, is redundant in that of one unit fails the rest will work, can be
sequential or batchfired, and that it can be worked and set as a carbureator
with a set screw, instead of computer memory, and is cheap to build, it can't
crash, and far far from complex.

The way I see it, it will have the carbureaturs procedures in
leaning/richening....by reading CHT, EGT and so on, but it will have all the
efficiency advantages of a multi point fuel injection as it's method of fuel
delivery.

I do belive that the raw concept of it, as it stands now, is very close to a
finished FI system, it might need to be worked out if a pressure sensor in the
intake will do, or if a Mass airflow sensor will be needed etc, but I don't
think that is much of a deal in the whole sceme of things. It needs to be built
and tested, and have some initial bugs worked out I do belive.


I will soon be doing some work in the oil field and know that I will do
12/hr/day, some days 14 hours/day, so this will not be something that I can lend
my own time to, but are hoping that someone will take it up and get a working FI
unit out of this, that is easily duplicateable by others.

I think that the basic concept is ...well genious...( applause to Paul) ...and
it is too good of a system to collect dust.

So I am appealing a bit here, with the hope that someone in need of a FI system
can afford to spend 150 bucks and a bit of time, will swing this together and
try what works and what doesn't work.

Roger


The 556 is two 555 in one package. A common practice in IC's.

The secret to making it work is the CMOS version of the 555.

Paul Lamar

Paul, got a bit lost here, the 555 system is on the webpage is a one 555 chip
system, but are you saying that if you would take two 555 chips, per module  it
would be a 556 system?

If so, then a 556 system is basically a double 555 system.

So that leads me to next question, whether the system is developed with one ( a
555) system or two (556) 555 chips, would that change the basic attributes of it
being made in modules that each one is an independent unit, still have no
memory, thus unable to crash, and still be reasonable simple to build and solder
together by a dummie ( like me) , and still be extremely reasonable in cost to
get parts for, and ...would it still be cockpit adjustable( fuel/air) ...or
would it have more self adjusting properties?

Also it leads me to the next thing I wonder, if the 555 system as I see it on
the site, is a one chip system, then would a two chip system have such an
advantage that it is probably the better basic system over the one chip 555
system, ...then...the two chip system is not developed at all...right?....and
the development of the 555 system, then stands at the one chip 555
system...right?

Did I get all this right?

Can you develop a bit on this, so I would know if there might be a future to
look forward on this or if this is something that is a bit on the back burner,
and may or may not be looked at...in the future sometime?

Also...just had a thought here...if Klaus system was a 556 system, that
basically ..as I now understand it....is a double 555 system, then it comes back
to being a proven system that have flown and done good.

Paul, I don't know if I got this right so....better leave the floor to you on
this now.

Roger

If you use a 556 chip technically it is still 555 system.
For a four cylinder engine like the O-200 all you need
is two 556 chips. Yes it is not as modular.
I don't think the CMOS version of the 555 is available in a two
chip package. These pdf's will tell you all you need to know.

Paul Lamar
-- 
The Rotary Engine NewsLetter. Powered by Linux.
ACRE NL web site. http://www.rotaryeng.net
Youtube key word PaulLamar2
Copyright 1998-2011 All world wide rights reserved.