Look, when a company claims that you can get 1uA power consumption in a standby state, you have to take them up on that claim.

1uA effectively means 100,000 hours on a single CR2032 coin cell battery. You know, the ones IKEA cheerfully calls the PLATTBOJ.

This is not an IKEA post.

100,000 hours means a year of running on a single coin cell. Now I have five year old plastic Casio that is still running, and I don't even know what the battery inside the watch looks like.

That's all very well and good. But the Casio watch doesn't do Bluetooth.

This is not a Casio post.

Now there's Nordic's excellent nRF52840 that we can talk about. Very popular amongst hobbyists, and it has seen some inroads into commercial products due to it's low power features. Then there is the CC2250 from Texas Instruments that is extremely popular amongst commercial Bluetooth products: beacons, dongles, exercise bands... you name it, it probably has a CC2250 or some variant of that inside

This is not a TI or Nordic post.

This is a Silabs post.


Now Silabs didn't actually claim that their chip draws 1uA when active. That happens when it is sleeping. When it is awake and broadcasting, it draws 1 ~ 3 mA, which is about 1000x more.

So if we spend all of our time sleeping, we can effectively extend the life of the system by a significant amount.

It is not a very interesting test if the chip just sits there and does nothing. Suffice to say, I tested it, and Silab's claim is roughly in line with what I observed.

Let's have the IC do something a little more exciting.

Better Soil Sensor
How a capacitive moisture sensor works with a 555 timer, and getting it to work with the BG22 Bluetooth chip from Silicon Labs!

So let's bring back the soil sensor application! For this test I've decided to just test the BGM220 module, so I've disconnected the soil sensor, which draws around 8mA.

Uploading the code, I immediately ran into the first issue where the chip was drawing about 1mA on average, even when the soil sensor was disconnected. No biggie, I didn't optimize the power saving features anyway.

However, as I dived deeper into the code, I realized that the Power Manager software module was already installed in the default empty-SoC Bluetooth application. It automatically handles entering and leaving of all the power saving states from EM0 (active) to EM3 (deep sleep).

So I was already (in a way) using the power saving features. So why was I drawing about 1mA? I made very sure to shut off all external peripherals, even the ADC when the device goes to sleep, and I even tried to manually toggle the EM3 state myself, but I was still coming up short.

I finally realized my mistake when I decided to create the base template from scratch.

I forgot to turn on power saving features for USART!

It took me the longest time to figure out why the chip was not going into sleep mode, and the answer was really quite simple: I neglected to turn on the power saving features on the USART peripheral.

Without toggling the restrict energy mode, the module draws about 1mA staying at EM0. However, when it stops broadcasting and turns off all peripherals, it can actually go all the way down to 97nA.

There is still a 1mA glitch with the WSTK and SSv5 where a series 2 IC will draw 1mA when it is just flashed or the secure bootloader is read. To fix this, the IC just has to be reset for it to start drawing the right amount of power. There is an additional issue where the chip will seem to draw 80uA at minimum, but this can be handled by updating the WSTK.
Module going from sleep to broadcasting

Overall, with a power scheme of being 50% on and 50% sleeping, the module draws around 248uA on average. The current and power draw can definitely be brought down even lower by increasing the percentage of time spent sleeping. In fact for an operation like sampling environmental data, this can be done for a few seconds every 10 minutes (which might even be excessive). This presents a ratio of $$\frac{I_{\text{active}}}{I_{\text{total}}} = \frac{10}{10*3600} = \frac{1}{3600}$$

Previously the duty cycle was:

$$ \frac{I_{\text{active}}}{I_{\text{total}}} = \frac{1}{2} = \frac{1800}{3600}$$

Which implies that

$$I_{\text{new}} = \frac{1}{1800} \times 248 = 0.13 \text{uA}$$

This implies that we can theoretically bring down the current usage from 248uA to 0.13uA, but realistically I would peg it to 1uA.  

For a CR2032 battery, which has a capacity of about 100mAh before the voltage starts to drop precipitously, this means the application can run for 403 h at maximum, which is roughly two weeks.

That is quite a long time for a coin cell battery, but how would it perform when paired up to Infinite Energy from the Sun™? Will it last a month? A year? Well, the only way to find out is to test it!

So instead of a tiny CR2032 battery, I hooked it up to the fairy light that boasts a 800mAh battery. This effectively gives us a month of operation just off the battery alone. Coupled with trickle charging the battery with the solar panel, it gives us a very long run time.