# Industrial engine electronic management system development - HBA style

### Help Support HomeBuiltAirplanes.com:

#### Hot Wings

##### Grumpy Cynic
HBA Supporter
Log Member
I promised this a day ago. Got sidetracked with an FTDI driver that didn't work anymore and a few other chores......

New topic: Industrial engine electronic management system.

Answer the basic questions - Who, What, Why, Where and How.

Who:

Me. The ICC – Interim Committee Chairman.
And you, based on the ASTM committee/sub-committee develop and vote model.

The various ‘There needs to be’ threads here on HBA have never gotten past the loose conceptual stage. Design by committee just doesn’t work unless there is structure. The quickest way to get structure is with a leader. I’m appointing myself as leader of this project. If I get any followers great! If not, well that’s life. Further down the road if the group decides that a coup d’etat is needed for whatever reason, well that may be a good thing. It means that there is a group that wants results.

What:

An aircraft grade engine management system for 1L and smaller twin cylinder industrial engines. Notice that is not just an EFI system I’m proposing. EFI may be the only part of the system many will want to use. I think we can incorporate the ignition system and other bells and whistles, such as constant speed prop control, as modular options after the base is working as desired.

Why:

There is a demand for inexpensive 4 stroke engines for light aircraft. The industrial engines have been shown to be a viable option but as with everything they could be improved. The various manufacturers are starting to implement EFI on their commercial products because they understand the benefits of better fuel control and EFI in particular. We could just wait for these versions to become common on the market, but aviation use requires some features that commercial industrial engines simply don’t need. It is highly unlikely any engine manufacturer will develop an EFI system that is truly aircraft grade. There just isn’t enough market to justify the development time. That will be our job.

Where:

Here on HBA, to start.

How:

Go watch this video by our very own HBA member Boku.
This will answer the How for the project. I could eventually come up with a system for my personal use that works. I just don’t have that much time even though by nature I’m a solo kind of guy.

Next:

A starting point.

Note to moderators:
The other EFI thread is in this folder. If it would be a better fit in another please move it.

Last edited:

#### Hot Wings

##### Grumpy Cynic
HBA Supporter
Log Member
The starting point

Attributes:
Pretty well covered in this thread
Summation, in no particular order:

To me this means eliminate as many single point failures as possible. Of those that remain they need to be uncommon and benign enough that the risks would be tolerated by the average consumer.
2) Inexpensive, not cheap
If we count our time at minimum wage to develop this we have about a 1% chance, overall, of meeting this goal. Cheap in this context means only the cost to an end user of what we develop for parts and their time to assemble, buy, install and tune.
3) Simple.
This is relative to the individual, but it needs to be simple enough that the average aircraft builder can, with good documentation, install and safety use what is developed here.
4) Makes use of as many off the shelf parts as practical.
Those parts should be available from more than one source and should have a high probability of being available in the future.
5) Should be as light, compact and as reliable as the current OEM carburetors.
Hopefully it will be better in at least 2 of those 3 parameters.
6) Should provide better fuel economy.
7) Should provide automatic altitude compensation
8) Should easily interface with other aircraft systems.
9) ??????

How to accomplish the above goals?:
A) Define the features desired and those that are needed.
B) Identify and develop hardware that will get the job done.
In the interest of simplicity, I propose that this be done with open source resources as much as possible. Arduinos are an obvious option. Pyboard and Teensy are 2 others. They both use ARM Cortex M4 chips. There is a plugin for the Arduino IDE for the Teensy and it may work with the Pyboard as well? If not there are options to load software to any of these chips without using the Arduino IDE.
Sensors are readily available from many sources. We just need to define what to use and where.
C) Software will be needed. Again, Arduino/C++ is an obvious choice for source code.
For circuit design Fritzing is one option. There may be other free open source options?
There are also student versions of some software available. NI Circuit Design/Multisim is one.
D) Build on what others have developed. I was recently made aware of the Speduino project on the other thread. It looks a good source of ideas and code for us to build on? It is more general and street racing oriented than what we will end up, but it at least is functional. For those that are new to EFI this is a good basic outline of the How: http://www.faqstels800g.ru/data/docu...ool-Manual.pdf

So, this is my proposal. If there is any interest lets get started with adding anything needed to, and deleting the fluff from, the “Attributes” list, then move on to A)

#### Vigilant1

