Sunday 29 March 2020

Microsquirt Engine Management Experience

I have noticed over time that there are a surprising number of forum posts, mainly on small capacity motorcycle forums, that link to this blog in reference to providing information for a conversion from carburettors to fuel injection. I am humbled that people find this blog useful and I am very happy that my ramblings are being appreciated! I have also had some contact from people who have expressed an interest in doing a similar conversion using the Microsquirt ECU as a base. This is the general gist I got from the forum posts that I read also and I would imagine that anyone reading this blog and wanting to embark on a similar project may consider using the same engine management system as I have.

It is now almost 8 years since I started work on this project and I realise that, apart from the initial decision process back in 2012, I have not really given much feedback on the Microsquirt as an engine management system now that my own experience and the scope of the project has grown. Given the description of this blog, I think it is a good time to summarise my thoughts and experiences with the Microsquirt/Megasquirt platform so that anybody reading this and looking to embark on a similar project can make their own informed decision.


I'm afraid this post has turned into a long one so I will summarise quickly and then look at each point in more detail. The short answer is that, if I was to start this project again with my current level of experience, I would not choose to use the Megasquirt platform. The main reasons being as follows:
  1. The hardware is not quite capable enough for my application (high speed engine). Microsquirt specific.
  2. Limited IO capability and hard-coded pin functions make the system less flexible than I would like. Microsquirt specific.
  3. I find the support for genuine firmware issues lacking
  4. The package as a whole (hardware, firmware & user interface software) is, in my opinion, not particularly well integrated. 
  5. I have found evidence of questionable calculations/logic within the firmware code
  6. Some of the above points can be solved by choosing to purchase the top spec MS3Pro but the cost of the top spec Megasquirt puts you into the realms of most professional or semi-professional motorsport engine controllers with generally better capability, support and integrated software.
The content of this post represents my own personal opinion and is entirely based on my own experience with and understanding of the the Microsquirt v3, MS2/Extra firmware and Tunerstudio software. The post is not intended to turn people away from the Megasquirt system but rather to empower readers with the knowledge of my own experiences. If any of the information I have provided is inaccurate or felt to be overly damaging then please contact me and I will be happy to correct or remove it.



Why I chose the Microsquirt as my engine management system

I my first blog post in April 2012, I briefly outlined my reasons for choosing the Megasquirt platform and specifically the Microsquirt unit. These were:

a. Cost
This was the biggest driver for me. As far as I was aware the Microsquirt unit was, and possibly still is, the lowest cost assembled engine management system available in the aftermarket. At the time of beginning the project, I had no experience with engine management systems or electronic fuel injection and I had no idea if it was going to be possible to create a reliable, functioning system that would allow me to use the bike as I wanted to so a low cost, low risk engine management solution was an important need.

b. Opensource
At the time, I believed the Megasquirt to be an OpenSource project and the assumption was that all firmware and software were free. I now know this not to be true. While Megasquirt firmware is viewable and modifiable by users, it is a commercial, copyrighted product and its use is subject to a license agreement. For the standard user this may not make much difference. Firmware & updates are still provided free of charge and there is nothing preventing you from making changes to the firmware as long as you do not distribute the modified firmware and you make the modified firmware available to the developers.
The tuning software, Tunerstudio, is also a commercial product and although a basic version is free, the full function version is a paid upgrade. Albeit at a relatively low cost.

c. Support
The active support forum for Megasquirt users was very attractive. As a beginner, it is very comforting to know that there is an active community of users with different levels of experience which you can draw on if (when) you get stuck. The fact that the firmware and software developers are also active on the forum is also a big comfort.

d. Form factor.
The Microsquirt v3 is small. That makes it very attractive for anybody doing an EFI conversion on a motorcycle. My CBR250RR suffers quite badly from the lack-of-space syndrome so the small form factor was very important.



