Gauging Interest: Open-Source/-Hardware Engine Management.

[NorthWet]

Edit:  Added some new thoughts at the bottom of this post.  endEdit:

 

If you could have a cheap electronic box that made your modding easier, what would you want?  I am not talking adding performance, but rather making things simpler to do, such as "EJing it", or putting SPFI onto an EA81.

 

For the last couple of months, I have been looking into nearly off-the-shelf hardware for engine management.  The realm of microcontrollers has really blossomed since I last looked at it some 20 years ago, as has process-sensing/-control electronics.

 

There has also been a movement, similar to LINUX in the computer world, to provide "open" access to both software and hardware that make microcontrollers practical for many different projects.  For as little as US$15 you can get a fully functioning processing heart (and its compiler/assembler/software-tools) to add it to nearly any project that you can dream up.  Just add power and the hardware that you want to monitor and control. For US$50, you can get 5-10 times the capabilities.

 

Along with this, many electronics companies are producing low-cost ICs for use in industry and engine management.  Most are designed to interface directly with the cheap microcontrollers.

 

I am working towards a couple ECUs for myself: an MPFI one for me EA82s and EJs/EGs, and probably a simpler one for SPFIs.  These would be basic units at first, just as proof-of-concept.  If they work out, they open up a very wide door for me.  With a little effort, virtual reality comes to engine-/system-management.  Parts can be made to appear as something different, signals can be altered or synthesized.

 

Any thoughts or wishes?

 

Added 06-06-13:

     Helpful gadgets are also something to think about.  Something that should be simple is an electronic heater-fan controller to replace the failure-prone resistor pack.  It is likely to be nearly the same price as a new resistor block, but with the added advantage of being customizable.

     Another thought would be various gadgets to fit in the clock hole in the dash.  GPS, inclinometer, MP3 player, clock... lots of possibilities.

Edited June 6, 2013 by NorthWet

[Crazyeights]

It sounds great. The hardest part of an EJ swap or SPFI conversion would still be the wiring harness though, correct?

[NorthWet]

It sounds great. The hardest part of an EJ swap or SPFI conversion would still be the wiring harness though, correct?

The possibility exists of making a separate, simplified harness. If one goes to distributed processing, it is possible to reduce wiring to a few nodes connected by little more than power, ground, and a comm cable similar to network cable.

[sikend667]

i too have been looking into this and think its a great idea! tuneability can be added in later as for most ej swaps it isnt nessisary until much later down the line

[presslab]

I always thought it would be fun to do an ECU.  There is of course the Megasquirt, but it's pretty stone age in it's technology.

 

Features I'd deem important are wideband o2, boost controller, drive by wire support, knock sensor (with software adjustable filters), high speed datalogging, CAN, etc., to name a few.

 

Some kind of hard real-time OS would be great, maybe FreeRTOS.

[bluto5]

im sure someone could do it better (harder better faster stronger) than megasquirt but i think youd have to be really bored to try.

 

cheap($170 to control a ea series and $260 for an ej) and ready to go, order it as a kit and solder it together for the diy feel. it can run almost any engine with capabilities that surpass 97.5% of tuners in the universe.

 

 

 

sam

[NorthWet]

The real advantage here is that it would be completely open to change.  Megasquirt is closed off to the user, and the decent ones, last time I priced them, were closer to US$350.  I think that I can come in under US$100 (maybe even US$50 for the ISPF), and have a platform that I can expand or simplify as I please.  

 

There is also some VERY interesting stuff that can be done using the the spark-plug as an intrusive sensor... but you have to be able to monitor the coil(s).  Simple electronics, but processor intensive.

 

Perhaps the most useful items might be emulators, open boxes that allow the use of generic sensors such as TPSs, MAFs, temp sensors. Or convert from MAF to lost-cost MAP sensors.  Or emulate an Optical SPFI distributor using a standard EA81 distributor.

[Scott in Bellingham]

_{Im interested in a stand alone system for doing EJ swaps, all brand new so  a guy that putting a  EJ 2.2 or similar in a old EA car can just do it with the engine nad wont have to have the doner harness thinned out}

[NorthWet]

Scott, that was one of my thoughts, too.  I am likely to EJ a Brat for my wife, and it would be nice to do little more than mount a couple feet of wire and a box or two.

 

