[Q&A March 30th] Alpha testing, Speed limiter, Auto-tune, "OTA" firmware updates, Processing speed... (and more)

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 :heart: 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! :wave:

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

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.

  1. Turn the key on to power the ECU;
  2. Open Airtune (online), select the target ECU and desired release version;
  3. Hit the “update” button. Bam. :boom: That’s it.

Watch the progress bar fill up and you’re ready. :sunglasses:

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.

OTA in Airtune2

OTA in Airtune3

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

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


A post was split to a new topic: Will nanoEFI work with 2-stroke engines?

I’m a few months behind, but in the Q&A mentality:
How are harness integrations expected to go? Does NEFI have a supplier for most connectors for various powersport equipment and plan to make PnP harnesses or is there likely to be some wire splicing involved?
Has any planning been done towards forced induction setups, or is the existing MAP and existing code going to be able to handle the vacuum-to-pressure ranges expected in forced induction?
How is engine temperature going to be monitored? Thoughts on different sensors for different cooling systems? (air/oil/water)
What is the impact of water ingestion likely to be on the system? Are there special precautions or processes that will need to be taken into consideration for when the water crossing might be deeper than it looks?

I have relationships from previous projects with connector manufacturers and distributors overseas. We can get almost all powersports and automotive connectors. Without suffering price mark-ups from middlemen stateside. My contacts are also great about being able to ID connector variants with just a picture or two.

Our wire is made in the USA :us:

The official harness from NanoEFI will be a universal fit with a few length options, as plug and play as possible. Although an open pigtail will be available for hardcore DIY’ers, I want to help most people avoid having to deal with mass-splicing their install and the headaches that can follow.

I’m going this route to keep processes lean internally, and minimize SKUs / management.

For exact-fit model-specific harnesses, I’d love to work with guys who might see opportunity in producing/offering exact-fit NanoEFI based setups to their respective riding community. I’ll be here to support the dealers with design, development and training. As long as they can support their customers directly after sale.

For common analog 1K NTC temperature sensors, you can use Sensor channels 5 and 6. These channels have internal pull-up resistors for native NTC support. The idea is to allow for head and coolant temp sensors to be used without any mods.

For more than two NTC-type sensors, you can add an external 1k or 10k resistor (depending on your sensor resistance) to pull-up to 5v. Or better, use the I2C protocol on those same pins (SN5 and SN6) to communicate with an external ADC module.

I’ll have a few styles of head (ring) and water/oil temperature sensors available.

My latest diagram (below) is outdated now. Sensor channels 6, 7, and 8 have been added in the latest board version. As well as adding the digital TWI / I2C interface.

This wouldn’t be a default feature. But you can connect a suitable switch (perhaps fixed to a float?) to one of the sensor channels, and tell the ECU to apply a hard ignition and fuel cut if that switch ever goes high or low.

1 Like