As a quick comment on the above Form Factor point, it should be noted that while the Microsquirt packaging is small, it only includes logic level coil drivers. That means for most motorcycle conversions (unless you are able to fit ignition coils with integrated drivers), an external ignition driver module containing the high current IGBTs is required. An external lambda sensor control module will also be required if using a wideband lambda sensor (recommended). While having these units external to the ECU can be an advantage from a packaging point of view, they generally increase the complexity of the installation and do need to be taken into account.
Now that the original decision process is fresh, I will jump back to the present and address the "why not" list.


1. The hardware is not quite capable enough for my application (high speed engine). Microsquirt specific.

While I have yet to find a defined maximum engine speed for the Microsquirt, the Megasquirt developers have stated in forum posts that the Microsquirt CPU is not guaranteed to be capable of tracking engine speed above 15,000rpm and, even then, the number of teeth on the trigger wheel will come into play. I am very much aware that the Microsquirt in my engine (18,000rpm) and 12-3 trigger wheel may be exceeding the design limits of the CPU. While I have bench tested the ECU up to 18,000rpm with satisfactory spark timing accuracy (after compensation for hardware lags has been applied), I cannot be sure if the accuracy is still as good when CPU experiences more load on a running engine.
This is a relatively unique use-case though as there are not many engines on the market that are capable of such engine speeds so it is hardly surprising that a low-budget ECU such as the Microsquirt would struggle. At the same time, competitor ECU's typically specify maximum engine speeds in the product datasheet so the limitations are clear when purchasing.
I would love to replace the standard trigger wheel with a higher tooth count wheel to increase engine position tracking accuracy but this is not possible with the Microsquirt controller. The Microsquirt simply does not meet the requirements of this project but then it never claimed to and I have to put part of the blame on myself for going ahead with the platform without knowing if it would be capable.
This is an issue specific to the Microsquirt unit and not a limiting factor of the Megasquirt platform. See point 6.


2. Limited I/O capability and hard-coded pin functions make the system less flexible than I would like. Microsquirt specific.

The majority of inputs/outputs are hard-coded to specific pins which means that if you do not use an input/output, you lose the functionality of that pin. For a basic ECU with already limited functionality such as the Microsquirt, this is understandable and it works fine for a basic installation. However, if you are installing a programmable ECU for a challenge like I did, you will inevitably want to expand on the capabilities of the system if even just to have the ability to log additional data that isn't necessarily used by any ECU calculations. When that happens, the only option is to either upgrade to a higher specification ECU or use an external data-logger with its own I/O capability. Personally, I have taken the 2nd option in the interrim with the plan to upgrade ECU in the longer term.
The Microsquirt is naturally going to be the choice ECU in the Megasquirt line-up for anyone doing a motorcycle conversion purely because of its physical size. Unfortunately for motorcycle people, the Microsquirt is also the entry level, most basic offering in the Megasquirt line-up and it does not look like the package or the firmware will be getting any upgrades in the future.
Again, this is mostly an issue with the Microsquirt unit and there are units available in the Megasquirt range which do not have these limitations.


3. I find the support for genuine issues lacking

One of the reasons for choosing the Megasquirt platform was that there was a very active support forum which the developers of the firmware and software frequent. There are a lot of threads started asking for help with many replies from users who appear quite knowledgeable and the queries seem to get answered quite quickly.
However, I found that as I got into the project and learned more about the system and the process of engine calibration, I began to find that the majority of questions on the forum were related to very superficial matters which were more than likely born out of the users inexperience and misunderstanding. As a new user, this is definitely very comforting to know that you have a place to ask the questions you are likely to come across.
While digging into logged data from my engine and the firmware code to try and understand how certain things were being calculated I found some genuine issues with the way the firmware was doing things. When I posted these issues on the forum they seemed to be largely ignored or I received pretty fluffy or defensive answers. It may not be the case but I felt that the attitude was along the lines of "what do you expect when we do this in our spare time?".
The issue with the way that the Megasquirt system is structured is that when it comes to the firmware, there is no direct line of support. If there is an issue with the hardware, you can approach the vendor who you bought the physical unit from. If there is an issue with the TunerStudio or Megalogviewer software, you can approach EFI Analytics who develop the software. But if there is an issue with the firmware then there is no clear path for support other than the forums. The firmware is developed by a handful people around the world who, to the best of my knowledge, do it in their spare time so approaching an individual and getting a timely and comprehensive response cannot be expected.
Also, unless the issue is hardware related, it is often very difficult for the user to distinguish if the issue stems from the user interface software or the firmware and so getting the information to the correct people can be difficult.


