Firstly, the good news is that the work around reconfigurable timers from the last update has been finished. Sequential 6 and 8 cylinder combos have been tested and look to be working. This is of particular benefit on 6 cylinder engines that can now be configured to run full sequential fuel with wasted spark ignition. I REALLY need to get some documentation written around this as the method is not entirely clear, but it is there ready to go.
Bug / Request bounties (or "Holy Crap Project Maturity")
A few people have commented (and a couple have already used!) that there’s now a ‘bug bounty’ feature that’s been added on the Github repo. For those who haven’t seen these before, it’s a system that allows a ‘bounty’ to be placed against a bug or feature request in order to gain some developer attention.
So, before everyone rolls their eyes and tells me I’m selling out, I do want to give a little perspective on why this (and other things like the Patreon account) came about. Whilst it’s impossible to get an exact idea of how many people are using Speeduino, I can say with confidence that it has grown significantly over the past 12 months. I’ve long ago given up trying to track number of running engines etc, but I can say that I’ve just shipped out the 800th order from the Speeduino store, which is in addition to those that others have sold, ones people have done themselves etc. In short, what this means is that the user base for the project is now ‘large’, where large is probably somewhere over 500 people with running or active projects. This leads to a LOT of requests for changes, features, bug fixes etc and on any given day I probably work directly with at least 5-10 different people via email/ Facebook/Slack/Forums etc around this. I’ve always balanced my development time between new features that I consider important, bug fixes (ALWAYS prioritising bugs on running engines where I can) and other user feature requests. Unfortunately this does mean that sometime things simply never make their way up the list to the point where I put some time into them.
What I hope is not that this bug/feature bounty system is going to make me a huge packet of money, because it won’t. At most these bounties might get to $50 or so. What they WILL do though is let me see what issues are really important to people, which goes a long way to helping prioritise what short be resolved first. That's not to say critical things with no bounties won't ever get looked at, but their priority will be based on my interpretation of importance alone (As has been the case up to now).
One thing that a number of people have said can cause some confusion when tuning is trying to figure out exactly what is causing changes in the pulse width at a certain time. Whilst there has always been the GammaE figure that shows the sum of all corrections, it can be difficult to see exactly what is causing that to vary at any given time.
To help aid in tuning, there’s now a custom dashboard that comes with the firmware that shows how both the GammaE and overall pulse width are currently being calculated. The file for this dashboard is located in the 'reference' directory of the firmware and can be selected as the base when adding a new dashboard tab in TunerStudio.
Note: This is currently only showing the value of pulse width 1, so if you are using individual cylinder trims or staged injection, the other channels may differ from this.
One area of the documentation that has always been too light on is the wiring diagrams, which are a critical thing, particularly for beginners. There are a few there, but they’ve varied a bit in style and detail etc. There are a few reasons for this, but one of them is that they can have a bit of a steep curve to get started on, not only finding some software, but also getting suitable images to use within them that aren’t copyright protected to someone else.
To try and make this easier, I’m going to standardise on a tool called draw.io. This is an online (and offline) tool that works well for wiring type diagrams and is available across all platforms (Win/Mac/Linux). As part of this effort, I’ve begun creating a library of relevant automotive drawings (injectors, fuses, sensors etc) that can be imported directly into draw.io. Most of these are ones I have created myself and, critically, are not copyrighted in a way that prevents their use. They are all offered under Creative Commons licenses.
This should not only make it easier for people to start helping out with diagrams if they want, but also give a consistent feel to all the diagrams used across the wiki.
So with that all said, there's also the usual other bug fixes and small improvements. Here's the full list of main changes:
- Selectable squirts per cycle is now working. Previously Speeduino defaulted to always using 1 squirt per rev (2 squirts per cycle on 4/stroke) unless sequential was used. Whilst this was listed in the documentation, it was less than ideal as other values for this could still be selected in TunerStudio. Note that there remains some issues with 8 squirts per cycle, but all other values should be working.
- Multiple comms and memory changes to allow for the calculations dashboard
- Add ability to read EMAP sensors. This uses the same cycle average algorithm as is generally recommended for IMAP. Currently this is only a read variable, use of this for load (Eg IMAP/EMAP) is coming next month
- Multiple cranking improvements on the Miata 99-05 decoder
- Boost and VVT control now work on Teensy boards
- Allow final values in the WUE table below 100%
- Increase the cranking RPM setting resolution to allow for 10 rpm increments rather than 100
- Removed a bunch or warnings that may have been coming up when projects were loaded in TunerStudio
- Fixed a regression that could cause the PWM idle control to not work on startup
- Negative values are now allowed in the fixed timing field
As always, if there are any issues that appear with this firmware, please post a bug or let me know in the comments of this post