Close

Improving battery life

A project log for Watchduino2

Inexpensive Open Source BLE smartwach compatible with Arduino tooling

Mar BartolomeMar Bartolome 09/19/2015 at 19:200 Comments

As you probably know, one of the reasons that drove us to build Watchduino in the first place was the prospect of creating a smartwatch that you wouldn’t need to think about recharging. We achieved this with the first Watchduino, using techniques like sleeping the processor, and getting rid of any component that we didn't need from the Arduino (such as LEDs). We upped the battery life from days to months, and we expect we can achieve the same with Watchduino 2.

This is what we've tried so far to achieve our goal.

Sleeping the Arduino

In the original Watchduino we were using a library called Jeelib. This library features a handy module called Sleepy, which you can use to *completely* sleep the ATMega processor in the Arduino, driving it's power consumption to almost zero. The only thing that it'll wake it up is a magical kiss... well, ok, not really. It's a hardware interruption. You can trigger one by setting a timer with the library, or activating pins number 2 o 3 in the Arduino.

In our case we are waking up the Watchduino when pressing the menu button (hooked up to pin 2), when we receive a Bluetooth notification from the phone, or when a timer triggers every 60 seconds.

But why wake every 60 seconds? Well, if we wake just for a fragment of a second it's not going to be such a loss in power consumption: we are still asleep 99% of the time. But by waking up every 60 seconds we can update the time on the screen every minute, and it'll appear that the Arduino has never gone to sleep. We can show the accurate time on the screen 100% of the time, so you won't need to actually wake the processor for a few seconds with the button interruption simply to look at the time.

OLED Screen

So does this mean the screen is on all the time? Correct. You may think that this is not the smartest move energetically, but let me surprise you.

OLED screens are made out of LEDs. LEDs will only drain power when they are on. This is why when your screen is black, it will waste no energy at all. But what about if we make it almost black?

Everytime we send the Arduino to sleep, just before it closes it's metaphorical little eyes, we instruct it to turn off all of the LEDs in the screen, save for a little area in the middle of the screen, where we shall show the current time, hours and minutes, with no seconds. The Arduino will turn on those LEDs before going to sleep, so they will stay activated after it does. After a minute, the Arduino will wake up, update the time, and go to sleep again.

The consumption of the screen while on this sleeping cycle is minimal, and the benefit of having an "always-on" device is huge.


Sleeping the Bluetooth module

The two optimizations above we are already applying. However, our biggest woe at the moment is the Bluetooth module. Despite being "low energy", it's certainly our most energy-hungry component, consuming up to 10mA when it's operating.

However, according to the specs, the HM-10 module that we are using can be optimized to consume between 0.4 to 1.5mA. If we managed to do this, the battery in Watchduino could last for weeks on a single charge.

Our purpose is to be able to integrate the Bluetooth module into the watch sleep cycle, reducing it's consumption when it's not being used. One of our initial experiments involved physically switching off the Bluetooth module with a transistor during the sleep cycle. This had a bunch of problems though. The phone could no longer detect it when it needed to send notifications, so these could not be made in real time.

We have now discovered that the HM-10 specification allows you to activate a sleep mode using the AT+SLEEP UART command, where the Bluetooth device will reduce it's activity somehow, but still remain visible for the phone. So any notifications will reach the Bluetooth module as normal, and wake up the watch. While on this sleep mode, the consumption of the Bluetooth module is close to 1.5mA, as promised by the spec.

A problem that we still need to solve is that after the Bluetooth goes to sleep, the communications from the watch to the phone will need a re-pairing of the two. We are confident that we'll find a workaround for this.


Overall consumption, and battery life

During the sleep cycle, the overall consumption for Watchduino 2 is 2mA. If no manual interruptions are triggered, the timer interruptions will wake up just the Arduino (not the other components) during less that a second. This means about 98% of the time being sleep time.

Considering that we are using a 240mAh battery, this gives us a theoretical battery life of 5 days (240mAh/2mA = 120h). This would of course be reduced if we manually wake up the Watchduino, but we are considering the maximum possible value physically.

Unfortunately, in our prototype the maximum battery life we have achieved has been roughly 48 hours under these ideal circumstances. Which is not terrible, but a bit disappointing given our calculations. We believe that the quality of the batteries we are using (the cheapest ones you can buy off China) might have a lot to say here, so for next experiments we will stock ourselves with different batteries of different prices, and check if they make any difference.

One tool that comes very handy for monitoring the battery life of our prototypes is the battery graphing that we've implemented in the companion app. When active, Arduino will, every 5 minutes, get the voltage that the battery is providing, and send it to the phone via Bluetooth. The phone will then use that data to make graphs like this one:

Another option to extend the battery life to double what we have now would simply be add a second battery as an additional smart link on the strap. Even if this is an option, we would still like to optimize the last drop of power from those 240mAh that we have from a single battery. Those 5 days of battery life (or at least something closer to them) are definitely within our reach, and beyond that, we are still hoping we will find further ways to optimize to extend it even more!

Discussions