Sep 22, 2021

5 min read

Zero Batteries - Why we made ONiO.zero

ONiO.zero is undoubtedly not the first microcontroller in the world that runs from something different than a battery. It is actually a ton of good microcontrollers out there from Ambiq, Atmel, Freescale, ST, Nordic Semiconductor and many more. The recipe for all of them is similar - some sort of ARM Cortex-M CPU combined with analog and digital peripherals, embedded flash memory and some RAM. Some have radio transceivers - some don't, some have USB and some don't. The so-called energy-efficient ones have onboard DC/DC converter to trick us the user a bit on the current consumption. It is really not all that exciting.

Hey wait - did we just instigate that microcontrollers have become dull? 

ARM lifted, for the most part, what used to be a big differentiator for microcontrollers namely their CPU and bus system. Most microcontrollers of today have pretty good CPU performance - and how we interface to the world with digital or analog peripherals have not really changed much. Interfacing an external sensor, one can rest assured that it is highly likely through SPI, I2C or UART. Maybe with the addition of some GPIOs. End of story. The point of limiting differentiation being further accentuated by most microcontroller vendors rather talk about some exoteric security use case or the availability of a software framework that is the universal truth (Of course thoroughly tested and ready to deploy, with yet another OS).

You may find the above summary entirely provocative and offensive - heavy sigh - however, something great came from it. And that was a motivation to make something different. While weeding through the various samplers on the microcontroller taste menu (Ambiq Micro gets our honorable best in class mention!) ONiO found that almost none were suited for our application - a small skin-worn medical sensor.

The battery conundrum

The problem we faced was a constant battle between having to use an external device to either boost or step-down the battery rail we had available. Since almost none of the microcontrollers considered could take the voltage of a single cell lithium battery directly (most limited to 3V6 maximum), it means having a step-down regulator in the design. Together with a good quality inductor you now have added as much cost to your BoM as the microcontroller itself. Not to mention that the microcontroller vendor will typically sell you on using their internal buck regulator to get the best power numbers - not telling you the downside of putting two regulators in series and what that does to power efficiency. So now the design is stranded with two regulators in series that by themselves offer some 85-90% efficiency - for a compound efficiency of 72-81%.

“The real problem with the battery approach came when considering shelf life and environmental aspects. A shelf life of 5 to 10 years means that 99% of the battery capacity was burnt during storage.”

Leaving the single-cell lithium battery approach, one can always try alkaline batteries providing some 800-1500mV to play with. Besides some very honorable exceptions, this rail is not accepted by most microcontrollers. So again, we have to use an external boost circuit - that as in the example with the step-down will run you almost as much as a microcontroller accounting for an extra inductor as well. Interestingly enough to achieve the lowest energy operation possible the microcontroller in front of you probably require to use its internal buck regulator to divide down the rail you just boosted to 1V8 or more.

So in ONiO's application running from any type of battery meant adding a step-down or boost circuit with the added cost of such regulator. Or one could have selected one of the honorably few microcontrollers that will run directly from a lithium cell or single cell alkaline battery. Either way a significant premium is added to your BoM due to additional components or from sourcing a premium priced microcontroller.

Tequila Sunrise

But the real problem with the battery approach came when considering shelf life and environmental aspects. A shelf life of 5 to 10 years meant that 99% of the batteries capacity was burnt during storage. And if looking for a shelf life in a hot climate all bets were off when considering 5 years due to much higher leakage. There are solutions to this problem, and that is either to add a charger or to use a very specific battery topology or chemistry. Both meant that the stick and forget medical sensor now was seriously expensive and troublesome to export.

“ONiO.zero will handle most energy sources as RF, ambient temperature, kinetic or voltaic cells. The device is programmable, has a powerful RISC-V CPU and comes with analog and digital peripherals you would expect from a microcontroller.”

And there it was - what do we do now? And it quickly sunk in that just maybe we could power from the surroundings. And that is the path ONiO has chosen since and it was the start for ONiO.zero some 12 months ago. What we found was that there are many excellent solutions for harvesting energy from our surroundings today. But they are certainly not easy to use, have a low level of integration, and come at a high cost. ONiO's goal is to change this - where simply the energy source ambient to the microcontroller is harvested directly, sensors are interrogated and processed locally and data stored or wirelessly transmitted. ONiO.zero will handle most energy sources as RF, ambient temperature, kinetic or voltaic cells. The device is programmable, has a powerful RISC-V CPU and comes with analog and digital peripherals you would expect from a microcontroller. In fact it also comes completely stripped from an OS - just good old embedded programming. Cheers! 

About the author

Vemund Kval Bakken

Chief Technical Officer

Vemund is the chief technology officer and co-founder for ONiO. He is responsible to set the long term technical direction and make sure that novel solutions are applied in our products. And make sure when ideas are novel enough that they are added to a growing IP portfolio.

We are using cookies to give you the best experience on our website.
You can find out more about which cookies we are using or switch them off in settings.