Achieving Ultra Low Power Bluetooth with BG22

How to get the lowest power consumption on the BG22 using project defaults. Or how to get 100,000 hours runtime on a BG22.

Achieving Ultra Low Power Bluetooth with BG22

When a company claims that I can get 1uA power consumption in a standby state, I 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.

100,000 hours means 10 years 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.

Now there's Nordic's excellent nRF52840 that we can talk about. It is 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. But they don't do 1uA consumption.

So you can see why I might just be a little excited about this.

Diving in

When the BG22 is awake and broadcasting, it draws 1 ~ 3 mA, which is about 1000x more than 1uA. So if we spend all of our time sleeping, we can effectively extend the life of the system by a significant amount.

However, it is not a very interesting test if the chip just sits there and does nothing. So 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 I decided to bring back the soil sensor application! For this test I've decided to just test the BGM220 module, which a module-based off the BG22. For this test I've disconnected the soil sensor which draws around 8mA.

Upon 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. I wasn't too concerned, because, I didn't optimize for the power saving features in my other project anyway.

However, when 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 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 because the power consumption stubbornly remained at 1mA

In a fit of frustration, I decided to create the base template from scratch and that was where I finally discovered my mistake:

I forgot to turn on power saving features for USART!

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.