Using the lazy soft timer

by <a href=""><font color="#000000"><font size="2">Legend Employee</font></font> </a> tmonte ‎09-04-2017 02:23 AM - edited ‎09-07-2017 02:09 PM


This article discusses the lazy soft timer and how you can use it to optimize your application’s current consumption.


Why is it lazy?

Lazy is perhaps a misleading term. No need to “re-write” the wheel, let’s see what the API Reference Guide has to say.


“This command can be used to start a software timer with some slack. Slack parameter allows stack to optimize wake ups and save power. Timer event is triggered between time and time + slack.”


What this means is that if the device wakes-up for any other reason (e.g. radio wake-up, GPIO) between time and time+slack then the stack will also raise a soft timer event. If no other interrupt comes between time and time+slack then the soft timer event will wake-up the device at time+slack.


How does this approach save energy?

The reason why this saves energy is that there is fixed overhead for each wake-up. Looking at the EFR32BG1 datasheet we can see that wake-up from Deep Sleep (EM2) takes 10.7us (table 4.9) and HFXO startup time is 300us (table 4.32). This translates into energy that is being consumed without executing any code and on every single wake-up.


The idea behind the lazy soft timer is to pack more code execution into each wake-up period and reduce the overall need for additional wake-ups, thus reducing the overall energy consumption.


This is especially useful when used with radio wake-ups. During TX/RX the SoC is most of the time in EM1 (CPU not running) and waiting for the radio TX/RX operation to be finalized. While doing this the HFXO is running at 38.4MHz and that alone cost 49uA or 65uA per MHz (a total of 1.88mA or 2.49mA) depending on whether the DC/DC is being used or not (tables 4.5, 4.6 and 4.7, EM1 current specs). When the stack raises a soft timer event right after a radio wake-up it allows a more efficient usage of the CPU which can execute application code instead of simply idling in EM1.


Practical example

This example is based on the Thermometer example with EFR32 internal temperature sensor but using a smaller sampling interval of 100ms. We then connect from a master device with a connection interval of 100ms (a second WSTK+BGTool or BLED112 as master gives control over the connection parameters) and subscribe to indications from the temperature measurement characteristic which starts the soft timer or lazy soft timer.


You can uncomment line 241 or 242 of main.c if you want to use the soft timer or lazy soft timer respectively.

//gecko_cmd_hardware_set_soft_timer(3276,0,0); // Uncomment this line to use the "regular" soft timer
gecko_cmd_hardware_set_lazy_soft_timer(3276,3276,0,0); // Uncomment this line to use the lazy soft timer 

Because the sensor readout doesn’t need to be extremely accurate we’re giving it a slack which equals the timeout of 100ms so that the stack should always be able to sync this up to a radio wake-up on one of the connection intervals.


Soft time vs Lazy soft timer

Using the “traditional” soft timer we can see 3 peaks in the current consumption.


The smallest peaks are the DC/DC refreshing. The tallest peak is the radio activity on a connection interval. The other 2 peaks are the soft timer wake-ups which trigger the ADC sensor readout. Let’s take a closer look at the sensor readout.


The sensor readout phase takes just under 1ms with an average current consumption of 4.34mA. For finalizing the metrics to compare against the lazy soft timer usage let’s see what the overall average current consumption looks like.


So on average we are using 155uA, with 100ms sampling rate of the ADC temperature sensor triggered by a soft timer and a connection to a master device with 100ms connection interval.


When using the lazy soft timer the first thing that’s noticeable is that the sensor readout peaks are gone.


And the biggest different comes on the average current consumption where we go from the original 155uA to 115uA, which represents an improvement of 25%.


If this would be a battery powered application it would translate into 25% more battery life. The difference between the average energy consumption can also be observed using the Energy Profiler tool built in to Simplicity Studio as shown below.



What is happening now is that the ADC sensor readout is done at the same time as the RX/TX radio operations when the CPU would otherwise be idling on top of a running (and power hungry) HFXO. Looking at the connection intervals we can see a small increase in the current consumption between using the soft timer and the lazy soft timer (upper and lower figure respectively).





The lazy soft timer offers the opportunity to sync up timer wake ups with other system wake ups which allows you to further optimize your system’s energy consumption when timer accuracy is not a requirement.