Close
0%
0%

Speeduino

The Arduino ECU / EMS Project.
Open, cheap, hacker friendly engine management

Similar projects worth following
This project aims to create a flexible, fully featured Engine Management Systems (EMS aka ECU) based on the low cost and open source Arduino platform.

Speeduino comprises both the hardware and software components that would be expected from a commercial engine management system, but in an open and low cost package.

Both the hardware and software continue to be under heavy development, but are capable of running both fuel and ignition for engines up to 8 cylinders.

For the latest feature status, see: http://speeduino.com/wiki/index.php/Overview
To join in on things, checkout the forum at: http://speeduino.com/forum

Speeduino v0.3.5_schematic.png

Schematic for v0.3.5 board (CC by 3.0 AU)

Portable Network Graphics (PNG) - 1.52 MB - 10/15/2017 at 11:04

Preview
Download

schematic v0.4.3_schem.png

Schematic for v0.4.3 board (CC by 3.0 AU)

Portable Network Graphics (PNG) - 1.58 MB - 10/15/2017 at 11:03

Preview
Download

v0.4.3_bom.xlsx

Bill of materials for the v0.4.3 board

sheet - 41.91 kB - 09/24/2017 at 11:22

Download

v0.3.6_bom.xlsx

Bill of materials for the v0.3.6 board

sheet - 53.19 kB - 09/24/2017 at 11:22

Download

speeduino-0.3.6-final.zip

Gerber 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

Download

