The Arduino ECU / EMS Project.
Open, cheap, hacker friendly engine management
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
Speeduino v0.3.5_schematic.pngSchematic for v0.3.5 board (CC by 3.0 AU)
Portable Network Graphics (PNG) - 1.52 MB - 10/15/2017 at 11:04
schematic v0.4.3_schem.pngSchematic for v0.4.3 board (CC by 3.0 AU)
Portable Network Graphics (PNG) - 1.58 MB - 10/15/2017 at 11:03
v0.4.3_bom.xlsxBill of materials for the v0.4.3 board
sheet - 41.91 kB - 09/24/2017 at 11:22
v0.3.6_bom.xlsxBill of materials for the v0.3.6 board
sheet - 53.19 kB - 09/24/2017 at 11:22
speeduino-0.3.6-final.zipGerber files for the v0.3.6 Speeduino board. The v0.3 line of boards are a larger board, slightly easier to assemble and use screw terminals for retro fitting
Zip Archive - 641.92 kB - 09/24/2017 at 11:18
Just a quick update that I've (at this 11th hour) finally finished off the project video for the 2017 Prize, of which Speeduino is a finalist!
It briefly runs through the history and motivation for the project as well as where it's going in the future.
A little late this month due to a few bugs that have taken quite a lot of time to resolve, but the September firmware is now ready to go. The bugs were in relation to the comms system, which underwent a major rewrite this month to not only improve the stability of connections, but also make the tune transfers significantly faster. I know a few people experienced some comms issues with the August release and that prompted me to not only fix those issues, but make some major improvements at the same time.
I've also made a lot of small improvements that are specific to the MX5 / Miata plug and play unit (and MX5s in general). I know this doesn't necessarily benefit everyone, but I do want to make sure these are working really nicely before the units go into wider production beyond just the Beta units.
The full list of user facing changes is below:
Note: The changes to the comms code required the internal memory layout to be adjusted. The system should update itself when it starts for the first time with the new firmware, but PLEASE CONNECT TO TUNERSTUDIO AFTER UPGRADING TO ENSURE THAT YOUR TUNE REMAINS CORRECT!
The firmware bundle can be grabbed from: https://speeduino.com/wiki/images/1/19/Speeduino-Sep17.zip
As always, if there are any issues found with this firmware, please leave a reply in this thread.
So time for some more new firmware goodness! This month sees a return to the more standard feature / bug release type changes rather than the larger structural ones I've been working on the last 2 months. I've gone back over the feature request list and tried to get through as many of them as I could, including a few that have been requested fairly regularly for a while now.
On the hardware front, I am really excited to say that the beta run of the NA6 MX5 / Miata PNP units is done and (mostly) shipped. These have been in the works for a long time and, whilst some development is still required on the firmware side of things for them to be perfect, they are ready for wider testing and use:
The major changes on the firmware front this month were:
As usual, the easiest place to grab the firmware is from the wiki: https://speeduino.com/wiki/images/6/69/Speeduino_Jul17.zip
Another month, another firmware drop! As is usually the case, there has been a bit of behind the scenes work happening in the firmware that is designed to both increase general stability as well as preparing for some more core changes that are coming in the next month or two.
There's also been a heap more work on the manual, in particular the layout and formatting of the offline manual. The whole thing is considerably easier to read and things like images are sized correctly etc. As always, if anyone is interested in helping out with the documentation, just let me know
As a bit of a side effort, I've begun work to bring the whole Speeduino codebase into compliance with the MISRA C:2012 standard. The MISRA standard is a set of coding guidelines designed by the automotive industry to maximise reliability and safety in software used in vehicle systems.
About half the code is now compliant and I expect to complete this effort within the next few weeks.
So as far as the new firmware goodness goes, the main changes are below:
Where does the time go? April already and March has been another big one for Speeduino. Forum users and installs are increasing all the time and it's terrific to see the project starting to be mentioned more often on forums etc as a truly viable system!
As a heads up, I plan a slightly quieter month throughout April on the firmware front. I will still be doing general maintenance, bug fixes etc, but probably not so much work on new features. The reason for this is that I want to spend a good chunk of time working through the documentation pages (https://speeduino.com/wiki/index.php) to try and:
1) Have at least something on every topic
2) Cover all of the most used pages with good detail, images etc
DIY Engine Management Systems live and die by their documentation and to date whilst Speeduino's documentation has been minimally OK, I would like to bring this up to a much more professional level. I've already begun restructuring a few things, so there are many placeholders there currently as indicators of what I will be adding.
If there is anything you find that you believe is important, but that doesn't already have even a blank page, then please drop a note in the forum and I will look at adding it.
Additionally, I am ALWAYS on the lookout for anyone who wants to help with documentation! If you have some time and knowledge to share, please do contact me and I can get you the required access!
As for the full feature list from March, here are the primary changes:
The firmware bundle can be downloaded from: http://speeduino.com/wiki/images/2/24/Speeduino_Mar17.zip
As usual, make sure to reload the latest ini into your TunerStudio project after upgrading the firmware
So after the big release of sequential control in October, Novembers release is less focussed on features and more on under the hood changes, although there have been a few new functions added
For the most part though, November is a stability and bug fix release, with heaps of patches included. Many of these are around sequential (and a big thanks goes out to Dan Elliot for testing throughout November!) but there were also improvements made to a number of decoders, overdwell protection etc.
As far as new features go however, the big one is that flex fuel sensing and adjustment is now supported. This allows for reading from a standard frequency based flex fuel sensor and adjusting the mixture accordingly. The great thing about the standard GM/Continental sensor is that is requires no calibration and so tuning of fuel requirements is largely universal. The default settings included in the base tune will work in almost all cases.
This feature does need some documentation to be written up, which I'll do over the next few weeks, but the support is there and working from this month onwards.
Finally, many of you will have seen that there is a poll up to vote on a new logo concept. Just incase getting to have a say in the new logo isn't enough incentive (how could it not be!?!) I've decided to add an extra reason to vote....
Once voting closes on Dec 16th, the final logo will be put together based on the results. At that point I'll be choosing 1 person who voted, at random and they will receive a t-shirt and bumper sticker with the new logo from the first round to get printed! This competition is open to all users who have made at least 1 post on the forum at the time voting closes.
Note that the shirts and stickers will take a few weeks to get printed once things are final, so don't expect your winnings before Christmas or anything.
There have been a couple of additions to the voting options recently and everyone can adjust their vote right up to the 16th, so even if you've already voted, take another look and have your say! https://speeduino.com/forum/viewtopic.php?f=28&t=890
The firm is available for download in the usual locations:
Github release: https://github.com/noisymime/speeduino/releases/tag/201611
The full list of changes included in this months firmware is below:
OK so I'm a bit late with this months update, but there's a good reason for it. I know I've been a little quiet around the forums the last few weeks, and this has mostly been due to putting all of my Speeduino time into the firmware.
So, without beating around the bush. The good news is that the October firmware now supports full sequential fuel and ignition control! This has been a huge piece of work to get in and is one of the reasons things are a little delayed. A couple of points about the implementation:
The firmware is available for download from the usual locations:
Monthly code dump: http://speeduino.com/wiki/images/8/87/Speeduino_Oct16.zip
Github release: https://github.com/noisymime/speeduino/releases/tag/201610
As a side note, there are issues with the 126.96.36.199 and 3.0.11 versions of Tuner Studio that cause corruption to your tune file! Version 3.0.12 fixes these, but PLEASE avoid the bad versions as they can really mess up your tune very quickly.
So September has been largely focussed on hardware for me, but as always there's been some more solid improvements and new features added in the firmware.
On the hardware front, I've finally had a bit more time to play with the new surface mount design, specifically the MX5 PNP board that has been in the works for a little while. Here's a little preview of the current incarnation:
This board is not yet ready to go and there were some showstopper issues found on this testing version, but given the ground up design, this was expected. The board did run an engine, but a few of the onboard features are not functional due to design issues. Still, it's getting there
Around the firmware, it's been fantastic to see a few people putting forward pull requests for their own work. I will need to begin putting in place some processes to make this smoother in the future (Eg a style guide) but I'm thrilled that others are putting up good quality pull requests that I am confident in bringing into the main code.
As usual, here's the list of major changes:
This firmware can be downloaded from: http://speeduino.com/wiki/images/a/a1/Speeduino_Sep16b.zip
Or from the release on github: https://github.com/noisymime/speeduino/releases/tag/201609
Despite me being largely out of action due to other commitments that last 10 days or so, there was a lot of progress made throughout July. Some of these things are parts of larger pieces of work and aren't fully completed yet (Eg 5 cylinder support), so this update may look somewhat lite on for new features, but rest assured there's lots happening.
To keep things short and sweet, here's the list of the major changes since last month:
As always, the firmware is available from the wiki: http://speeduino.com/wiki/images/2/2f/Speeduino_Jul16.zip
Or now also as a release on github: https://github.com/noisymime/speeduino/releases
<Insert usual spiel about me not being able to believe it's the end of June already>
OK, short, sweet and to the point on the update this month. So much good stuff happening, but at least for June the firmware is a little quiet on the new features front. That's not to say it hasn't got a lot in it though!
On the juice side of things, a lot of work has been done on the Flex fuel capability. Whilst it's not fully ready for June, the ability to read, display and log a flex sensor has been added. classified has done a heap of work on the actual fuel/ignition adjustments side of things and I'm hoping this should be merged within July sometime.
A LOT of work has gone into squashing bugs that were identified, some small, some more significant. I'm happy to say that from a reliability point of view, this release is the best to date by a long margin so I recommend upgrading for this alone.
Rather than drag it out, here's a full summary listing of the changes:
As usual, the release is available on the wiki: http://speeduino.com/wiki/images/3/36/Speeduino_Jun16.zip
I have also begun tagging releases on github to allow easier tracking through there.
Further details on this can be found at: Compiling and Installing Speeduino firmware
Create an account to leave a comment. Already have an account? Log In.
where can I find v0.3.7 schematics?
MXP4250A would be replaced by an OEM MAP Sensor? MXP4250AP pinout on datasheet is Vout P1 and VCC on P3 so I guess than is possible to use a wide range of stock MAPs, or am I doing so wrong with that?
Where can i purchase the electronic components and board connectors
I'm impressed with what you are doing here and when you add "low cost" you've got my attention. I have a number of questions but understand I am starting from the most, very basic beginning here. If I ask what amounts to a stupid question please be patient. I freely admit my ignorance right now. I hope it doesn't last long.
1.) I may have missed or overlooked this but are you dealing with the OBD2 protocols or are you developing an ECU more akin to one that is more typical to what is used in racing? I ask because I assume you have a commercial interest with your project and OBD2 with its "Check Engine," light is a mandated common denominator with most engine management issues.
2.) I have not read everything you have put up that's related to your project but I'm curious about how you have dealt with cold starts? Are you maintaining any "history" in a memory as a reference?
3.) My decision to participate here is because of the other side of the ECU's. OEM ECU's are generally a conglomerate of what is typically referred to as "modules," which manage or control systems other than the engine. It's that other side of the ECU's I'm interested in. I usually build with Ford components and use their control packs for engine and transmission management but that is all they control or manage. A couple of effected systems because of Ford's methodology are power steering and ABS. I'm throwing these out as just examples of the many effected systems. Typically with power steering the amount of electric, electronic or hydraulic assist is controlled by monitoring some component related to the real time speed of the vehicle. When using power steering on a vehicle being managed by a control pack PCM (ECU) there is no monitoring of speed and the whatever type of power steering is being used it is always operating at the systems base reference. The amount of power steering assist required for parallel parking and driving on an expressway at 90 mph are very different yet with the control pack and the lack of power steering support the amount of assist is the same. It's not a safe condition. ABS takes a lot less writing to consider. Although ABS usually has a stand alone control module the ABS is often a component of a traction control system which is communicating with and directing ABS operation. Because of this ABS and traction control are usually removed from the vehicle.
My goal is to find a way to get all of these non-engine systems controlled by the original installed PCM (ECU) working without a dependence on the control pack PCM. That is except to monitor data values as needed. My concept is to use the control pack PCM like a static sensor for reading data as needed but without any of the communication protocol nonsense which in my mind is the source of compatibility or non-compatibility issues with the electronics used in todays vehicles.
My original thought was to use the original OEM PCM for all of the non-engine systems and let the control pack PCM control the engine. Both Auto Meter and Dakota Digital have assured and convinced me that this is not possible because of the "as designed" requirement for these modules to communicate. There is no way to remove or disregard the communication requirements of OEM systems so they can stand alone. This is how I understand what I've been told anyway. A different protocol is needed. I don't know enough now to understand if what I'm thinking of would still be a Can Bus protocol system or not.
Finally, systems like Ford's Microsoft Sync used for features like GPS and internet access is beyond my interests and alternatives are available if these features are desired.
My questions right now amount to this; Am I wasting my time chasing my tail with this? Some have told me I am. Can Arduino be used to accomplish my goals? I have Ford dealership level access to PCM data so I don't need to chase at least that much support. I'm under the impression that components don't care about protocols. An electric power steering rack only requires the proper voltages to operate as conditions dictate. There is nothing inherent to the rack itself that dictates protocols or data formats. I'd appreciate anything you can share about required reading and what equipment and supplies I need to pick up if my pursuits are viable.
So, I've got a little bit of an oddball question:
What about setting this up for something like CIS? I've got older Bosch CIS units that use a Lambda feedback look to control fueling, and I've been looking into how to hack it into supporting fuel enrichment for turbocharging. This would negate the need for Electronic Fuel Injector support, as it would just need to manage a pressure regulator based on TPS and the CIS Plate position, plus O2 feedback.
You should be able to use parts of this firmware, but I don't think it will work the way you want it to as-is. If I was you, I would make sure I had a deep understanding of how the cis system works from factory, and use parts of this to start writing your own code. Of course, you would have to talk to Josh if you ever wanted to market it, but for personal use it's kind of the point of open source.
Anyways, I'm sure you could pretty easily impliment some sort of valve or pump control scheme to make everything work, and control it all with an Arduino....
Hopefully that was helpful.
Just registered to say this is amazing!
Earlier this year I decided to Megasquirt a small engine, and to save money I re-designed the MS pcb and cut/built it myself using the [now very old] components and design, and the now obsolete Motorola/NXP mcu. What a pain in the ass it was!
I always wondered why this hasn't been done on modern hardware, then found that it has and has been spawned into closed-source commercial products costing ££££.
I wish I'd have found your project sooner!
I'll be following the project closely. Thank you for all your effort doing this :)
Any plans for MAF support?
None at this stage I'm afraid. MAP will likely be the preferred method for a little while.
Really hoping this takes off so I can move away from the more closed source Megasquirt.
Anyone running this on a high powered turbo honda yet?
Not high powered (yet), but one member has recently finished his Civic turbo install: http://speeduino.com/forum/viewtopic.php?f=19&t=206
hi josh can i ask a question about the 3 output pin namely cam pin, pulse pin mph pin of stim. shown on your feature demo is it directly connected in speeduino or need conditioner. which pin in speeduino it will put i'm confuse. is it in sda and clk. and also how to order speeduino v2 board.
Excited to see more details on the Speeduino shield. If you haven't already, it's worth seeing how the Megasquirt folks dealt with stuff like electrical noise and physical ruggedness--ECUs need to be pretty tough and reliable!
Yeah, this was a big consideration from the start and has been factored into the board designs. All the analog inputs are rail to rail protected etc. Checkout the schematic () , I'm very open to suggestions for improvements as it's an area I've needed to learn a lot about. Combined with a metal enclosure, results have been pretty good so far
The biggest noise problem area has definitely been in the USB serial comms, which are very susceptible to noise. The one thing Megasquirt do here which I'm not (yet) is a CRC check, but so far I haven't found it too necessary if you bring the baud rate down etc.
Makes sense. Could you use some kind of isolation on the USB serial link? Optoisolators? Or maybe some kind of optical fiber connection to avoid the problem entirely?
I'd love to see some hardware/installed pictures--I'm guessing they're somewhere but I missed them.
USB serial is tough as it's relatively high speed and you're very reliant on the cable itself. Short, good quality cables don't tend to have too many problems though, as long as you don't try to push the speed too much.
I added a pic of one of the guys installs. Will gather some more soon.
Can you run the data via CAN bus? You'd need to build in a converter, but the protocol is well-proven in automotive applications..
CAN is definitely on the list for things to start playing with. It does however add a bit of cost to the project, so I'd like some way to make it optional. The goal has always been to have a $100 ECU and I don't think CAN will be possible inside that envelope.
Become a member to follow this project and never miss any updates
By using our website and services, you expressly agree to the placement of our performance, functionality, and advertising cookies. Learn More
I'd like to use the speeduino on my 1500 triumph spitfire,i'd also like to incorporate the MCU into the main pcb,i use Tina7 ,is there a complete schematic,i'm not sure if the gerbers will open in Tina,i will try it or load them in a gerber viewer,i rarely use the jumper pins as they (for me) don't allow for easy tracing of circuit connections in the schematic,yes they tidy things up but i can click a wire and i highlights its path whereas the jumpers don't allow for this.