BTW, the thing that got me started on this thought -path was coming across an "Arduino", a design concept from a school in Italy.  I really liked the philosophy behind it.  Most of the Arduino products use ATMEL 8-bit processors, but at least one uses a 32-bit processor that runs at up to 85 MHz.  (That may not sound like much,but the EA series processors were 1 or 2 MHz).  ATMEL  MCUs come in a dazzling array of capabilities, and start at less than US$1 each.  Distributed smarts, anyone???

[Scott in Bellingham]

if there was such a product I would be interested in building and selling it at my store, my brother sets up and programs programmable controlers for industry, if we could get all off the shelves parts that would be a plus, are you thinking of using all the stock Subaru sensors and FI parts or ?  , are the plug ends available to plug into the stock parts?

Edited May 31, 2013 by Scott in Bellingham

[NorthWet]

The injector connectors are pretty standard, IIRC. Haven't looked too closely at the EJ's other connectors.  You could use pretty much any sensors that you want, as long as the data you need can be extracted.  Industrial MAP sensors and TPS are pretty cheap (I am planning on doing a TPS/emulator for my SVX-only TPS).  The connectors are likely to be the most expensive part, if the rest is done right.

 

Basing it on one of the Arduinos would be useful, as Amazon.com and Radio Shack carry these.  I forgot to mention that the Arduino project was started by artisans, not total computer geeks.  The idea is to open up new possibilities in the Arts/Industrial-Arts. 

 

On the engine/tranny control side of things, MAXIM and FREESCALE (a division of MOTOROLA) offer very useful, highly integrated ICs.  MAXIM has a "dual knock-sensor" processor, and a "dual VRS" processor, both for less than US$10 each.  FREESCALE  has an interesting series of ICs, including one that will actuate and monitor coils and injectors for a 4-cyl engine (MCZ33810), some that will do similar for a single coil, single injector engine.  They also have load drivers (solenoid, lamp, etc) and others that monitor if solenoids actuate properly.  There are automotive "ignitor" IGBTs (transistors) for around US$2 each (1 needed for each coil).  A veritable smorgasbord of LEGO blocks...

[Scott in Bellingham]

a project Id like to do someday is make a engine with all electronic control, no timing belt, no cams just

electronic silinoids on all the valves, a sensor on the crank and a few injectors, the valve timing , injection, and spark would be totally adjustable , could have a computer in dash and different preset choices for either lowend tork, highend power, fuel economy and soforth, with sensors on the engine and computer controlled its endless the changes and choices you could have, would be fun to play with

[JWX]

http://www.diyefi.org/

 

The guy that started this wanted a open soruce MS. Sounds basically like what you're trying to do here. I haven't followed what they've done for the past couple of years though.

[NorthWet]

I imagine the valve actuation would need to be electro-hydraulic or electro-pneumatic.  I would think that direct solenoid actuation would not work well above a relatively low RPM (the power demands would be too great).

 

Although I love to "blue sky" engineering ideas, lets see what would be simple and beneficial in the here-and-now.

 

As I typed earlier, one of my wishes would be to have open-boxes near where they would be used, rather than tucked away in a nice, dry and climate-controlled passenger compartment.  I have not as yet convinced myself that I know how to keep boxes dry and not too hot.  Anyone with experience in this so I don't have to "reinvent the wheel"?

[NorthWet]

http://www.diyefi.org/

 

The guy that started this wanted a open soruce MS. Sounds basically like what you're trying to do here. I haven't followed what they've done for the past couple of years though.

Yes, I found that site a few weeks ago.  I have gotten some very useful information, and leads on what to look for elsewhere.  The impression that I get is that there are a bunch of people "doing there own thing", with little common goal or coordination.  Lots of energy and time and money expended trying to "reinvent the wheel".  Their's does not seem to be a "LEGO" (interchangeable building-block) concept, which I think is crucial to making something like this practical.  I want to use a common and cheaply available processing platform (which starts out with more capability than our original ECU processors), use general-purpose sensor hardware and control hardware, a simple interconnect between modules... and well designed, modular software.

[idosubaru]

other cars have the ECU in the engine bays, i'm sure it can be done.  insulate and keep the heat away shouldn't be a big deal.

 

i'd be interested in gas mileage improvements, though i know you ruled that out.

would it still control the check engine light parameters too - if so i'd love to dial out the stupid P0420 debacle.

 

i'd think it would need to come in under the cost of a stripped harness - which i think folks charge like $200 for...if i did a swap i would totally pay them to do that stripping and so if there's an off the shelf box i'd also go that route.  but some/all of them also quit doing that - so you might ask them why - what problems did they encounter or was it not worth their time?  and what kind of demand did they have?

 

you are exactly right about maknig it practical and simple.

