Hi everyone. @It.s-A-Lex had a lot of good questions that I thought would be great as their own Q&A update.
If you all like this, we can make it a regular thing as part of weekly updates. Be sure to throw a 
below, and comment your thoughts or additional questions. Your interaction with these updates shows me what’s important to you. And helps to inform my decisions going forward. Thanks!
Let’s get started…
Thanks, and welcome! 
We’re actually in the middle of Alpha testing now, with live-testing actively happening on a large dual cylinder v-twin vertical shaft engine. It’s a big one, at over 500cc. The twin is run on a test stand still, so we’re still not quite on an actual vehicle yet.
I’m moving to on-vehicle testing soon. The first will be the Ranger 800.
From a hardware standpoint, this is currently possible. However, this would take some work in software. I’ll be looking to add it in. If I can, before beta release (no promises though). But certainly some time shortly afterward. In the meantime, feel free to create a feature request in the ideas section and we can start a deeper discussion around the specifics 
At first glance, I can say that your speed sensor would need to have a 5v pulse-based output (or be translated externally to 5v).
Are you able/willing to take some measurements, pics, and help me track down any technical manuals for your model? If so, do me a favor and create a topic for your Agility 50 over in the Powersports section. I’ll have a bunch of questions for you about the bike, and then I’ll be able to say for sure what will be needed for compatibility.
The primary processor (ATmega328p) will handle the auto-tune feature, no problem. I have a few approaches in mind, none of which are computationally heavy. So there’s no reason to offload the process to the co-processor.
Autotune will get added to what I call the “base scheduler” which runs in the main loop. It checks statuses and schedules non-critical functions with lower priority. On the other hand, all injection, ignition, triggering, timing, and counting is interrupt based (very high, immediate priority). So anything going on with base scheduling in the main loop (like auto-tune) is paused when the high priority stuff fires. Then resumes afterward. We’re a long way from maxing out the base scheduler, so no worries there.
So although it’s true that adding a new process like autotune will consume a few additional cycles worth of processing, there are plenty of extra cycles to go around. It won’t affect performance in any way.
This question really deserves its own update explaining how the local / mobile, and cloud functionality have taken form. And the differences between it all. I’ll follow-up on this one.
As of right now, what I’m calling the “core” kit is aimed to cover the basics and will include at least the TPS, TMAP, and fuel pressure sensors. Others will be offered separately. This is still pretty flexible, and we’ll probably settle on an à la carte system of ordering customization to meet people’s needs.
The term “OTA” is short for Over-The-Air. In our case, it means that NanoEFI’s updates are completely wireless over your home/office WiFi and internet connection. With no physical connection, cables, or adapters. No USB ports to wear out, break, or jiggle to get just right.
When you want to update to a new release, your ECU securely downloads the new encrypted firmware package directly from NanoEFI.com. It handles the entire firmware flashing process with “one click”. No fiddling with settings, baud rates, com ports, or anything else technical.
- Turn the key on to power the ECU;
- Open Airtune (online), select the target ECU and desired release version;
- Hit the “update” button. Bam.
That’s it.
Watch the progress bar fill up and you’re ready. 
And as a bonus, you can’t possibly brick the processor while updating with OTA! Even if power is hard cut to the ECU mid-burn. Just power it back up and hit update again. It’s a really robust process.
Pretty cool, huh?
There are no plans for porting over to different main processor after launch. In terms of processing speed, the ATmega328p is overpowered for what we’re doing with single and dual cylinders. Unless I start getting sloppy on optimization, we’re nowhere near maxing out it’s processing capacity. 
With that said, I’m interested in the SAMD21 series. But still, no plans. The 328p is capable of covering our needs for a good while.
No plans for knock sense right now. It’s something I’m interested in down the road, but I haven’t started researching yet.
However, I believe I saw that a relevant patent dealing with knock detection via Ion Sensing just recently expired. If anyone wants to help me look into that, I’m game. 
