Because NanoEFI should be easy for everyone to tinker.
Ease-of-use is a big priority for this project. But having the ability to tune EFI parameters to get the best performance (or gas mileage, etc), can add a lot of complexity quickly, both in development and to the end user. Which in turn can cause a higher number of people to fall off of the learning curve and end up not using the device or contributing to the project at all.
The first proposal was to ignore performance and efficiency tuning, which fits well when considering affordability. That would make the pitch to riders revolve around reliability. Just outdo carburetors to a set margin and everyone should love it.
But then again, seeing as how a lack of ability to tune would likely turn off users whom are more technically inclined and expecting of such features, the case on tuning couldn’t yet be closed. It became apparent that NanoEFI project needs to be include the ability to fully tune fuel maps without hard-coding the Atmel328p chip’s software for each tune.
So how about tuning over USB/Serial cables?
It’s too complicated.
The consequences of using a cable interface are more than immediately comes to mind. If looking at using a FTDI for example, it becomes clear that all of the additional documentation to get each user up to speed on the tuning process, as well as the extra costs ($25 for a quality cable), plus all of the new places that people could run into pitfalls in wiring and extra 3rd-party programs made it a deal-breaker if a wired connection was the only option.
Documentation requirements would be lighter, but the technology itself would be too limited and harder to implement/update.
If we look into a Bluetooth interface, sure that would work. But programming an interface for Windows, Linux, etc to operate over would make development too much and use too cumbersome.
We may have a winner!
All things considered, the technology that most closely suits our needs is WiFi. Of course, provided that we can find a low-cost chip to do the heavy TCP/IP lifting for us.
HTML/CSS/JS User Interface
Interfaces can be programmed much easier in HTML with a nice JS library like jQuery. Polish it off with CSS3 and we can implement a user interface that abstracts away the more technical aspects of the tuning process.
Remote-hosted code and Auto-updates
Since WiFi has the benefit of being connected through the user’s local network, the HTML for the interface itself can be pulled directly via HTTPS from nanoefi.com servers so that fitting all of that coding into the 32kb of the Atmega won’t be an issue. We’ll need to use up just enough space to transmit the bare document structure and an iFrame.
Even updates to the NanoEFI software can be pulled from the internet with a few clicks of the few mouse (or automatically).
Tune on the fly (or on the road)
The final – and perhaps most awesome – benefit of integrating WiFi is that the user will be able to tune and make adjustments to their tune while on the road with a mobile device. Pull over to a rest stop, put the NanoEFI unit into “SoftAP” mode. This creates a hotspot that your mobile device can connect directly to to access the tuning interface, without needing a network.
This will require a more barebones interface. But there may be a technical workaround that will allow the mobile device to use its own data connection to load the remote-hosted interface files from online.
The WiFi module
After researching, it turns out there is an IOT device available for around $3 – $4 that should suit our requirements. Introducing the ESP8266.