projects quickly get out of hand. start out with a simple and great idea and gets complicated because each person wants one thing slightly different, style, color, fucntionality, fit, different year, motor, country.  simple sounds smart. 

 

95-99 EJ's may be a great fit since EJ18, EJ22, EJ25's can all be plug and play and the ECU's are interchangeable. so one platform could control every EJ engine during that time period.  00-04 would be simple too, after that gets into variable valve but i think you can ignore them and the engine just runs like one without VVT.

 

newer models opens the market up more to the rust belt if that matters. around here 99 and earlier stuff is becoming obsolete due to rust and the people driving/wanting those era rust buckets aren't looking to spend anything or care about maintenance.  i like that era but they're mostly a waste of my time.

[NorthWet]

I didn't really rule out increased fuel economy, just that the initial emphasis would be towards basic, modular functionality.  Once the solid foundation is built, more functional modules could be built. 

 

If an EA person wanted to switch over to coil-packs or coil-on-plug, a relatively simple module can do that. 

 

Once you go to either CP or COP, you can monitor the spark gap for each cylinder fairly easily.  This provides spark-duration info, misfire detection, compression/power stroke detection (no need for a cam-position sensor), sparkplug erosion monitoring, and similar.

 

Once you monitor the spark gap, with a little more hardware (and a heap of processing cycles) you could use ion-sensing to actively monitor the combustion process in real-time. A/F can be gauged, peak-pressure-point can be computed, and knock can be sensed even if  it is light and the engine is running at high RPMs.  Modularity would permit getting the extra processing power by stepping up to more powerful processor modules, like a quad-core 1GHz ARM module.

 

Adaptive/heuristic techniques can be used to customize the ignition/fuel maps.

 

Lots of good stuff could be done... IF a solid but flexible foundation is built.

 

BTW, I have a bit of a background in digital electronics, and spent over 25 years in Data Processing, including some 15 years as an assembler-language programmer.  Microcontrollers just sound like wonderful fun to me.

[presslab]

Once you're deep enough into the hardware design I don't see any reason for using an Arduino form factor; none have an FPU either so that makes fancy algorithms quite difficult with fixed-point math.  There are lots of options out there for micros; the Cortex M4F comes to mind. http://www.nxp.com/products/microcontrollers/cortex_m4/series/LPC4300.html

 

I say the Megasquirt hardware is so clunky, but there is the MS3 Pro.  It's not open-source and $1200 though...  And still to add things like WBo2 you need to have external hardware. Meh.

 

Saab has used ion sensing technology for like 20 years.  It's still in use today but certainly not the norm, I wonder why not many people use it?  Seems like interesting technology.

[NorthWet]

An idea of what I was considering for the processing heart:

Basic - http://www.amazon.com/SainSmart-ATmega328P-CABLE-Included-Arduino/dp/B006GX8IAY/ref=sr_1_3?ie=UTF8&qid=1370127148&sr=8-3&keywords=Arduino+uno

 

Higher performance - http://www.amazon.com/151185025-Arduino-Due/dp/B00A6C3JN2/ref=sr_1_1?ie=UTF8&qid=1370127047&sr=8-1&keywords=Arduino+due

 

These are "jelly bean" parts, developed by a community of like-minded people whose interest was and is to provide a free ("open") hardware platform.  The bootloader and the development environment are free (no-cost).  All of the important signals and inputs are brought out to headers.  Connect your product to those header pins, write the code to control those pins, and your product is ready to test.

[NorthWet]

The reason to use an established form factor is so that you don't have to go create it.  It is there, and if your processor has a problem then you can get a replacement from Amazon for very little cash.  The processor is not the star, the functional modules are.

 

Realistically, most things do not need floating-point math.  Most things that are likely to would benefit more from a DSP... which would be in the module for that function.

 

One thing the "C-language revolution" did was allow people with no aptitude for programming think that they were good at it.  Anybody with $50 bucks (or none when Linux got rolling) could easily write crap code.  They never learn discipline or elegance... or how hardware REALLY works.  In 15 years of Mainframe Assembler coding, I never once needed to use floating-point math.  Lots of people do bizarre things in code because they don't understand any better and "C" lets them.

 

The ion-sensing technology probably doesn't make economic sense in most markets.  Its not much of a selling point, requires specialized coil hardware, and allows the deletion of stuff that pollution laws probably require.  Several manufacturers use it, but none seem to advertise it in the US.

[NorthWet]

