Low duty Cycle Mode#
Introduction and Motivation#
Low Duty Cycle (LDC, sometimes just Duty Cycle) by definition means switching something periodically on and off. However, in the context of low power radios, we usually use it for receive mode only. In this case, the radio is switching between a low power, long duration sleep state and short active states, wherein the radio is in receive state looking for valid preamble. In this way, the radio is able to save a huge amount of power.
Furthermore this operation is automatic, meaning no MCU intervention is needed for scheduling receive intervals, saving more energy. Typically an interrupt line or events are used to indicate a valid packet's arrival.
Synchronous and Asynchronous Duty Cycling#
Duty cycling radio protocols can be sorted into asynchronous or synchronous protocols. Asynchronous means that the receiver doesn't know when the transmitter would send a packet, while in synchronous mode. As its name implies, there is temporal synchronization between the two connected parts; the messages will be sent at a specified time.
Some widely used protocols use LDC (e.g. Bluetooth low energy) in synchronized networks. By spending energy and time for synchronization, the receiver can receive all the packets while it is in sleep state most of the time.
However, in some cases, the overhead required by the synchronization doesn't worth it, e.g. if you need to receive messages from a transmitter that rarely sends anything. In such cases, you probably want to use asynchronous duty cycling on the receiver, but in such cases the transmitter cannot predict when the receiver is listening. The goal of this KBA is to solve this problem, and explain how asynchronous LDC works.
In this document, the theoretical configuration of LDC will be illustrated with application examples (general use cases), and at last some implementation notes will be shown for both EZRadioPRO and EFR32 devices.
Theory of LDC#
The main idea behind the LDC is to move the power consumption of Rx to the Tx side. Though in LDC mode, both side are strongly dependent to each other focus on the Rx side first and assume an optimal Tx.
Rx Side Considerations - Preamble Detection Period#
To minimize the receiver's side average power consumption, the time spent in active state should be minimized. What's the minimum time to keep the receiver on? When and how could the receiver detect an incoming message? What is this event? There are more options for the receiver to detect an incoming message, but we concentrate only to the preamble detection case.
In preamble detection duty cycle mode the radio periodically wakes up for a short duration to look for a preamble. When a valid preamble is detected, the radio remains in receive state until the packet is fully received (or an error detected during reception).
Note that the original goal of the preamble is to achieve bit synchronization of the incoming signal (or to restore the clock signal in other words). Therefore, the preamble should always be at least as long as it needs to be to reliably achieve this task. Most radio's datasheets (Si4460/1/3/4 p. 28.) recommend selecting preamble length and preamble detection threshold (aka. preamble detection period), which is a minimal value to achieve 0% PER.
Define the following receiver time terms:
Tpdp: preamble detection period
Tron: receiver's active state time (it should be longer, than the preamble detection period)
Tsleep: receiver's sleep state time
and ignore other timing constraints, like wake-up time, radio state transition time, etc.
From this point, assume optimal Rx, and focus on the Tx side.
Tx Side Consideration - Application Examples - LDC in Asynchronous Networks#
There is tradeoff between the Rx side's and the Tx side's power consumption: longer sleep period infer longer transmission time (see the examples section).
There are two widely used scenario to ensure package reception on the receiver side in asynchronous networks, one called as "Duty cycle" mode, and the other is the "Master-slave" or "Master blast" mode.
Duty-cycle Mode#
This mode requires a packet with a very long preamble at the transmitter side. For the simplest example, assume the active time (Ton) and the sleep period (Ts) are given. In this case, the transmitter should have at least
Tpream = 2 * Tron + Tsleep
long preamble to make sure all packets will be received, independent of the receiver state when the transmission started. The rest of the packet is transmitted in Trest time.
In the worst case scenario, the transmitter starts transmitting slightly after the receiver wakes up, and does not provide long enough preamble for detection (Tpdp) in this wake-on period, continues the transmission during the receiver is in sleep state (Tsleep), and for the next active period (Tpdp+Trest), where the receiver finally detects the packet. This is shown in the picture below.
Compared to the case when the receiver is always in receive state, Duty-cycle mode saves approximately the duty-cycle proportion of power on the receiver side.
(Unsynchronized) Master-slave Mode#
The master term refers to the transmitter and the slave term to the receiver(s).
This mode has a similar idea, but instead of one packet with long period it uses transmit burst with short packets back to back, which transmit time, Tburst, should fit to Tpream determined in the Duty-cycle mode (the preamble length is much shorter in this mode but it has to fit to Tpdp time at least, and we will call it Tpream). Usually the rest of the packet (syncword, header, payload, CRC, etc.) is for Trest time in the air.
The slave must be in active state at least 2 * Tpream + Trest = Tron long, which is higher than in the Duty-cycle mode for ensuring packet reception for every case.
Comparison of Applications#
The downside of Duty cycle mode comes up when the radio wakes on the beginning of the preamble. This implies a long active period due to waiting for the whole packet. Furthermore, the radio has to handle if the preamble is lost, then reacquired due to interference. Finally, it's fairly easy for a malicious source to cause problems; it's easy to generate an infinite preamble.
On the other hand, with Master-slave mode the receiver only needs to be active for as long as it receives a single, short packet. The downside of Master-slave mode is that the receiver must be in active state as long as the longest possible packet is; otherwise it could miss the preamble of the packet.
Therefore the selection of application strongly depends on the protocol, or rather, the used protocol needed to define the LDC application mode.
Possible Improvements in Master-slave Mode#
With Master-slave mode, it is possible to improve the performance and energy consumption. For example, the transmitter could check for an ACK after each transmit. If the transmission was acknowledged, the transmitter can stop. The drawback with this is that this only works with a single receiver, and the active period of the receiver should be extended to include the time the transmitter spends to wait for an ACK.
Another method to improve Master-slave mode is to use a specific "wake-up" message, and not the actual data. This wake-up message only tells the receiver when the actual data will be transmitted and the receiver can wake-up again for that. This worsens the power consumption on both receiver and transmitter side, but the data length doesn't affect the active time on the slave any more.
Note About Preamble Detection Selection#
Low detection threshold may lead to misdetection and sensitivity loss, but halting the receiver longer in active state increases energy consumption.
Therefore the threshold should be good enough to achieve the required packet error rate. Note that the data rate may also impact on the threshold selection.
Implementation on EZRadioPRO#
EZRadioPro devices have a low frequency (32 KHz) clock system, called as WUT (Wake-Up Timer). It can be operated from an external or an internal clock source (see in the API documentation for GLOBAL_CLK_CFG register, CLK_32_SEL bit fields). The radio uses this clock during sleep state for generating wake-up signal (the WUT activity distinguishes between sleep and standby states), thereby WUT supports LDC mode (and Low Battery Detection as well) by hardware.
Registers with GLOBAL_WUT prefix related to this timer. Both the sleep period and the active period (documentation calls it LDC period) should be set with a mantissa (WUT_M and WUT_LDC bitfields) and a common exponent (WUT_R bitfields). The active period may be less than the configured LDC period, when a packet arrived before its expiration (as shown in the second picture). We signed LDC period as Tron and sleep period as Tsleep.
Next to the periods, the preamble detection threshold should be configured. It determines the number of valid preamble bits the radio must receive to qualify a valid preamble. A shorter Preamble Detection Threshold may be chosen if occasional false detections can be tolerated. This threshold can be set through the PREAMBLE_CONFIG_STD_1 register's RX_THRESHOLD bitfields, and all the other preamble related settings are located in the 0x10 Group of the registers.
After issuing a START_RX command, the radio's high frequency crystal should be started up, and the PLL requires some calibration time (see AN585 p.1.). This should be take into consideration to set the receive time correctly.
Further documentation:
LDC EZRadioPRO can be found in the AN585, which describes Master-slave mode more in depth.
How to set Tx preamble length and preamble detection period, for a frequency hopping application, but it can still used for an LDC application as well.
Implementation on EFR32#
EFR32 devices have LDC (although this feature called as Duty Cycle mode) implemented as part of Channel Hopping feature. The theory is similar to that, which was described for EZRadioPRO devices, but here is a simpler implementation, only two relevant APIs should to know:
RAIL_ConfigRxDutyCycle(): configures the mode and timing for the Duty Cycle operation
RAIL_EnableRxDutyCycle(): enables radio's receiver (RAIL_StartRX() or RAIL_ScheduleRx() API should be called after this).
RAIL_EVENT_RX_DUTY_CYCLE_RX_END: event triggered after a complete active-sleep period, where (RAIL_StartRX() or RAIL_ScheduleRx() should be called again
For complete documentation, visit the API documentation.
Note that the APIs do not put the MCU itself into sleep state. The easiest way to do that is to use the Power Manager service, which is fully supported by RAIL. This is documented in the Power Manager article.
Notes:
The RAIL_ConfigRxDutyCycle() and the RAIL_EnableRxDutyCycle() APIs are not supported on the EFR32XG1 family of chips, and in multiprotocol applications.
The RAIL_ConfigRxDutyCycle() and the RAIL_EnableRxDutyCycle() APIs must not be called while the radio is on.
There is a Duty Cycle example in the RAIL SDK, demonstrating the APIs above.