##### Well-Known Member
Regarding proposed attributes:
1) . Should we specify that the unit should be able to use 100LL? That would drive us to an open loop system. Or, we could do some research and then decide if the 100LL attribute is worth the cost. I personally would like to be able to use 100LL at least occasionally without needing to replace a sensor.
2) Have we covered failure modes enough? I want to stay airborne even with several failures.
3) Fault detection/diagnostics? It would be nice to know what parts have failed.
4) Electrical requirements? Many B&S engines have 16 amp alternators, and I'm not sure how long they'll hold up if asked to do that continuously. The Harbor Freight 670cc engines have a very small alternator, I believe. The EFI can't use every bit of the available juice.

Other available resources: Maybe study the B&S EFI system to see what choices were made in its design, what injectors, pumps, and sensors were selected, etc. It won't all apply to aviation use, but they sell a lot of them, presumably did some expensive engineering, and their worldwide dealer network might be a source of spares if we use some of the same things.

Thanks for taking this on.

Last edited:

#### rmeyers

##### Active Member
What license do you propose for the embedded software?

#### Vigilant1

##### Well-Known Member
Regarding Attribute 8 (should interface with other acft systems): So, do we want this to feed us RPM, fuel flow, manifold pressure(?), In a form that can be readily used by some existing (cheap) engine mgmt software, or is it he design of that display software part of this project? Wired or wireless? This attribute would be very nice, but it might be a lot to take on, not useful to everyone, and full of future headaches if display software manufacturers change data standards, etc. ("Hot Wings, my EMS won't work with the MGL display I just bought. Can you guys modify the code for me?" No one is going to want to take that recurring hassle on). Maybe a cheap, standalone dedicated display just for this program will be less of a headache. Not as elegant, but in keeping with the vibe of this effort I think.

Last edited:

#### Hot Wings

##### Grumpy Cynic
HBA Supporter
Log Member
What license do you propose for the embedded software?
Still thinking about that. If we base it substantially on the Speeduino then the choice has been made.

I personally don't have any problems, in this case, with letting someone use the code as the base of a closed project. There just isn't enough money involved with the end use to have to worry about someone getting rich using our work?

CopyLeft

Edit:
This is one of those decisions that I think should be made by the members of this committee after discussion and voting.

Last edited:

#### Hot Wings

##### Grumpy Cynic
HBA Supporter
Log Member
My first attempt at defining the features desired and/or needed.

First those features that are needed:
1) A reliable, accurate and repeatable way to deliver a combustible fuel mixture to the engine under all anticipated conditions. Pretty basic.
2) ???

Features that are desired:
A) Oxygen sensor feedback:
This may be the first decision to make. Other than the old, no longer available, Subaru Robin I don’t know of any industrial engine that has, or will, come with a simple open loop (no O2 sensor) EFI system. All the current industrial engine EFI systems use an O2 sensor. In the case of the Kohler they specifically say that it is used for closed loop only under constant conditions after the system is fully warmed up.
The problem with using an O2 sensor is that we are still stuck with having only 100LL available at most airports. Current options are to just use the OEM EFI and find mogas or use a carburetor. For the purposes of this project I propose that we develop a system that can be used both open and closed loop. We will need a good wide band O2 sensor to develop the basic mixture map. The cost of the hardware for the wide band sensor and controller chips is under $100 with the sensor itself being most of the expense. The chips for driving and sensing a Bosch wide band O2 sensor are around$5. For those on the cheap side they can borrow/share a sensor for initial setup is the hardware is already on the EFI control board. The software can be designed to be user selectable to run closed loop or rely on only the map in memory.
B) User interface:
None is really needed except during setup and calibration. But to make diagnostics and upgrades easier there should be some form of user interface. Options are USB, CAN, and wireless. USB is already on most of the boards that are likely to be used. CAN has the advantage of an extremely robust data stream and a well-defined standard. Wireless, while not required, does provide some user-friendly options. It should be considered as an add on?
Using CAN gives us the option to send the data from the EFI sensors directly to an engine monitor. There is then no need to duplicate sensors for the display. The actual display should probably be a separate project? I'll have to double check but I think we can use CANAero standards. Wireless, other serial standards may work too?
TunerStudio interface/compatibility. I know zero currently about how to go about interfacing with this software. Speeduino does so this should be an option for this project?
C) Sensor suite:
The more we have the better as far as data collection. At the very basic we need a MAP a TPS and RPM. The problem with only the basics is that if one quits the whole system quits, or at the very least goes into a very primitive limp mode. By using other sensors like coolant and air temp, EGT, and O2 the software can make a best guess, if one of the basic sensors fails, and support a less primitive limp mode. By cross checking the other sensors the software can track sensor drift and maybe warn of potential failure. The use of dual sensors helps with this task as well as providing redundancy. Cost is a factor to be considered.
Does anyone know of a small inexpensive way of measuring mass flow suitable for a 1L engine?
D) Redundancy:
Dual CPUs that cross check one another is desirable but does add expense. The boards likely to be used can all be purchased for less than $25 each. A little more for the Teensy 3.6. E) Data logging: Internal, External, or both? #### Hot Wings ##### Grumpy Cynic HBA Supporter Log Member 4) Electrical requirements? Many B&S engines have 16 amp alternators, and I'm not sure how long they'll hold up if asked to do that continuously. The Harbor Freight 670cc engines have a very small alternator, I believe. The EFI can't use every bit of the available juice. The electronics won't take much. Most of the boards we might use have a max load of around 500mA. The injectors, and fuel pump will the the big load with a wide band O2 sucking some during warm up. ("Hot Wings, my EMS won't work with the MGL display I just bought. I'm kind of insensitive to these kind of problems. If someone purchases something with proprietary software or hardware - that's their problem, not ours. I like standards. If the standards evolve, then we should try to keep up, but most good standards are backward compatible. For example we can plug a USB 1.0 flash drive into a UBS 3.0 port and it's going to work. #### Vigilant1 ##### Well-Known Member Lifetime Supporter A) Oxygen sensor feedback: . . . .For the purposes of this project I propose that we develop a system that can be used both open and closed loop. We will need a good wide band O2 sensor to develop the basic mixture map. The cost of the hardware for the wide band sensor and controller chips is under$100 with the sensor itself being most of the expense. The chips for driving and sensing a Bosch wide band O2 sensor are around $5. For those on the cheap side they can borrow/share a sensor for initial setup is the hardware is already on the EFI control board. The software can be designed to be user selectable to run closed loop or rely on only the map in memory. Is there a significant advantage to relying on closed loop for the calibration/setup after the system is installed? Can the same thing be accomplished open-loop by using EGT? If we use use closed-loop to calibrate (with pump gas containing real gasoline and 10% ethanol) and then run the system operationally using 100LL (that has different attributes), will we be getting things right? Further, mybe it would be practical to develop mixture maps as part of the centralized big project, with the end user just selecting one from the library, fine tuning using a "mixture knob" potentiometer knob in flight. That same "mixture knob" could be very useful in some "limp home" modes. D) Redundancy: Dual CPUs that cross check one another is desirable but does add expense. The boards likely to be used can all be purchased for less than$25 each. A little more for the Teensy 3.6.
The logic needed to compare the CPU results introduces another possible faiure mode, and may make troubleshooting more difficult. "A man with two watches never knows the time." It would be simpler to have two entirely independent CPUs/boards with a toggle switch for selection in the cockpit, testing both is part of the lineup check (like a mag check). In flight, if you don't like the way things are running, go from "CPU 1" to "CPU 2" and see if things clear up. If both CPUs have backup modes to deal with sensor failures, there's a lot of redundancy there.

#### Vigilant1

##### Well-Known Member
Attributes: Is this to be a throttle body injection (one injector for the entire engine) or port injection (one injector per cylinder)? One injector is cheaper and easier, would allow maximum commonality between single and twin cylinder engine installations. Individual injectors per cylinder allows better tuning for (what are likely to be) non-optimum induction systems, probably better CHT management, better fuel economy, and possibly longer engine life (each cylinder gets a more precise mixture, so less overheating from being too lean or oil dilution from being too rich).

ETA: Due to the uneven firing (and induction) interval of V-twins, most airplane installations I've seen use dual carbs. As we won't be trying to time the fuel injection events with each cylinder's induction stroke, a separate injector per cylinder (port) would be mandatory, I think.

Last edited:

#### rmeyers

##### Active Member
Don't know too much about ARM based MCUs. My background is in embedded automotive engine controllers.

All of the things requested so far are certainly doable, CANII, USB, WIFI, on-board ADC, etc, but feature creep will kill a project like this in a hurry. I think that what you are doing here is the right approach. Get a consensus on what features the proposed unit will have, lock them in, and then pick a chip architecture. It may be found that ARM based solutions will not suffice. NXP (nee Freescale, nee Motorola) have hundreds of embedded processors specifically designed for automotive use. They have demo/dev boards in the Raspberry PI price range, and they will sell you one or 100. These boards will have everything you need except the high power outputs. They also have free SDK and developer tools for the less expensive chips. One of the smaller ColdFires would be just about right for this usage.

The downside, and it may be considerable, is the learning curve. Everybody and their uncle seems to have ARM experience these days and there appears to be on the close order of 100,000 videos on YouTube about how to get started. The ColdFire is based, loosely on the old Motorola 68000, so it's not that hard to deal with. The steep part of the curve is in the functional modules of the chip. QADC (analog to digital converter module), eTPU (timing input/output module), CANII module, USB module, etc, are interesting to set up but incredibly powerful and easy to use once set up.