View all 6 files

  • 1 × Arduino Mega 2560
  • 1 × Speeduino Shield board

  • Hackaday prize video uploaded

    Josh Stewart10/21/2017 at 23:52 0 comments

    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. 


  • September 2017 Progress report

    Josh Stewart10/09/2017 at 06:22 0 comments

    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:

    • Better starting with the 4G63 (Miata) decoder
    • Fixed a bug where the fuel pump would not finish priming under some conditions
    • The Miata 99-05 (NB) pattern was rewritten to have better sync on startup and be more accurate
    • The VVT table now has an explicit On/Off mode to make it more suitable as a generic RPM/TPS based control
    • Added a rolling limiter option for hard cuts. This will be expanded and made more flexible over the coming months
    • As mentioned above, significantly better comms and EEPROM management which should be both faster and more stable
    • The unused analog pins can now be selected as general outputs for some functions (Eg fuel pump)

    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.

  • July 2017 Progress report

    Josh Stewart08/05/2017 at 13:37 0 comments

    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:Image
    The major changes on the firmware front this month were:

    • Support secondary pressure sensor for real time baro readings. This has been asked by various people since (I think) the beginning of the project and is now supported. None of the boards currently have this built-in, but any of the spare analog inputs (Such as the ones on the proto areas) can be used for this. Currently it's limited to being an identical sensor to the primary sensor (ie they have to have the same calibration), but I'll probably change that this month
    • There's now a cranking enrichment curve in place of the single value. This allows for temperature dependant changes to cranking pulse widths
    • Improved MAP sensor reads (Faster and more accurate) that also allow for negative calibration values. You may notice your MAP sensors readings are a touch higher (2-3kPa at most) with the new firmware, this is normal.
    • Some experimental changes to the boost control PID algorithm
    • Allow the per tooth timing mode on Dual Wheel triggers
    • Fix a bug that prevented dwell limiting from working on Basic Distributor setups
    • Fix regression where the tpsDOT value would not reset to 0 (Introduced in June firmware)

    As usual, the easiest place to grab the firmware is from the wiki: https://speeduino.com/wiki/images/6/69/Speeduino_Jul17.zip

  • PROGRESS REPORT - MAY 2017

    Josh Stewart06/13/2017 at 23:19 0 comments

    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:

    • There's now a flex based boost adder that, combined with boost control, allows for additional boost to be added as the ethanol content rises.
    • The ignition table now allows advance values below 0, ie after TDC.
    • The 4g63 decoder has been expanded to work with the 6 cylinder variation of this pattern used in vehicles such as the 3000GT (Eg 6g72 and similar engines)
    • All O2 target values and readouts can now be set in lambda or AFR (Previously only AFR was used)
    • Improved the cranking accuracy of the missing tooth decoder (Better tooth to tooth prediction)
    • Fixed a bug where the WUE and Cranking indicators would remain on if the engine was stopped during cranking
    • Fixed a bug that could force injector timing to be simultaneous on 6 and 8 cylinder setups, even when semi-sequential was configured
    • Added a new updater mechanism that allows for slightly smoother firmware updating. This is all behind the scenes stuff but will reduce the number of warnings that may appear in TS when performing a firmware update that alters some of the data structures
    The firmware bundle can be downloaded from the wiki at: https://speeduino.com/wiki/images/f/fa/Speeduino_May17.zip
    As usual, make sure to reload the latest ini into your TunerStudio project after upgrading the firmware

  • Progress report - March 2017

    Josh Stewart04/04/2017 at 23:43 0 comments

    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:

    • Addition of closed loop stepper idle control. This comes with a fairly major rewrite of the whole stepper control system, affecting open loop as well. Hopefully this should be a big improvement for those who had been asking about stepper idles
    • Add a bunch of extra info into logs (Eg boost duty, boost limiter indicator, idle load (Steps or duty cycle) etc)
    • Add an option for a number of decoders (Eg dual wheel) to only sync once. Currently these decoders will resync every time they get a cam pulse, but this can be problematic on noisy cam signals.
    • Initial Subaru 6/7 decoder. This has not yet been tested on a vehicle, so should be considered somewhat experimental
    • Thanks to user dazq, there is now an outputs test dialog in Tuner Studio. This allows you to test board functionality and outputs (Ignition and injectors) without having a stim attached. It can be enabled through the project properties dialog.
    • Some compatibility work for Teensy and stm32 (Code will now fully compile on stm32, though scheduler/timers are non-functional)
    • Calibration for the VW/Audi/Porsche 250kPa MAP sensor added
    • Fixed a bug on the On/Off idle control that could cause it to startup in the wrong state
    • Improvements to syncing on the Audi 135 decoder
    Keep an eye out over the next few weeks for some more details around the hardware I've been working on over the last few months!



    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

  • November Progress report

    Josh Stewart12/05/2016 at 12:00 0 comments

    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.

    Giveaway!

    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

    Download

    The firm is available for download in the usual locations:

    Wiki: http://speeduino.com/wiki/images/3/38/Speeduino_Nov16.zip

    Github release: https://github.com/noisymime/speeduino/releases/tag/201611

    Release notes

    The full list of changes included in this months firmware is below:

    • Move to using the ADC interrupt method of performing analog reads. Thanks to VitorBoss for his work around this!
    • Flex fuel control added
    • Allow selection of the trigger edge on secondary trigger as well as primary
    • Fix ignition miss that could occur when overdwell triggered incorrectly
    • Multiple fixes for timing issues that occurred when sequential was selected
    • Functional timers for teensy boards
    • Enable the injector 3 and 4 angle dialogs when sequential is selected
    • Add missing output mode setting on the stepper motor outputs
    • Improve the scaling on the acceleration enrichment dialog.[/list]

  • October Progress report

    Josh Stewart11/09/2016 at 11:18 0 comments

    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:

    • Individual cylinder fuel trim adjustment is supported via 4 6x6 3D tables
    • Fuel and ignition are independent of one another, meaning one can be sequential and the other not
    • Sequential is available for engines up to 4 cylinders
    • Currently sequential is only supported with the missing tooth (+ cam) and dual wheel decoders. Support for others will be added over the coming weeks

    In addition to that piece of good news, there's been the usual assortment of new features, bug fixes and performance improvements:
    • Fix for issue of sensor calibrations (IAT and CLT) not saving correctly. This was present on versions of Tuner Studio newer than 3.0.7
    • New baro read method on startup will detect if the engine is already running and attempt to use the last known good baro reading
    • Calibration profile for MPX4400 was added
    • Improvements to some of the fan control logic. This fixes a potential issue of a fan not switching off under certain conditions.
    • Changes to the fixed crank timing code to improve accuracy. This may make for more reliable starts on low res decoders such as the Basic Distributor and the 4G63.
    • Code will now compile cleanly and run to the point of being able to connect to TunerStudio using a Teensy 3.2 or 3.5/3.6. Note that there is NO scheduling available for these platforms yet, so it is non-functional, but it is a huge step closer to getting these up and running as an alternative.
    • A number of code/comment cleanups from VitorBoss (Thanks!)

    I think that just about covers everything. This is a BIG update this month and there are a lot of changes both in the code and in the layout of things in TunerStudio. I strongly recommend going over your tune after upgrading to ensure that everything still looks ok.



    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 3.0.10.8 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.

  • September Progress report

    Josh Stewart10/03/2016 at 04:12 0 comments

    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:
    Image



    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:

    • A critical fix to the Multiply MAP option to correctly calculate PW for this. Note: If you've had this enabled, you will likely need to make changes to your VE table with this fix. . If you are not using Multiply MAP (Default is to have this off) then there is no impact
    • Changes required to support TunerStudio 3.0.7 and newer. This was caused by a change in TS to drop support for a certain label in the ini
    • Oddfire support for engines up to 4 cylinders has been added
    • More flexible pull up / switch configuration for launch control (Thanks go to Connor McLaughlin for this)
    • A 'Non-360' degree decoder. This is a version of the dual wheel decoder that allows for primary tooth counts that don't divide evenly into 360
    • A live histogram of O2 and tpsDOT has been added to the acceleration enrichment dialog. This is a huge help in tuning this enrichment as you can directly see the impact that throttle movements are having on the O2 and adjust the curve accordingly.

    REMEMBER TO ALWAYS LOAD IN THE NEW INI FILE INTO YOUR PROJECT ONCE YOU'VE UPLOADED THE FIRMWARE ONTO YOUR ARDUINO



    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

  • July 2016 Progress report

    Josh Stewart08/04/2016 at 02:00 0 comments

    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:

    • An error management system has been introduced for handling various types of sensor and operating failures. This is still very much a work in progress, but essentially it will allow for easier diagnosis of errors and the use of default sensor values for a 'limp home' mode. The system flags that there has been an error and will output an error number that can be looked up against the (WIP) documentation: http://speeduino.com/wiki/index.php/Errors
      • Up to 4 error conditions can be managed at a single time
      • For this release, the replacement default values are disabled, so you only get the error being logged for now, but I expect this to be turned on by default (With a configuration dialog) for next month
    • Speeduino now uses it's own signature in TunerStudio, meaning that conflicts between the ini file and the code that is loaded will be picked up when you connect. This should hopefully reduce the number of people having disconnection issues due to mismatching config/code. See below for important details about this change
    • Fixed a condition that could cause the tacho output to 'miss' every now and then, which resulted in a poor signal.
    • Significant performance improvement on the 2D table lookups
    • Change code directory structure to work with the recently released Arduino IDE 1.6.10
    • Fixes for injector timing issues that were discovered in the June release (These fixes were also included in the rereleased v3 of the June files).

    IMPORTANT: Because of the change with the signature, you MUST have Tuner Studio 3.0.2 or newer to use this firmware. It will fail to connect on any version earlier than this. I HIGHLY recommend the update even if you're not using this firmware though as Tuner Studio 3 is a great leap forward over the 2.6.x versions. It can be downloaded from: http://www.efianalytics.com/TunerStudio/download/



    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

  • June 2016 Progress report

    Josh Stewart07/01/2016 at 08:29 0 comments

    <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:

    • Flex fuel sensor reading added
    • lambda output added
    • New decoder added based on info from classified. I have no idea what this should be called, but for now its simply designated 'MazdaAU' as this is apparently a pattern unique to Australian vehicles.
    • Include AFR option has been added to allow incorporating AFR target directly in the pulsewidth calculation (Similar to 'Include MAP')
    • Decent performance improvements to the corrections code
    • Tweaks to the serial comms code to allow newer versions of the Tuner Studio beta (.120 and up) to be used
    • Bug fix for potential serial disconnect and display of incorrect values
    • Fix bug identified by AndreaRC that could cause injector pulse dropout under certain conditions, particularly when very low injector timing angles were set

    On the whole this is a solid update, if even its not feature rich. I highly recommend it for all users for general stability etc.



    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.

