# Designing new Aviation ECU

Discussion in 'Mazda Rotary' started by MolsonB, Aug 16, 2015.

### Help Support HomeBuiltAirplanes Forum by donating:

1. Aug 16, 2015

### MolsonB

#### Active Member

Joined:
Nov 13, 2014
Messages:
26
12
Location:
Hi Homebuilders...

In my conquest to build my first airplane, RAI-1 XR “Tango XR”, | Revolution Aviation Inc., why not go all out and build your own engine (Rx8) and ECU.

This thread will be the R&D of an ECU designed for the aviation rotary. We honestly don't have many options out there. Tracey Crook was the only one, which is no longer in production and Megasquirt which isn't geared towards aviation (no redundancy, and limited analog inputs). My goal is to have dual redundancy on everything from sensors, power supplies to the microchip itself.

My micro-controller of choice is the PIC32MX470F512H. 120MHz, 512KB program memory, 128KB RAM, 12KB flash, 28 Analog/Digital converters. 5 16bit timers
PIC32MX470F512H - 32-bit PIC Microcontrollers

Inputs
Tach 1
Tach 2 *
Manifold Absolute Pressure 1 - Front rotor
Manifold Absolute Pressure 2 - Rear rotor
Intake Air Temp 1
Intake Air Temp 2
Coolant Temp 1 - Before radiator
Coolant Temp 2 - After radiator
Coolant pressure
Oil Temp 1 - Before radiator
Oil Temp 2 - After radiator
Oil pressure
Fuel Pressure
Mass Air flow Sensor 1
Mass Air flow Sensor 2
O2 Wideband Sensor 1 - Front rotor
O2 Wideband Sensor 2 - Rear rotor
Exhaust Gas Temp 1 - Front rotor
Exhaust Gas Temp 2 - Rear rotor
Exhaust Gas Temp 3 - After collector
Exhaust Gas Temp 4 - Near exit
Cylinder Head Temp 2 - Front trailing
Cylinder Head Temp 4 - Rear trailing
Knock Sensor 1
Knock Sensor 2

*Tach 2 = currently RX8 only has 1 Tach, but if someone could come up a bracket to have another Tach 180degrees would be nice)

Outputs
Injector Front A
Injector Front B
Injector Rear A
Injector Rear B

Coil Front trailing
Coil Rear trailing

Oil Metering Pump - Remove OEM unit and build DYI *

*With RX8 having side exhaust, along with premixing oil in the fuel, I want to create my own 2 stroke oil reservoir that will inject oil onto the side seals based on RPM.

Operations
For engine operation, we only need 1 tach, MAP, IAT, CLT. The rest will be used for logging / display purposes. Have control of each spark plug and coil. Speed-Density and/or Mass Air flow will be used to calculate fueling. The PIC should have enough room for ignition tables 16 x 16. The human interface will be from Android tablet program via bluetooth. Allowing to change fuel and timing in real-time and monitoring all sensors.

This will be a huge endeavor, but I believe the Rotary engine is the future for GA planes. Anyone with C programming or hardware design, by all means help out.
Also on the hardware side of things, keep on eye out at cimarron for CNC products.

ekimneirbo, FritzW, ElEsido and 2 others like this.
2. Aug 17, 2015

### rv6ejguy

#### Well-Known Member

Joined:
Jun 26, 2012
Messages:
3,749
2,777
Location:
I see less and less Wankels being fitted to Experimentals over the last 5 years or so. I don't believe there is much of a market for aviation Wankel ECUs because of this but if you have the skill set to design and flight test a new controller for several hundred hours, I say go for it. Just don't look for a quick return on your time or money spent.

3. Aug 17, 2015

### Workhorse

#### Well-Known Member

Joined:
Mar 7, 2010
Messages:
400
61
Location:
Southern Spain
Perhaps one reason is that it's been difficult to set up a rotary because of the lack of a proper system like MolsonB suggest. If he can develop such a turn-key solution, I'll be a customer. I say go ahead Molson!.

4. Aug 17, 2015

### rv6ejguy

#### Well-Known Member

