The fixes for working around silicon issues that Nordic provided initially showed some good results in that they removed the stability issues during extreme, rapid temperature change (freeze a Wimoto Climate to ~-15c, then bring it to ~+40c quickly). However, when we started to power profile the devices earlier this week, we found that the reason things were stable is that the main CPU clock was being used nearly 100% of the time. I’ll attempt to explain and illustrate why this is a “very bad thing”, but it’s a relatively hard to articulate (or at least I’m not sure I’m able to do it very well 🙂 ).
Bluetooth Low Energy (Bluetooth Smart) achieves much of its potential energy savings through pretty much spending most of its life sleeping — the best way to save energy is not to expend it, after all. The radio, by far the most power hungry component, wakes up in a orchestrated fashion to advertise the device or to exchange data with another device in a coordinated fashion. Even when you’re “connected” to a Bluetooth Low Energy device, the radio is only on periodically and there’s all sort of complicated orchestration to pull off keep things in sync between the two radios. One additional way to save lots of power whilst sleeping is to switch from the clock that drives the CPU (which in our case is 16Mhz and referred to as “HFCLK”; high-frequency clock) to one that just drives a counter that will wake up the CPU or other peripheral blocks on the silicon when necessary. This is called an LFCLK (low-frequency clock) in our world and can either be an RC oscillator included on the silicon, or an external “watch” (32.768KHz) crystal.
Due to some issues on the silicon revision of the Nordic nRF51822 we use inside our system-on-a-chip, two major things weren’t happening properly:
(1) The LFCLK included on the silicon wasn’t getting recalibrated periodically. The on-chip clock source is a resistor-capacitor network (an “RC oscillator” as they’re called). One of the interesting things about an RC oscillator is their frequency is partly a function of their temperature and temperature changes need to be compensated for with periodic recalibration. In fact, you can technically use an RC oscillator as a temperature sensor to exploit this phenomenon. Unfortunately, these recalibration routines were failing to work properly in our latest firmware due to the particular mix of silicon plus SDK plus SoftDevice (Bluetooth Smart radio stack).
(2) The nRF51822 is designed for aggressive power management and you can literally switch various “blocks” of the chip off to save power. These can be peripherals such as the UART, I2C/TWI lines, various onboard power supplies, the radio baseband itself, and even the crystal that drives the main ARM Cortex CPU (“HFCLK). Unfortunately, when we implemented fixes to get the LFCLK to be stabilized, a lot of our work to shut off various blocks on the chip fell to pieces — causing high current consumption, which would have caused battery-life woes.
If you’re spending most of your time asleep and using tiny amounts of current (~3-4uA) and only waking up periodically (every few hundred milliseconds) for short “bursts” where you use relatively high amounts of current (a couple of milliseconds using 1mA to ~20mA), you can keep going for a long time even on a relatively puny battery (a CR2450 coin cell, which has a capacity of about 620mAh, in our case). If for whatever reason you aren’t spending most of your time (99%+) sleeping, you suddenly start to see battery life disappearing rapidly as there is a huge (a factor) difference between sleep current and the various active states of current (~1-20mA) — especially if you happen to not be able to shut down the CPU clock source.
For our devices, we also have several housekeeping tasks that will wake up the CPU — everything from reading hardware sensors, to the data logger routines, calibration, alarm management, realtime clock management. We do a *lot* of things onboard compared to your average BLE tracker or similar device — you can get a glimpse into from the complexity of our profiles in our developers docs. These functions are all fairly aggressively power optimized too.
We’ve spent most of the week going back and forth with our Nordic application engineer and have now what we believe to be the right “constellation” of fixes. We also had to move from temperature-based recalibration of the internal LFCLK to a simple, periodic recalibration — which consumes more energy, but the temperature-based calibration just wasn’t working properly even after applying various “fixes”.
The following ‘scope trace might help illustrate things a little better for those interested (at least one person has asked for a technical explanation so far). This is a “healthy” power profile where we spend most of the time at ~3.5uA of power consumption and then periodically shoot up to ~1mA when the CPU is active and ~15-20mA when the radio is active. We basically want to see a flat line for the most part. A couple of days ago that flat line was pretty much where the peaks for active CPU were, which affected energy performance by about a factor of 500.
So, the long and the short of things:
– We believe we’re back in “good shape” as far as radio stability is concerned
– We believe we’re in reasonably good shape as far as power profiling is concerned, although it’s taken some effort to get there.
– To avoid any potential “battery-gate” incident, even though we don’t think that’ll happen, we’re including an additional CR2450 battery in the secret compartment inside each Wimoto inner carton, which also contains the Velcro pads for Climate and Sentry sensors to be attached to objects. See below for pictures illustrating where they’re hidden.
We’re hoping to ship several hundred Climate’s (first wave of what we can ship) next Friday. It will take some time to get to all the products, all the backers, and all the perks; so please, please, please be [a little more] patient and we’ll continue to try and set expectations on what’s going out.