Frankenstein, The Open Source Engine Control Unit

The Engine Control Unit is a vital part of every car made in the last 40 years or so, but unlike just about every other electronic device, open source solutions just don’t exist. [Andrey] is trying to change that with rusEfi, a project that hopes to bring together hardware, software, and engines in one easy to use package. He’s even designed Frankenstein, a full ECU ‘shield’ for the STM32F4 Discovery dev board.

This isn’t the first time we’ve seen [Andrey]’s adventures in building an ECU. An earlier board was also powered by the STM32F4 Discovery, and he actually drove his 96 Ford Aspire around using this homebrew ECU. It was only firing on two cylinders, but that was only a loose solder connection.

Of course building an ECU from scratch is worthless without the proper firmware that balances and engine’s fuel economy and performance. This sort of testing must be done empirically and [Andrey] has a Kickstarter going for the development of this firmware and some dyno time. No rewards, but it’s worth chipping in a buck or two. I did.

Videos below.

 

47 thoughts on “Frankenstein, The Open Source Engine Control Unit

          1. At about a thousand dollars per unit upwards by the look of it on ebay. Not something that would interest me .I would rather buy anything from a wrecker and just play with it first. Silly to compare free with something costing $1000

          2. @rue_mohr: FreeEMS is still very much alive and well, I assure you. FreeEMS is also absolutely nothing to do with MegaSquirt, whatsoever. FreeEMS has certainly not been renamed to LibreEMS, which is effectively just two guys and a small branch with a couple of soon-to-be-replaced features.

          3. Most of the good developers from the DIYEFI have left and created or joined libreEMS. Now there is a developer war going on between the two camps and it’s not a pleasant environment to participate in as there is lots of emotion and a lack of progress. Long term this problem probably means the LibreEMS team will migrate to the rusEFI platform or some kind of ARM platform. The use of a portable OS in rusEFI will likely attract the interests of the LibreEMS developers as well as other developers. Long term rusEFI is a lower cost option and it has a better development environment, both in terms of tools and personalities.

          4. Thanks for that link. I was wondering if there was anything left of the open-source project that was MegaSquirt. I personally want to hack something together to put on a small scooter for fun, not install an item that’ll more than double the cost of the vehicle.

        1. @Galane, MegaSquirt was never “all open” and was always proprietary. Being able to download the files does not mean that you’re free to use them however you wish. The wayback machine has plenty of good quotes around this.

      1. As I recall, the PCB was proprietary, code was free. Hence the code variants with spark control, traction control, soft-cut limiters etc. Tuning is no more complex than simple calculations to get it idling, and then using a wideband oxygen sensor while driving around.

        Been running it for 12 years now with no issues, and it cost <£100…

        1. The code has never been “free” as such. It has been downloadable and readable, and under varying conditions, modifiable, however it’s never been “free” as in freedom.

  1. Slightly off topic, but here are two youtube videos that show the development of a Cosworth V6/F1 engine back in the mid-80s, however what makes these intersting, is that there is a new engine control unit being used, and well spoiler alert gives them headaches.

    There is also some 80s mainframe “porn” (green/black terminals!) in it.

    However this is one of the best documentaries I saw ever:

    http://www.youtube.com/watch?v=xbB1qwhKaaE
    http://www.youtube.com/watch?v=gqfVAGOaGEc

  2. I would have to say this is awesome. For it to be really useful it will need to have some kind of way to plug in to lots of different makes and models of cars
    this does have VERY COOL writen oll over it

  3. Back in my BSME days we did closed loop optimization of fuel/air mixtures (and timing maybe? It’s been a couple decades). We measured exhaust gasses. The dyno time in the kickstarter is needed for real-time torque measurement? A cool hack for this hack would be a way to measure torque on an engine is use. Wireless strain gauge on the drive shaft?

    1. Realistically, NO. Dino time is not needed unless they are making custom firmwares for specific engines. Torque is pretty easy to measure using the speedometer sensor if you know the vehicle weight. Dino time is really for fine-tuning…getting 30MPG from an engine that was getting 28MPG and such…but tune it for a 200K engine with some wear and the same vehicle with the same engine with 100K might actually suffer. That said, the actual kickstarter doesn’t even mention dino time. Their first goal seems to be to make some kind of firmware generator menu thing, and their second goal seems to be to make it “much more smarter” by (presumably) making it learn from the O2 sensors like every car since the 1980’s. After that they want to improve their Wiki, improve CAN support, and then to add support for more sensor types. If they do it all, and do it well, then they might have a viable product.

  4. It might be cool if it gets off the ground; I’d buy one if there was a simple set of menus to select what kind of sensors, ignition timing, fuel curves, etc. It has been done before…but not cheaply, and those who are still making/selling units designed in the last century haven’t lowered prices since launch.

  5. There’s also the matter of vibration and enviroment. Generally ECU are mounted under the hood near the engine so there can be lots of vibration (such as when you lose a spark plug). Also it may have to deal with heat as high as 500 F and sub-zero temp with swings taking a few minutes, most cheap electronics would blow apart easily from such wide repeated swings. Oh yeah they get wet from water, snow melt, salt (off road in cold climates), leaked and spilled fluid, etc.

    If the ECU was mounted somewhere safer like in passenger cabin, then one would have to deal with long wires that can throw sensitive timing off. Different cars would have different needs and different behavior on top of needing to know the wiring diagram as no one used universal design, and firmware as well.

    It is a lot of work to make one work. Prop to anyone who successfully build one and the car works.

    1. Apparently you haven’t worked on vehicles since the early 1980’s. Only a few early 80’s, very primitive ECUs were under the hood. Chrysler mounted their first one right on the air cleaner. Ford put the controller for the electronic controlled variable venturi carb under the hood, so was the controller for Ford’s short lived (1983-1984) throttle body EFI. After that, Ford went all multiport, unlike GM and Chrysler who used throttle body EFI on most vehicles and multiport mostly for their higher priced models for a long time.

      1. Actually I see a move from inside the cabin under the hood. 90s mazda – inside the cabin, 2000s mazda – at least mx5 – under the hood

        mini cooper – ECU is under the hood, 2011 nissan truck – under the hood… But that’s just cherry picking, I do not know that many cars.

      2. VW passat B4 has the ECU’s under the hood in the same area as the mechanical arms for the wiper system and the pollen filter.
        And the ECU itself is enclosed in a box to protect it from the elements and some basic vibration dampening.

        Biggest problem is temperature variations.

    2. If you’re going to the effort of wiring up a new ecu, you could just move it to the passenger cabin Assuming the sensor signals hold up for the extra couple of feet.

  6. Andrey seems like a nice guy, but it seems like he hasn’t gotten any guidance from the Kickstarter people on setting up this campaign.

    Andrey, if this campaign doesn’t make it, please don’t get discouraged. The information on your project home page isn’t clear about where you are in the project, what you want to do and what your long term goal for the project is.
    There is a lot of room for perks here. Simple “Thank yous”, T-shirts, unpopulated/populated boards. Acknowledgement in the source code comments for donors, printed manuals, input on the design. (one perk for one design decision, another for a different design decision.)
    I love what you’re trying to do.
    And Andrey, you have some ‘splainin’ to do. Give more information in your talk and have everything written down on the kickstarter home page. Why is the next step necessary? Don’t rely on everyone watching the video to learn about your project. And show your passion and some energy. I know you care about this or you wouldn’t have gotten where you are. But If you don’t show your passion in the campaign, don’t expect others to believe in your project.

  7. > It was only firing on two cylinders, but that was only a loose solder connection.

    Uhm yeah. That’s probably why they build good parts of the production ECUs on ceramic substrates with direct die bonding.

    1. I repaired 6 ecus last week from 06-09 cars and only one had ceramic/alloy bonded wires. And one should note 9/10 times the failure is the aluminium bonding wires to the ceramic. I cannot remember the last time I saw a solder joint fail in a modern designed and built ecu.

  8. Firstly on the front page I see ” literally used a board” . have no idea what they mean and I suspect they don’t understand the nuances of the language so first get a good English front page explaining what you are doing.
    Did you build the Frankensein board ? I think so but the other ECU plug is this someone elses?

    Next I am interested atm because I have a dud controller driving a diesel generator which I would like to find a contoller for that I could set up and test for myself , learning heaps in the process. I would join their kickstarter if I had a bit better understanding of what they are doing and what benefit I might get by doing so. Knowledge not money.

    Lastly I can’t leave a comment on their page because there is no anonymous provided and I do not use social site logins at all

  9. FREEems to be found at DIYEFI.org. Completely open source, and making serious headway, running many engines and I think not only very much worth a mention, but very much worth taking a look. Go along and have a mooch people.

  10. FredEMS (FreeEMS) is great for non collaborative effort(s). Collaboration has been a problem with MS and FredEMS as is evident by the inability to keep developers or attract new developers. MS prevents collaboration because it doesn’t allow you to make changes to the hardware, and if you do, you’ll get into legal issues. Those development environments hold back progress. What we need is a development environment where the group is more interested in progress than BS. This is where rusEFI has filled a void.

    Frankenstein shows how it works when you get multiple developers working together in unison instead of several individual efforts that hopefully get smashed together with out issues. Frankenstein is a combination of modules designed by multiple developers then merged together. If a problem is identified, the module can be fixed and the effort grows. If you want a feature that doesn’t exist in a module, you can copy the project and change a module to meet your exact desires. The software operates under an OS that can port to other hardware platforms with minimal effort. As well it’s based off an ARM which allows pure software simulation. You can develop software with out having any hardware other than your PC. You can debug new code by simulating the register values and looking at the output registers seeing if your code changes have addressed a particular bug or not. Other platforms require you to connect to an engine and see if it breaks.

    RusEFI is a friendly but demanding environment with many knowledgeable people who often help those that don’t have the skills yet. It’s a great place for someone to learn, as well there are several experienced developers making progress daily. Even though it’s a young project, it’s making some great head way, and just about anyone can find a place to contribute or participate. As a developer who has been booted from MS and banned from FredEMS, I encourage people to check out rusEFI. The group there is far less interested in BS than other efforts out there.

    1. Hey Jared, I just wanted to point out that you’ve not been banned from the DIYEFI.org forum (where FreeEMS discussions are hosted, along with SECU-3, and various other things), and are still welcome to post there any time. Your posts will be moderated because last time you posted you were aggressive and disruptive. If/when you prove you can act in a civil way, I’ll lift that restriction again. Choosing to not post because you know this is the case does not constitute being banned. All the best for your endeavours!

      1. I understand you consider the ban at DIYEFI to have been lifted, in that I can technically post and eventually some manipulated version of my post will make it to the thread. However I disagree with your filtering and manipulation of my content so as far as many are concerned, it’s a banning. As well several members there disagree with your claim that I was aggressive or disruptive. I understand you have lost other developers as we feel you are aggressive and BS prone. I seem to recall libreEMS was created by disgruntle members who felt DIYEFI was not a proper development environment, and they were annoyed with you chasing away developers.

        I feel that the S12X chip is not a good choice in platform, as it has poor compiler support, when compared to an ARM system. There are so many more tools and developers for an ARM based system, that I haven’t joined libreEMS.

  11. Andrey, good work so far with rusEfi ! I have been following your threads on http://forum.diyefi.org as well as at http://rusefi.com/forum/index.php
    and you have helped me (unknowingly) with your work on serial communications between your firmware and TunerStudio. I am working on a similar project to control my GM 4L60E electronically shifted automatic transmission in my 1995 Chevrolet S10 4×4 and it is based on the Freescale 9S12C64 microcontroller which I designed hardware for and I am using a branch of FreeMS2 firmware (based on FreeEMS) that Fred and I have been working on.

    As one of the hardware developers for FreeEMS, I can assure you that the project is indeed active with FOSS hardware being developed by not only myself (see the hardware design I’m working on at https://github.com/DeuceEFI/Jaguar/tree/dev) but many others as well. I have been working on the FreeEMS project for the last 2 years and I have two vehicles (a 1932 Ford coupe and a 1996 Chevrolet S10) running on my codename “Jaguar” board. There are “Jaguar” boards scattered around the world, I have even got to ride in a “Jaguar”/FreeEMS powered Volvo wagon in Canada!

    As for the FreeEMS community environment, we recently had a couple of in person meetups where 5 or more FreeEMS developers were working together on developing new hardware solutions, new tuning software features and firmware code while working on an open source automobile project (http://wikispeed.org/). Some of us were together for a weekend, some for almost 2 weeks, and we had fun while working together to solve many different problems for not only the FreeEMS project but also for the Wikispeed project as well. Future meetups have been discussed in the USA as some of the developers are scattered throughout the USA, not to mention the great number of developers scattered around the world.

    I, along with other FreeEMS developers, help those that ask for it either on the DIYEFI forum or on the FreeEMS IRC channels on freenode.net

    1. My TunerStudio implementation would not happen without Mark@open5xxx’s effort to figure it out.

      Hopefully one day we would all agree that’s it time for cross-platform modular code and better collaboration across the whole DIY EMS spectrum, because it really sucks that rusEfi has to reinvent the bicycle simply because we want more CPU power & RAM. Hopefully this cross-platform code base would be based on rusEfi :)

  12. “I feel that the S12X chip is not a good choice in platform…..” There are a lot of guys who would agree with that, even me to a certain extent. I think rusEFI is in a good position to get some rapid development done. It seems like they have a plan which allows for developers to fill in holes. In the early days of Fr3dEMS there were a handful of experienced S12 guys, but it seems they were run off, rather than managed. Anyway when it comes to those kinds of comments, I always suggest that people draw their own conclusions via the evidence at hand.

    I look forward to seeing what the future brings, on all fronts :)

  13. It’s looking like rusEFI is the way to go for all of this. The FreeEMS project looks unorganized and reminiscent of a project that has died, but has posted everywhere “We’re not really dead we promise!”. The fact that a LibreEMS project even exists without appreciable completion on FreeEMS isn’t just a red flag, it’s a gigantic red lighthouse of warning that there seems to be drama going on in those circles. No thanks.

    LibreEMS looks to be far better organized – at least someone there looks like they attempted to take the time to make their source available cleanly, a suitable webpage, etc.

    rusEFI webpage actually shows 3 different variations of hardware, with pictures and clear information, and has links to people’s ebay shops where they’re putting together kits, as well as a separate site for sharing tuning information, wiki, much better documentation, etc.

    Never underestimate the power of clearly available information, a good presentation, and competent management. I’ll definitely be keeping tabs on rusEFI from now on. Interested in how it evolves over time.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.