One could go around all day, "Why not this processor, or that processor?", any of which would have pros and cons.  Projects have gotten stalled due to stuff like this.  The NXT processor might be nice... but it is one among dozens, and it is still just a bare chip.  The time, energy and cost of making a board-level product is not trivial.  Another point is that even a simple low-cost Arduino unit has something like 10 times the capability of the original EA ECUs.

 

Another contender for a processing platform is one I came across yesterday, the WANDBOARD project.  Similar concept to Arduino, newer, so less established, and unclear whether it will become community supported like the Arduino.  A full-on, high-performance management system might make use of this.  If functional modules are designed properly, we should be able to just plug-and-play. 

[presslab]

I'm not trying to turn this into a "point / counterpoint" argument, just pointing out other options.  At first you talked about these intensive algorithms.  I'm not sure if you didn't initially realize that the Due can't do floating point and are overly defensive, or if you don't plan to emphasize those features, or you planned to do them in fixed point all along.  Having a DSP "module" separate from the micro is adding a ton of complexity for nothing.

 

The Wandboard is the other end of the spectrum!  They're really cool, I even own one.  But this is the wrong direction, first the peripherals are all wrong for the IO an ECU needs, second it's total overkill; you need to find something in the middle.

 

If I had to guess I'd say that you're shy about designing the hardware and trying to find some off the shelf board you can make work.  Well you're just gonna have to dig in.  The other parts an ECU needs to interface to all the engine sensors, injectors, solenoids, etc. is going to be an order of magnitude more difficult than designing the support hardware for a micro.

 

Perhaps though it seems you've already made up your mind?  If so I'll let you carry on unencumbered...

[NorthWet]

Oh, no, I am not trying to be strong-willed (stubborn), just that I think that most approaches have been misdirected, requiring proprietary design to do something that is actually pretty generic.  As long as we are talking basic sensors like RPM, MAP, temp, and EGO, everything is pretty trivial.  On the control/actuation side, a US$5 IC can handle the entire ignition and injection duty based on data passed by the processing core... whatever it might be.  And this is for an MPFI (with distrib).  An SPFI only needs an even cheaper chip.  Need to use VRS crank and cam sensors?  A US$4 dual VRS DSP can do that.  Knock sensing is similar.

 

What I want is a modular approach to engine management.  MS seems stuck because of the approach they took, and everything with them is proprietary.  Users suck eggs if they want something more or different.  In my view, they should be able to build up their own system out of building blocks.  The DYI EFI sites all seem to bog down in everyone trying to show how their way, their processor is better than anyone else's; nothing really appears to get accomplished.

 

In the end, people doing mods are probably going to want something cheap, simple, and something that they can tweak.  Openness and modularity seem the best way to go.

 

Presslab, I certainly welcome your thoughts, suggestions, and critiques.  It is differing views that encourage me to look at things from their perspective.

 

Cheers!

 

Edit: oops! Mea culpa.  I referred to an IC as being a DSP, but it is really a digital-controlled analog signal processor.

Edited June 2, 2013 by NorthWet

[NorthWet]

Edit: The following is more for some future viewer than for anyone who has already commented.  end Edit

 

Amplifying a little on the whole floating-point thing:  Floating point is just a representation of scientific notation, and should only be needed when working with either very large of very small numbers.  It also is a human construct, one that the hardware has no need for.  The fact that "high level" languages such as C encourage the common use of floating-point is more an artifact of the "psychopathy" of the language.  (All high level languages are expressions of the thinking processes of their designers, so tend to exhibit psychological traits of the designers.  C is a rather nasty example, as it was written by computer scientists for their own experimentation, and it escaped the lab.) 

 

There are much better ways than floating-point to perform decimal math, and decimal math is unneeded in engine management. 

 

Regarding the Wandboard being overkill, for most things this is totally true.  From the literature I have seen so far, It is not clear to me what GPIO is accessible.  Lots of the other I/O could be used for things such as a "glass cockpit", and data logging.  The processing power would be about right for experimenting with ion-sense applications.

Edited June 2, 2013 by NorthWet

[NorthWet]

Presslab,  I respect your input, and would prefer if you continue to keep expressing your thoughts. I apologize if I sounded defensive:  I am not.  I am pretty thick-skinned, and used to lively discussions about pros and cons of things.  I know that my view of things is twisted about 90-degrees from normal, so it is always good to get perspective from others.  I truly have never had a need to use any floating-point, and I have worked on program debuggers, optimized search-engines, and done Systems Programming on large mainframe computers.  Outside of scientific pursuits, everything is normally done with out floating-point math.

 

Cheers!