4. The package as a whole (hardware, firmware & user interface software) is not particularly well integrated.

This is related to the same issue as point #3. The separate developers and designers for the three main aspects of the ECU package, by nature, means that the Megasquirt package as a whole is not as well integrated as an ECU package where the hardware, firmware and user software are developed by a single entity and sold commercially as a package.
To me, the biggest issue with this structure is the user interface software. It is obvious that the Tunerstudio software has been developed by a separate entity than the firmware.
I can understand why the structure has worked out how it has. It looks like the developers of Tunerstudio saw a gap that was created by the original software not being very user friendly and not being maintained. It is just a pity that this alternative software has now become the only option for Megasquirt.
While Tunerstudio and it’s data analysis counterpart, Megalogviewer, are free in their basic form, to get any usability that approaches competitor calibration software, you need to purchase the full versions. I understand the requirement for EFI Analytics to employ this multi-level software as the company is a standalone entity but it does mean that when a user purchases a Megasquirt ECU, it is not offered with all the tools required to use it in the same way as competitors offer. This works well for the basic level Megasquirt offering as some people may not need or even know how to use all features of the software but when it comes to the higher level offering, the additional cost of the calibration and data analysis software from a third party supplier is a disadvantage and does need to be taken into consideration.
I have also found that there are not enough calculation parameters available to datalog via the Tunerstudio software. The available parameters to log are typically only inputs and end outputs. In my opinion, it is essential to include far more raw inputs and outputs from calculations in order to calibrate an engine effectively and troubleshoot any issues. These should include at least raw sensor voltages or ADC count, controller P, I & D contributions and injector open time determined by the ECU. This is most likely a limitation of the RS232 serial link as some of these additional parameters are available over CAN-Bus but as the user interface software cannot communicate via CAN-Bus then this is not particularly helpful. This may well be a case that only a limited number of parameters are passed to the interface software but it also serves to reinforce the integration issue.


5. I have found evidence of questionable calculations/logic within the firmware code

I prefer to work with Lambda rather than AFR because it is unambiguous and is a constant across different fuel types. It is also a simple scale factor so it is very easy to see how far away from stoich you are just by glancing at the measured lambda. AFR in general use is a theoretical ratio which is based on a chemically ideal fuel which is unlikely to relate to the fuel you are actually using so I don't actually see any benefit to using AFR as a measurement. The only time I would use AFR is if I needed to figure out how much air was passing through the engine.
The Megasquirt platform by default uses AFR in its fuelling calculations if you have chosen to incorporate AFR target in the fuelling calculation. In order to calculate the multiplier for the injector open time depending on Lambda target, the firmware needs to receive a user specified stoichiometric AFR from the interface software. This additional operation in itself makes AFR a less than ideal parameter to use within the ECU calculations.
Beside the point, I can accept that the calculations are done less than ideally and given the internet seems to have made people in general more familiar with AFR rather than Lambda it makes sense that the developers would use AFR if they are marketing their product towards the hobbyist.

The developers have included a feature within the user software which allows the user to specify that they want to use Lambda rather than AFR. This changes the default AFR gauge and logged field from AFR to Lambda and also makes the AFR target table display in Lambda. This looked promising and I used it until I noticed some anomalies in the data and looked into it.
Since the EGO sensor calibration which is sent to the ECU is in AFR, the AFR read from the sensor must be divided by the stoichiometric AFR to provide the Lambda value which is logged. I had always made the assumption that this conversion was carried out using the user provided stoichiometric AFR. This however is not the case in the MS2/Extra firmware. The firmware uses a hardcoded 14.7 as a divisor for AFR to Lambda, effectively providing an incorrect Lambda feedback should the EGO sensor input be calibrated to anything other than Lambda 1 = 14.7:1 AFR.