One last thing. Vigilant1 said "A man with two watches never knows the time." and he is absolutely correct. Two processors is just begging for a deadlock. All of our military stuff requires three processors so they can continuously vote. Now that gets complicated.

#### Hot Wings

##### Grumpy Cynic
HBA Supporter
Log Member
Is there a significant advantage to relying on closed loop for the calibration/setup after the system is installed? Can the same thing be accomplished open-loop by using EGT?
I don't think there a significant advantage to running closed loop for our mission. We will probably have to have different maps for the different fuel blends, unless we add a fuel type sensor.

Attributes: Is this to be a throttle body injection
No. Maybe a third injector upstream used as a backup/limp? The charge savaging of the V-twin kind of eliminates the throttle body approach.

One last thing. Vigilant1 said "A man with two watches never knows the time." and he is absolutely correct. Two processors is just begging for a deadlock. All of our military stuff requires three processors so they can continuously vote. Now that gets complicated.
Understood. Even with 3 in on the vote unless there are dual sensors to cross check - Democracy can still be wrong. There may be software ways to simulate a third CPU/pilot, but I don't want to get into that here, at least until I've had some time to actually try a few things. Ultimately giving the pilot the choice, as Vigilant1 mentioned, to pick which CPU to run the show may be the most practical solution?

HBA Supporter
Log Member

#### Hot Wings

##### Grumpy Cynic
HBA Supporter
Log Member
NXP (nee Freescale, nee Motorola) have hundreds of embedded processors specifically designed for automotive use.
Something like this might be an option?
NXP MM912_P812

The only problem with something that is not common in the hobby world is that soldering surface mount requires tools and skill that have a rather steep learning curve.

#### blane.c

##### Well-Known Member
HBA Supporter
Just a couple quick thoughts on this.

On the surface I like the idea of two processors and the ability to manually switch between them. I have reservations that the processor may be the least likely point of failure and switching to a second one will just be verification something else is wrong. Still worth a shot if you are a single engine aficionado but for multi-engine the second engine and limp mode on the problem child may suffice.

100LL the lead is a problem. Maybe a toolkit so you can remove oxygen sensor when 100LL is all that is available and a program dedicated to running on it. I mean we know the sensor is just going to puke so why insist on it being there? So we can hold its hair? It just doesn't make sense. Lead is not a problem for billions of users so fixing that problem is likely a deal killer for the project. A work around is more practical I think.

Throttle body's were the first injection systems to go on the American V-8s and V-6s. I bet it was because it was the easiest (spelled least expensive). That said two cylinder independent induction just doesn't "sound" that difficult, your going to be running an ignition timer so the basic data for timing must already be there? Is it enough better to justify two throttle bodies and two injectors or … ? I look at the Walbro unit for example, they are doing it for among other things compliance with emission standards and it looks throttle body to me.

#### blane.c

##### Well-Known Member
HBA Supporter
Do all the boards require the same inputs? If some of the boards support software that requires less input is that a good thing? What is the minimum number of input pieces that will work for this project considering working around leaded fuel? Maybe the answer to that will eliminate a few boards as options.

If a piece will give the board multiple data inputs it may reduce cost and weight and if one piece of data is going to send you into limp mode anyway what's the downside?

Maybe figuring out the minimum amount of input that will work will help?

#### Hot Wings

##### Grumpy Cynic
HBA Supporter
Log Member
o Is it enough better to justify two throttle bodies and two injectors or … ?
I think so. Way back when EFI was still analog VW thought port injection was enough of an advantage that they added a second set of points to pick which injector to fire. Throttle body would have been much easier.

As for the O2 work around maybe a reasonable compromise would be to develop the basic map with a wide band sensor and then run a cheap unheated narrow band in service? Maybe design an on/off fitting for the O2 bung that lets the pilot twist something 90 degrees to shield the O2 sensor from the exhaust gas. At the same time a switch lets the CPU know the O2 sensor is on holiday. This probably wouldn't work with a wide band because of the heater.

Do all the boards require the same inputs? If some of the boards support software that requires less input is that a good thing?
Attached is a quick Excel file of the common EFI sensors and how ;they attach to the CPU.
View attachment Sensor types.xls

Need to learn how to use the tables here. :emb:

Last edited:

#### Vigilant1

##### Well-Known Member
Okay, we're all done here. And it does ignition, too.
One day, a new record!!

Seriously, pros and cons of going with this ( or similar) embedded controllers vs Arduino, etc.