Joined:
Jun 26, 2012
Messages:
3,749
2,777
Location:
You could be right. There are other existing solutions like MoTec, Haltech, Link etc. but they don't offer the redundant part without twin ECUs. On the other hand, these ECUs are much more reliable than the engine they are attached to as is usually the case.

cheapracer likes this.
5. Oct 21, 2015

### ElEsido

#### Member

Joined:
Oct 21, 2015
Messages:
13
4
Location:
Switzerland
Go for it, Molson!

Please consider working with the makerplane.org guys - check their CAN-FIX protocol.

6. Oct 24, 2015

### rmeyers

#### Active Member

Joined:
Dec 20, 2013
Messages:
25
22
Location:
Denver, CO
Thought that if I was going to offer an opinion I should do it before things got too far along.

First let me say that the concept of building a dedicated ECU is certainly do-able.

The problem that I see is the choice of microcontroller. I think that the PIC is a poor choice for this use case, or being more diplomatic, I should say that there are far better choices.

Please forgive me in advance if some of the things that I will say are already known to y'all.

Many hobbyists, or for that matter EEs, are only peripherally aware that Freescale makes several lines of dedicated automotive controllers. This is their bread and butter, not a sideline. I believe that it is still the case that the majority of cars on the road in the USA have Freescale, or Freescale designed, processors. They range from triple core fully redundant PPC models at the top end to ColdFire, a MPC68000 upgrade, at the lower end. Freescale chips are highly integrated, with all of the requirements of the OP in one chip. An example, and I don't know if this is exactly the right chip for the job, would be the MPC5644A. Power PC e200 core (I seem to remember), 150 mHz, 4 meg flash ram for program storage, 196K ram, 40 A/D channels, Serial module (SCI), 3 CANII buses, SPI and the list goes on. Most importantly, and I do mean most importantly, it has 1 eTPU2 module. The TPU is what sets the Freescale chips apart from all others.

Skip this if you're not interested in what the TPU does.... TPU stands for Time Processing Unit or Time Processor Unit, Motorola/Freescale can't seem to decide. Effectively, it is (oxymoron alert!) an autonomous slave processor. It is optimized for high accuracy counting. The eTPU2, the most current version, has between 32 and 64 channels per TPU. Each channel can be configured as an input or output. Each channel can run a simple program, conveniently provided by Freescale. In its simplest form, channels 0 and 1 would keep track of the crankshaft and camshaft position, respectively, and higher number channels would fire the injectors and sparkplugs, one channel for each. The interface between the TPU function and the CPU code is a simple variable. In other words, the CPU decides how much fuel, duration of spray, time of injection start, or finish, when to fire the sparkplugs, etc. and the TPU does it without any further intervention from the CPU. In fact, the TPU and CPU have separate power supplies and one or the other can crash/reboot without affecting the other.

Basically, the TPU relieves the main processor from having to count. This is super important!

Think for a moment about how processors without a TPU determine crank position. All modern engines use a timing wheel of some sort on the crankshaft, for example; 60-2, a wheel with 60 square teeth with 2 teeth removed, 36-1, 40-2, 40-2, etc. The PIC processor above would have to either periodically check the hardware crank sensor to determine it's state or it will need to generate an interrupt on every tooth transition. Either way, the CPU only has the time between teeth to do all of its calculations. It can, and has, been done, but the cost in code complexity is enormous. You will always have to calculate and worry if the new code you added runs over your time allotment. This description is actually a not very accurate portrayal of what goes on with a non-TPU processor. The point is that there are some very serious issues with this approach.

Here is how I see the pluses and minuses of the TPU vs non-TPU approach:

Cost of hardware:
CPUs; Nearly a wash. The MPC5644A can be purchased at approx 20 something dollars in quantities of one. I'm sure the PIC is much cheaper, but these aren't big numbers on any scale.
Boards; The 5644 will require a 6 layer board, minimum. If you are attempting to put all of the driver and I/O hardware on the same board as the processor, the PIC will need 4 layers minimum, probably 6. Because of the high degree of peripheral integration, the 5644 may end up a smaller board.
Components; Again, because of the high degree of peripheral integration, the 5644 will probably use fewer on board components.
Enclosures-connectors; No difference.
Dev Board; Pic probably wins this one. I'm not terribly familiar with the PIC development environment but it's probably cheap. A dev board for the 5644 will run about $300. Bootloader hardware; Pic is probably$25 to $85 dollars, MPC56xx is$200, Freescale Coldfire about the same as PIC.

