Duty-cycled radio

The radio is sleeping most of the time. When sleeping, a low-power timer runs to wake the system. The sleeping radio cannot wake the system when it receives.

Example: the system may sleep for a few seconds, and be awake (with radio on) for about a millisecond. That is, the duty cycle is around 1000.

Voltage monitor/Load switch

A microprocessor (in a radio SoC) needs a fast-rising voltage to boot cleanly. Otherwise it may enter a state where it consumes power without booting. (Fibrillating?) It may be in that state for a long time. The solution is to use an external voltage monitor aka power supervisor aka reset chip. E.g. TPS3839 (ultra-low power of 150nA.)

You can’t just connect the voltage monitor to the reset line of the mcu. Otherwise, the mcu will still consume power while its reset line is held in RESET state. (Between the time voltage is high enough for the voltage monitor to have active outputs say 0.6V and the time the voltage is high enough to run the mcu say 1.8V.) An mcu may draw a fraction of a milliamp while held in reset.

So the voltage monitor drives a high-side load switch that switches power (Vcc or Vdd) to the mcu. I use the TPS22860. (You can switch ground i.e. low-side with a NMOS mosfet but it’s not so easy to design your own high-side switch. You can’t switch the low-side of an mcu because many pins may leak to ground?)

Voltage monitor hysteresis and boot sequence

The voltage monitor asserts its Out (sometimes call Not Reset) at a certain threshold voltage but then unasserts if the voltage falls below the threshold a certain amount called the hysteresis. While the mcu is booting, it must not use so much current that Vcc falls below the hysteresis. The boot sequence typically does a bare minimum, then checks Vcc, and sleeps until Vcc is much beyond the the minimum. That is, allowing time for the ‘challenged’ power supply to catch up and store a reserve. Only then does the software proceed to use the radio, duty-cycled.

You could use a voltage monitor with higher hysteresis. But they don’t seem to make them. The hysteresis of the TPS3839 is only 0.05V. You can play tricks with a diode/capacitor on the input of the voltage monitor to make it seem to have a higher hysteresis (to delay longer before un asserting.) And there are application notes on the web about adding hysteresis to voltage monitors. But they seem to apply to older voltage monitor designs, and don’t seem to apply to the ultra-low power TPS3839 (which samples Vcc.)

Also, you could design your own voltage monitor with more hysteresis. For example, see the Nordic solar powered sensor beacon. That uses a few mosfets to provide a 0.2V hysteresis (say booting at 2.4V and resetting at 2.2V). Unfortunately, they don’t seem to have exactly documented how the design works.

Power Budget

A power budget calculates the average current of a system, given certain phases of certain durations, where each phase uses certain devices/peripherals.

Here the main phases are:

sleeping (say 1.5uA for 1 second)

radio and mcu on (say 6 mA for 1 milli second)

You can almost ignore any phases where only the mcu is active, it should be a small portion of your budget.

Synchronization algorithms

These make your units wake at the same time, so they can communicate with each other.

A beacon is usually unsynchronized. The thing that hears a beacon (e.g. a cell phone) has enough power to listen a long time. You also might not need to synchronize if you have a “gateway” that is always powered and listening. (See Zigbee.)

This seems to still be a research topic, there is much literature to read and few open source code examples.

Testing is hard

With such a challenged, nanopower supply, testing is hard. A bug may exhaust power so that the system brown out resets, losing information about what happened.

Most hardware debuggers make the target consume more power than the power supply can provide? TI seems to have ultra-low power debugging tools, but I haven’t studied them.

You can implement fault/exception handlers that write to non-volatile flash so that you can subsequently connect to a debugger and read what happened. Default handlers typically just infinite loop (which will brown out reset.) Typical handlers will do a soft reset. Unless your app makes a record or communicates that, you might not even know the system reset itself.

Agililent (formerly Hewlett-Packard) sells expensive instruments for monitoring power consumption. These may tell you you when (in relation to other events) you are consuming more power than you expect, but not exactly why.

Over voltage

A solar cell is a current source, and provides a variable voltage. Voc is voltage open circuit (when your capacitor is fully charge.) It can exceed the Vmin of your radio (typically 3.6V.)

Voltage regulators (such as shunt regulators) that prevent that are themselves current wasters.

You can choose a solar panel whose Voc is less than the Vmin, but there are few choices in that range (Voc < 3.6V, Vope around 2.4V, for indoor light.) Or you can require that your solar panel never be exposed to strong light.

I haven’t found a zener diode that would clamp the voltage to 3.6V, and not leak much, at such nano currents.

Energy Harvesting

This is another buzzword, but good to search on. It often means: with a single coin cell battery.

Energy harvesting chips are available. They solve some problems you might not have, such as over-voltage protection, or voltage boosting.

It often refers to other power sources such as heat or vibration. Those power sources are usually even smaller than solar (light) power, but solar power is episodic (diurnal.)

Solar power in different setting differs by orders of magnitude. Direct sun is ten times stronger than outdoor, blue-sky shade, which is ten times more than strong indoor light, which is ten timer more than dim indoor light.