For example: Say you are running E85 with a theoretical stoich AFR of 9.8:1. You might calibrate the EGO sensor so that it reads 9.8 AFR at Lambda 1 and input a stoich AFR of 9.8:1 in the software for use in the fuelling calculations. If you have the software profile set to use Lambda, when the engine is running at stoich AFR (Lambda 1), the Lambda reported to the user through the software and being logged will actually be 9.8 (measured AFR per EGO calibration) / 14.7 (hardcoded stoich AFR) or Lambda 0.667. The also applies to the AFR target which is passed to the fuelling equation.

I have identified that the code was changed in the MS3 firmware so the issue is isolated to MS2/E firmware. I made the developers aware of the issue at the beginning of 2018 and the feedback has been that users should always use 14.7 stoich AFR even if running different fuel. This approach is acceptable but I feel it is not documented or made clear to the user that they should be only be using 14.7 stoich AFR when setting up the ECU.



6. Some of the above points can be solved by choosing the top spec MS3Pro but the cost of the top spec Megasquirt puts you into the realms of most professional or semi-professional motorsport engine controllers with far more capability, support and software.

While all the above might sound like I am bashing the Megasquirt platform, I do like the idea of a build-it-yourself hardware platform, freely available firmware whose source code is available for anyone to tweak to suit their own needs and simple calibration software. It is also undoubtedly the cheapest option for engines with high cylinder counts (more than 6) if you want to run sequential ignition & injection.

However, points #3, 4 & 5 are issues with the Megasquirt platform, not the Microsquirt unit so by upgrading within the Megasquirt platform these issues/frustrations would remain. From my point of view in controlling a 4 cylinder engine, I have come to the conclusion that there are many alternatives to the Megasquirt platform available on the market which provide the same features (if not more) as an MS2 unit for a similar cost, in a pre-assembled package, with a fully integrated hardware/firmware/software package, support from the manufacturer and more useable software.

I feel that there is still a market for the MS2 hardware and the MS3 DIY kits within the hobbyist community but when you start getting into the cost of the fully assembled and smaller footprint MS3Pro series of ECU, I feel that the money is better spent on an ECU that is produced by and supported by a commercial entity and is marketed at professional or semi-professional race teams rather than hobbyists.




I have come to the limitations of the Microsquirt ECU quite quickly with this project and, in hindsight, I have spent far more time and effort trying to overcome these limitations than I should have. I should have upgraded from the Microsquirt a long time ago. An ECU upgrade is already in work and will be the subject of future blog posts. Given my issues outlined already, I will not be continuing with the Megasquirt platform.

I have a Life Racing F88R ECU available to me that I purchased for a different project so I have decided to fit the F88R to the CBR250RR in place of the Microsquirt. Of course the F88R is in a different price bracket from the Megasquirt offering so cannot be considered a direct competitor. The F88 platform is mainly targeted at the professional motorsports market. The performance and features available reflect this but then so does the price.
I have also recently become aware of the ECUMaster EMU Black ECU which is in the same price bracket as the MS3Pro ECUs but includes some very nice features such as onboard LSU lambda drivers, full H-bridge for DBW throttle control, 2off onboard K-Type thermocouple inputs, 6off injector & ignition outputs and very professional software. These are features that are not common at all in ECUs priced around $1000. If I did not already have the F88R ECU the EMU Black would be my choice for this project.


If you are new to EFI or engine tuning, it can be difficult to know what you don't know. There are so many options available now on the market that it can be daunting to pick the one thats best for you. My advice would be to figure out what features you want and use them to narrow down the choice. Also make sure that the ECU hardware is capable enough for your use case. If you are unsure, contact the manufacturer.
Once you have narrowed down the options, it is a good idea to visit the manufacturers website & download a copy of their software. There are usually some sample projects included to allow you to get familiar with how the software works. The software can make or break an ECU. It is the only interface you have so make sure you are happy with it and it does what you want. 

If you are still reading, I hope this has been helpful.