Difference between revisions of "CCxx00 Wake-on Radio"
(→Recommendations) |
|||
Line 1: | Line 1: | ||
[[Image:wor_cs.png|frame|Receive check with carrier sense]] | [[Image:wor_cs.png|frame|Receive check with carrier sense]] | ||
+ | |||
+ | [[Image:wor_energy.png|thumb|Measured CC2500 Energy Consumption [mAh/day] vs. Wake-on Radio Receive Check Interval]] | ||
Wake-on Radio is a hardware implemented version of low power communications. It allows your microcontroller to completely go to sleep while your radio duty cycles on its own. | Wake-on Radio is a hardware implemented version of low power communications. It allows your microcontroller to completely go to sleep while your radio duty cycles on its own. |
Revision as of 16:01, 27 February 2008
Wake-on Radio is a hardware implemented version of low power communications. It allows your microcontroller to completely go to sleep while your radio duty cycles on its own.
Hardware controlled receive checks operating automatically on the radio are extremely efficient, especially because physical-layer carrier sense information is incorporated into each receive check.
Contents
CCxx00 Wake-on Radio Design and Implementation
Wake-on Radio is implemented differently in the TinyOS CCxx00 driver than is described in TI's applications notes [1] [2].
The goal of this implementation was to get each receive check as short as possible to extend the life of a wireless network performing idle receive checks most of the time. To do this, receive checks are programmed to go asleep immediately if no carrier is detected within 8 symbol periods (MCSM2.RX_TIME_RSSI=1). We also wanted to transmit full packets of information, instead of the 1- or 2- byte packets used in TI's Wake-on Radio application note examples.
This design requires a transmitter to produce a long, continuous wake-up signal, characteristic of B-MAC. The CCxx00 radios handle this well, because they'll automatically produce an infinite preamble simply by kicking the radio into TX mode.
The CCxx00 transmit branch in TinyOS will tell the radio to begin transmitting a preamble, then start a timer that will later inject packet information into the radio. The timer's duration is a few milliseconds longer than the receive check interval of the destination node. This means the radio actively transmits a preamble for the duration of the timer that is set, and during that preamble transmission, all duty cycling receivers in the vicinity are awakened. While the radio is sending out its long preamble, and before the timer fires, the microcontroller is free to go to sleep. When the timer finally fires, the actual packet information is injected into the TX FIFO which transmits the packet. The duty cycling receivers that have been woken up by the long preamble acquire the packet information and then alert the microcontroller.
If at any time the carrier wave disappears, the radio is automatically put back into WoR mode. The register settings determined through experimentation help assure this is the case. Functionally, after a packet is transmitted or received in the radio stack, WoR is re-enabled.
Side-effects
The preamble is not addressed. This means all nearby receivers are woken up when a transmitter is trying to get packet information through. It also makes it relatively easy to perform a Denial of Sleep attack, simply by modulating a carrier on the frequency the radios are listening on.
It may be possible, with an improved transmission and reception strategy, to maintain a continuously modulated channel while transmitting an addressed "preamble". This would let non-destination nodes go back to sleep quickly.
Recommendations
This scheme shifts the power consumption to transmitters. Transmitters must transmit a packet for long amounts of time due to the required long wake-up preamble. To mitigate this, we recommend you keep preamble transmissions as short as possible. In order to use shorter wake-up preambles, we recommend using a receive check interval of 50-250 milliseconds. Wake-on radio driven receive checks are so efficient that shorter receive check intervals do not mean large increases in energy consumption. Your networks will be able to achieve high throughput with high energy efficiency.