Software:
Tools; Pic tools, IDE, compiler, bootloader software are probably free, I know that a lot of Atmel stuff is. PPC tools run from stupidly expensive to free. CodeWarrior for the embedded PPC runs \$6000 per seat. On the other hand, for example again, ST Micro makes the same chip as the MPC5644A, (either under license or a joint venture, I don't know, it is the exact same chip), called the SPC564A, and provides a free IDE, compiler, bootloader, and real time operating system. I think that all of the aforementioned stuff is also free for the ColdFire line.
The Code Itself!; There is at least one open source project that I know of for TPU equipped processors that could be readily adapted to any other TPU equipped processor family. For the non-TPU project you could probably look at the original MegaSquirt source code to see how they did it, but keep in mind that the original source code is all in assembly language. Not sure if later versions are open source or not. Since it's all in assembler, you couldn't use it on another architecture anyway.

Personal Feelings: On balance, the PIC, or similar, is easier to get set up and get some code running. The Freescale processors have, unfortunately, a much steeper learning curve. Most of the effort is in learning to set up the various modules on the chip, A/D, CANII, SCI, etc. However, once set up you never have to mess with them again no matter what changes you make to the fuel/spark code. Freescale modules are all semi-self sufficient. Set 'em up and don't mess with them. The PIC and others of its kind, ARM, Atmel, etc. give you easy access to the hardware registers and it is easy to set something up and get it running. However, whenever you make any changes to the main code base you have huge rewrites. This really slows you down and makes debugging more difficult.

Overall, the PIC will get you up and running more quickly than a Freescale part. However, code complexity will balloon exponentially and progress will slow at the same rate. The Freescale solution takes longer to get going, but strangely enough, it gets easier as you go. You will arrive at the point of a safe and reliable aircraft quality ECU far, far, quicker with the Freescale (or ST) part.

AdrianS, MolsonB and ekimneirbo like this.
7. Oct 24, 2015

### rv6ejguy

#### Well-Known Member

Joined:
Jun 26, 2012
Messages:
3,749
2,777
Location:
We've always used Mororola (Freescale) in our ECUs. Once you learn the ins and outs of a particular family, you tend to stick with it. I think many people get carried away with how much processor you need for a basic job like this (run the fuel and spark) which is way different than what OEMs are doing with their CPUs (millions of lines of codes and eyewatering complexity). You really don't need ultra fast or huge memory. The engine timing and injection events are running at a glacial pace compared to even an old 68HC11 running at 2Mhz. The big thing you need with EFI ECUs is usually lots of timer pins, especially if you want to do timed (I hate the term sequential) injection and run individual coil channels for COP.

You're right about processor cost- even a high end processor is a small overall cost in the scheme of things to develop a new ECU.

8. Oct 25, 2015

### ekimneirbo

#### Banned

Joined:
Oct 31, 2014
Messages:
1,009
324
Location:
Deep South
Always good to see fresh ideas and enthusiasm. Do you plan on displaying all the data or just logging some of it? Also
wouldn't you have a better chance of success if you tailored the ECU to conventional 4 cycle engines where there is a
larger market and include the ability to control and monitor rotary engines rather than exclusively for rotary engines?
I wish you luck with your endeavor........

9. Oct 25, 2015

### rv6ejguy

#### Well-Known Member

Joined:
Jun 26, 2012
Messages:
3,749
2,777
Location:
The Experimental aircraft ECU market is at least 98% piston engines these days. There is no good business case for doing Wankels only IMO unless you are going to do it from your basement so to speak on a shoestring budget. Don't forget that you need to do tech and customer service along with design, testing and manufacturing. Lots of smart folks could write code, some others design reliable hardware, few can get it into production, properly validate and test it, support it properly and run the business side while making money. If you can do all that, power to you as I said before.

We are working with a German company now who is starting to manufacture new build Wankels (owning the original engineering and some tooling) for UAV, Experimentals and off road applications. We'll see where it goes but are ready to supply this market if it flies so to speak. We have aircraft dedicated, dual fully redundant ECUs for most popular engine types. Just introducing some new features now and next month to make them even more appealing for the traditional aviation engine crowd which is by far the largest market currently.

10. Dec 21, 2015

### MolsonB

#### Active Member

Joined:
Nov 13, 2014
Messages:
26
12
Location:
Wow I don't know how I missed getting updates from this thread. Just to point out though, this wasn't a post of creating a business. Just a fellow hobbyist sharing his ideas with others.

PM
rmeyers - Incredible information you provided. Just amazes me in the spot on info without knowing much about me. True, I've only used PICs before so I'm comfortable with all their setup. But they don't have the timers like the Freescale (as you mentioned) which was causing more headaches and math. I started to look into a freescale dev board but I just don't have the time or resources to learn something new right now. I want my engine running this spring on my test stand.

All and all, it looks like it makes more sense to stick with a MegaSquirt. They have features that most high-end ECU's don't even support yet. I'll design a board that will support dual power supplies / cpus. Cut out all the unnecessary circuits that we won't use and add the ones we will. You can tune their software via bluetooth and your Andriod or laptop. I'll even come up with a 'translator board' that will convert Megasquirt serial output to be accepted by other EFIS brands. (I already have engine info displaying on my GRT from Megasquirt.) I don't know if other brands give out their serial EIS protocols like GRT does. If they do, pass them along to me.

Again this isn't a business, it's for my own use. But if people like what they see, they can buy their own hardware and follow along.

11. Dec 21, 2015

### rv6ejguy

#### Well-Known Member

Joined:
Jun 26, 2012
Messages:
3,749
2,777
Location:
I just read about a company offering 555 based controllers which they have on working engines now. These will be about 1/10the the cost of the MS even...

12. Dec 21, 2015

#### Well-Known Member

Joined:
Nov 12, 2008
Messages:
129
39
Location:
-
The 555 scheme is incredibly simple and dirt cheap. It is not for GDI, though.

Last edited: Dec 21, 2015
13. Dec 21, 2015

### pwood66889

#### Well-Known Member

Joined:
Feb 10, 2007
Messages:
1,376
129
Location:
Sopchoppy, Florida, USA
My thanks to rmeyers for his insightful post.
I helped a guy migrate his angle of attack measuring system from analog to digital and we used the PIC. His comments regarding ease of starting to use a PIC are spot on. They can be programmed in BASIC of all things! He makes an excellent case for going to the Freescale with a TPU, though, and there may be less expensive development environments available if one is looking.
Regarding the 555 (triple-nickle) timer; it is a very robust, cheap chip. Design will be more hardware than software, with the changes that involves ("Hardware is easy, while Software...").
Glad to see the thinking going on here!
Percy in SE Bama

14. Dec 22, 2015

### rmeyers

#### Active Member

Joined:
Dec 20, 2013
Messages:
25
22
Location:
Denver, CO
Ross, were you referring to the simple 555 timer or the MPC555?

15. Dec 22, 2015

### rv6ejguy

#### Well-Known Member

Joined:
Jun 26, 2012
Messages:
3,749
2,777
Location:
Just 555 timers. Old and cheap as dirt.

16. Dec 8, 2018

### MolsonB

#### Active Member

Joined:
Nov 13, 2014
Messages:
26
12
Location:
Well life has shifted me in many directions, and I'm finally back on my plane. Spring 2019 should be final inspection and flying. Lots of ground testing from now until then.

I ended up going with the MegaSquirt. I did create my own Teensy (ardiuno) board, to add all the extra functionality through the can-bus system.

Few things I've added / remove from the list
-Ability to control linear & PWM motors. This controls coolant & oil outlet butterfly valves, based on temperature settings. Minimizes drag, while keeping rad temps where you want.
-Flex fuel sensor, so if you get mogas vs pumpgas the fueling tables will adjust.
-Push button start & shutdown. Just because it's cool. lol

-Removed CHT's
-Removed MAF's