View all 33 project logs

View all 4 instructions

Enjoy this project?

Share

Discussions

johnamptech wrote 08/14/2022 at 18:53 point

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. 

  Are you sure? yes | no

amadeo.om wrote 06/10/2019 at 19:28 point

where can I find v0.3.7 schematics?

  Are you sure? yes | no

amadeo.om wrote 06/10/2019 at 19:22 point

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?

  Are you sure? yes | no

ramsey wrote 06/07/2019 at 16:01 point

Where can i purchase the electronic components and board connectors

  Are you sure? yes | no

dnczar wrote 09/17/2017 at 04:35 point

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.

Thank you.

Frustrated (Don)

  Are you sure? yes | no

Stephen K wrote 04/03/2017 at 14:13 point

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.

  Are you sure? yes | no

zparker2012 wrote 04/06/2017 at 18:50 point

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.

  Are you sure? yes | no

Aivaras wrote 11/22/2016 at 12:03 point

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 :)

  Are you sure? yes | no

cBake wrote 06/07/2016 at 18:28 point

Awesome!

  Are you sure? yes | no

Stephen K wrote 06/07/2016 at 17:16 point

Any plans for MAF support?

  Are you sure? yes | no

Josh Stewart wrote 06/08/2016 at 06:36 point

None at this stage I'm afraid. MAP will likely be the preferred method for a little while. 

  Are you sure? yes | no

Stephen K wrote 06/06/2016 at 11:18 point

Really hoping this takes off so I can move away from the more closed source Megasquirt.

  Are you sure? yes | no

larry wrote 06/02/2016 at 20:28 point

Anyone running this on a high powered turbo honda yet?

  Are you sure? yes | no

Josh Stewart wrote 06/03/2016 at 23:50 point

Not high powered (yet), but one member has recently finished his Civic turbo install: http://speeduino.com/forum/viewtopic.php?f=19&t=206

  Are you sure? yes | no

alef.riyas wrote 04/12/2015 at 22:31 point

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.

  Are you sure? yes | no

zakqwy wrote 02/25/2015 at 16:52 point

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!

  Are you sure? yes | no

Josh Stewart wrote 02/25/2015 at 18:56 point

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. 

  Are you sure? yes | no

zakqwy wrote 02/25/2015 at 18:58 point

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.

  Are you sure? yes | no

Josh Stewart wrote 02/27/2015 at 04:42 point

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. 

  Are you sure? yes | no

zakqwy wrote 02/27/2015 at 15:13 point

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..

  Are you sure? yes | no

Josh Stewart wrote 03/06/2015 at 23:06 point

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. 

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates