Duty-Cycled Radios and Preamble Sampling

A radio is usually the largest single load on a battery-powered wireless device, and the asymmetry is extreme: transmitting costs tens of milliamps for milliseconds, receiving costs a similar current for as long as the receiver is on, and idling costs a similar current for as long as the radio is powered. The receiver’s duty cycle, not the transmitter’s, sets the energy budget of a device that must be reachable at any time.

Why listening is the expensive part

A device that transmits a reading once per minute spends a few milliseconds per minute at tens of milliamps. A device that must accept a command at any time has to have its receiver on, and the receiver’s current is of the same order as the transmitter’s. Keeping the receiver on continuously therefore costs two to three orders of magnitude more than the occasional transmission.

The obvious fix is to turn the receiver off and agree on when it will be on. That agreement is the entire design space of duty-cycled media access, and every scheme in it is a different answer to the same question: how does a transmitter know when the receiver is listening, without a separate control channel.

The naive answer is time synchronisation. If every node shares a clock and a schedule, a transmitter can send exactly during the receiver’s listen window. The cost is the synchronisation itself: maintaining a shared clock across nodes requires periodic message exchange, and the exchange costs radio time on every node. The accuracy required grows with the sleep interval, because a clock error of 20 parts per million accumulates to 20 µs per second, or 72 ms per hour. Over a long sleep, the listen window must widen to cover the accumulated error, and widening it costs exactly the energy the scheme was meant to save.

Preamble sampling

The alternative removes synchronisation from the receiver side. The receiver wakes on its own schedule, opens a short listen window, and if it hears nothing, goes back to sleep. The transmitter, when it has data, sends a preamble long enough to overlap one of those windows, then the data. The receiver that catches the preamble stays awake to receive the frame.

The name comes from the mechanism: the receiver samples the channel for a preamble rather than for a frame. The preamble’s length is the critical parameter. If the receiver’s sleep period is $T_s$ and its listen window is $T_l$, a preamble of at least $T_s + T_l$ guarantees that every receiver hears it, because no receiver can be asleep for longer than $T_s$ without opening a window.

The cost moves to the transmitter. Sending a preamble for $T_s$ costs the transmitter’s current for that whole interval, and $T_s$ is set by the receiver’s sleep period, which is set by the receiver’s energy budget. A long sleep period on the receiver therefore makes every transmission expensive. This is the central trade of the family: receiver energy is exchanged for transmitter energy and for latency.

The latency is the other half. A transmitter that must send a preamble for a full sleep period delays delivery by up to that period, and the delay is not bounded by the receiver’s processing but by the protocol. For a sensor reporting a temperature once a minute, that is acceptable. For a device that must respond to an actuation command within 100 ms, it is not, and the receiver’s sleep period must be short enough that the preamble fits within the latency budget.

/* Transmitter side of preamble sampling: the preamble must cover one
   full receiver sleep period plus its listen window. */
static void send_with_preamble(const uint8_t *payload, size_t len)
{
    uint32_t preamble_us = RECEIVER_SLEEP_US + RECEIVER_LISTEN_US;

    radio_set_preamble_mode(true);
    radio_transmit_preamble(preamble_us);
    radio_set_preamble_mode(false);   /* the frame follows immediately */
    radio_transmit(payload, len);
    radio_wait_tx_done();
    radio_sleep();
}

The gap between the preamble ending and the frame starting is a protocol requirement, not an implementation detail: a receiver that detects the preamble needs time to switch from its sampling mode to its receive mode, and the switching time has to be covered by the preamble or by a short extension after it. Getting that wrong produces a link that works at close range and fails at the edge of the range, where the detection is later.

The variants and what each optimises

The basic scheme has a known inefficiency: every receiver that hears the preamble stays awake for the whole frame, even though the frame is addressed to one of them. On a network with many nodes in range, that is a large waste.

A common improvement sends a short wake-up beacon that carries the destination address, followed by the data only if the address matches. Receivers that are not addressed return to sleep immediately after the beacon. The beacon must still be repeated for a full sleep period to guarantee that the destination hears it, so the transmitter’s cost is similar, but the other receivers’ cost falls sharply.

Another variant lets the transmitter learn the receiver’s schedule. If the receiver’s wake time is predictable, the transmitter can send a short preamble that starts just before the window rather than a long one that spans the period. That recovers most of the transmitter’s energy, at the cost of the receiver’s schedule becoming observable and of the transmitter needing to maintain a table of schedules. It also reintroduces the synchronisation problem in a milder form, because the table’s entries drift.

A third variant puts the decision in the receiver: a receiver that hears a preamble can respond with an acknowledgement that tells the transmitter to proceed, or can stay silent to have the transmitter retry later. That gives the transmitter feedback on the link quality but adds a turnaround, and the turnaround time is the radio’s receive-to-transmit switching time, which is often a few hundred microseconds.

Numbers that set the design

The IEEE 802.15.4 standard fixes the frame structure and the modulation, and its receiver sensitivities and transmit powers define what a link budget can be. Its maximum frame size of 127 bytes, with a defined overhead, sets the payload available for application data. These are normative constants, and a protocol built on top of the standard inherits them.

The energy comparison follows from the currents. A receiver drawing 20 mA while listening, with a 1 percent duty cycle, averages 200 µA. A receiver drawing 20 mA continuously averages 20 mA. The ratio is the duty cycle, and the design question is what duty cycle the application can tolerate given the latency it permits.

The preamble cost is the reverse ratio. A transmitter drawing 20 mA for a preamble of one second spends 20 mC. A transmitter sending a 20-byte frame at 250 kbit/s spends about 640 µs, or 13 mC. The preamble therefore costs more than the frame by a wide margin when the receiver’s sleep period is a second, and that ratio drives every optimisation in the family.

Where the scheme fails

The first failure is the hidden terminal. A transmitter that begins a long preamble occupies the channel for the whole preamble, and another transmitter that cannot hear it may start its own transmission inside that window. Collision detection is not available during a preamble, because the preamble is not a frame. The usual mitigation is a random backoff before the preamble, which spreads the starts but does not eliminate the overlap.

The second is the energy cost of false wakeups. Noise that resembles a preamble wakes the receiver, which then stays awake for a frame that never comes. The probability of a false detection is set by the correlation threshold, and lowering the threshold to improve sensitivity raises the false rate. A receiver woken ten times more often than it has data has an effective duty cycle ten times its nominal one.

The third is the interaction with the rest of the device’s power states. The radio’s wake is an interrupt, and the core must be awake enough to service it or the radio must be able to receive into a buffer autonomously. If the core wakes for every preamble, the radio’s duty cycle is not the device’s duty cycle, and the core’s wake cost is added to every received frame. The pattern that avoids this is the one described in peripheral clock gating and autonomous transfer: the radio’s buffer is filled by the radio itself and the core is woken once per frame.

The fourth is that the scheme assumes all nodes run the same parameters. A network with mixed sleep periods has a transmitter that must satisfy the longest one, which makes the whole network pay for its slowest member. Protocols that negotiate the parameters exist, and they cost radio time to maintain.

The budget view

The honest way to compare schemes is to compute the energy per delivered frame, including the transmitter’s preamble, the receiver’s listening, and every node’s wake cost in between. For a network of N nodes each reporting once per period, the receiver-side listening dominates when N is large, and the transmitter-side preamble dominates when the period is long. The crossover is where the two are equal, and it moves with the number of nodes and with the traffic rate.

The measurement that matters is not the radio’s datasheet current but the average current of the assembled device over a full reporting cycle, which is the quantity described in the duty-cycle arithmetic. On a device where the radio is the dominant load, that number is essentially the radio’s duty cycle multiplied by its active current, and the protocol’s job is to make the duty cycle as small as the latency requirement allows.