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,
Interesting points! I have both the pro and open source tools.
I will make some comparisons and report back! I agree production validated code
is expensive. I think that a properly configured open project could rival it in
many ways today....
Here is a thought, what about megasquirt ported to the mototron platform?
David Goings
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.