Using the Lazy Soft Timer
This document describes the use of the lazy soft timer to optimize the application's current consumption.
Lazy Soft Timer
Lazy is perhaps a misleading term. According to the API Reference Guide,
“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.”
In other words, if the device wakes up for any other reason (e.g., radio wake-up or GPIO) between time and time+slack, the stack will also raise a soft timer event. If no other interrupt comes between the time and the time+slack, the soft timer event will wake-up the device at time+slack.
Saving Energy Using the Lazy Soft Timer
Each wake up has a fixed overhead. Looking at the EFR32BG1 data sheet, each wake-up from Deep Sleep (EM2) takes 10.7 us (table 4.9) and HFXO startup time is 300 us (table 4.32). This translates into energy consumed without executing any code and on every single wake-up.
Lazy soft timer packs more code execution into each wake-up period, reduces the overall need for additional wake-ups, therefore 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.4 MHz and that alone costs 49 uA or 65 uA per MHz (a total of 1.88 mA or 2.49 mA) depending on whether the DC/DC is 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.
Let's say that an application needs to read a temperature sensor every 100 ms. The exact timing is not important. This can be easily solved by applying a soft timer, either a traditional one or a lazy one:
// setting up traditional soft timer: gecko_cmd_hardware_set_soft_timer(TICKS_PER_SECOND / 10, 0, 0); // setting up lazy soft timer: gecko_cmd_hardware_set_lazy_soft_timer(TICKS_PER_SECOND / 10, TICKS_PER_SECOND / 10, 0, 0);
Because the sensor readout doesn’t need to be extremely accurate, slack is granted which equals the timeout of 100 ms so that the stack should always be able to sync this up to a radio wake-up on one of the connection intervals (providing that that connection interval is less than 100 ms).
Using the "traditional" soft timer, 3 peaks appear 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 1 ms with an average current consumption of 4.34 mA. For finalizing the metrics to compare against the lazy soft timer usage, let’s see what the overall average current consumption looks like.
On average 155 uA is used with 100 ms sampling rate of the ADC temperature sensor triggered by a soft timer and a connection to a master device with 100 ms connection interval.
When using the lazy soft timer, notice that the sensor readout peaks are gone.
The biggest difference comes on the average current consumption that goes from the original 155 uA to 115 uA, which represents an improvement of 25%.
If this was 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.
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, notice 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 enables syncing 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.