Wake-on-Radio vs Periodic Polling in Wireless Nodes

Key Takeaways

• Wake-on-radio wakes a node when a transmitter's wake-up preamble is detected by the radio itself.
• The wake interval, not the idle sleep current, sets both the worst-case latency and much of the average current.
• Periodic polling is simpler to build but pays one transmit and receive window per poll regardless of traffic.
• Match the transmitted preamble to the receiver's listen interval, or the node will miss frames intermittently.
• A module that lists a wake-up receive mode supports wake-on-radio directly; others need host firmware timing.

1. What Is Wake-on-Radio?

Wake-on-radio is a hardware receive mode in which a node's radio wakes for short listen windows and interrupts the host once a wake-up preamble confirms real traffic.

The host MCU takes no part in the detection decision, which is what separates wake-on-radio from any firmware polling scheme. Detection lives in the radio's duty-cycled receiver, while the host stays asleep until a confirmed frame is ready.

Core characteristics

• Preamble-triggered wake: the transmitter sends an extended wake-up preamble, and the receiver completes a wake cycle when that preamble correlates.
• Duty-cycled receiver: the radio sleeps between listen windows, so response timing lives in silicon rather than host firmware.
• Bounded wake latency: the worst-case delay to a delivered command is one wake interval plus preamble and payload time.
• Quiescent current sets the budget: the dominant draw is the listen-window average, not the microcontroller's deep-sleep current.
• No host timer in the receive path: firmware does not poll, because the radio raises the interrupt itself.

2. How Does Wake-on-Radio Work?

A wake-on-radio link is a timing contract between a duty-cycled receiver and a transmitter that over-sends its preamble on purpose.

1. The receiver sleeps between short listen windows. The radio wakes itself for a brief listen window at a fixed interval, typically a few milliseconds repeated about once per second. Current between windows sits in the microamp region, so the interval sets much of the average draw.
2. The transmitter sends an extended wake-up preamble. The preamble is longer than the receiver's listen interval, so at least one listen window falls inside it. That extra length is the mechanism, not overhead to trim.
3. The receiver confirms the preamble and holds the receiver on. Correlation detects the wake-up preamble and keeps the receiver active for the frame that follows.
4. The host MCU is woken by interrupt. Once the preamble is confirmed, the radio asserts an interrupt and lifts the microcontroller out of sleep, so the host pays active current for real frames rather than background noise.
5. The node answers and returns to its listen pattern. The host reads the payload and replies if required, at the energy cost of any radio in the same power class. A short interval then reacts fast and drains the cell fast, which the decision rule below balances.

3. What Is Periodic Polling?

Periodic polling is a receive strategy in which the host MCU wakes on a timer, powers the radio, sends a request and waits for a bounded reply before sleeping again.

Nothing in the receive path is automatic: the firmware sets the cadence, drives the radio and interprets the silence when no peer answers.

Core characteristics

• Timer-driven host wake: a real-time clock alarm brings the MCU out of stop mode at a fixed interval, with timing authority held in firmware.
• Latency floor equals the poll interval: a command arriving just after a poll waits almost a full interval, so worst-case response is the poll period plus the exchange.
• Fixed cost per poll: each cycle is one transmit and one receive window, so an idle network pays the same energy as a busy one.
• Self-contained implementation: any radio with basic transmit and receive ability works, with no special preamble handling in the modem.

4. Wake-on-Radio vs Periodic Polling: What Is the Difference?

Both strategies solve the same downlink problem, but they split the work differently between the radio and the host.

The decision rule: choose wake-on-radio when a command must land within seconds with no mains supply; choose duty-cycled polling when the radio lacks a wake-up receive mode, when the downlink is predictable, or when firmware must own the cadence.

5. Wake-on-Radio Configuration and Key Parameters

These are the parameters that decide whether a wake-on-radio node meets its battery-life target and still reacts in time.

• Listen interval versus preamble length: the transmitted preamble should be at least one listen interval longer than the receiver's wake period. Too short, and frames are missed intermittently.
• Sleep current in the microamp region: measure the whole board, not just the radio, where a single pull-up can dominate a 2 uA sleep current.
• Wake latency: budget one wake interval plus preamble and payload time. When that exceeds the limit, speed up the listen window rather than shortening the interval.
• Transmit duty cycle and regulatory limits: check the band's duty-cycle allowance before raising reply rates, because a crowded band is unreliable.
• Battery capacity and self-discharge: size the cell for the average listening current, since self-discharge and cold-temperature loss can exceed the load.
• Timeout on the host wait loop: keep the receive timeout longer than the poll or preamble interval, or the host sleeps before the frame arrives.
• False wake rate: log interrupts that yield no valid frame, because a rising rate points to interference or a loose preamble threshold.
• Antenna and receive sensitivity: the antenna is part of the detection chain, and a weak link degrades preamble detection before payload throughput.
• Supply decoupling during a wake transient: place bulk capacitance at the radio supply pin, since a wake current step can reset a starved rail.

6. When to Use Wake-on-Radio and When Not To

Good fit for wake-on-radio

• Battery nodes that must accept a command within seconds, such as a valve that acts on demand.
• Links that stay idle for long periods and carry occasional short downlinks.

Good fit for periodic polling

• Predictable downlinks, such as a scheduled setpoint push or a daily configuration refresh.
• Designs on a radio without a wake-up receive mode, where changing the modem is not justified.

Poor fit for wake-on-radio

• Mains-powered nodes, where listening current buys nothing and a permanent receiver is simpler.
• Links with continuous downlink traffic, which a duty-cycled receiver cannot sustain.

Poor fit for periodic polling

• Nodes that must react within seconds while holding a multi-year battery target.
• Installations whose poll cadence is short enough that transmit windows dominate the energy budget.

7. Real-World Applications

In remote monitoring and building control, downlink commands arrive rarely but are expected to take effect quickly, which is where a wake-up receive mode earns its place.

Ebyte modules in the LoRa UART family cover both ends of that trade-off. The E22-400T22D-V2, built on the Semtech SX1268, is a DIP LoRa UART wireless module that lists wake-on-radio (WOR), listen-before-talk (LBT) and relay networking, with adjustable 22 dBm output, up to 5 km open-air line-of-sight, TTL UART compatible with 3.3 V and 5 V MCU IO, a wide 2.3-5.5 V supply and an ultra-low 2 uA sleep current. The E220-900T22S, an LLCC68 based LoRa UART wireless serial port module, is offered with a wake-up-on-radio (WOR) operating mode, 22 dBm output, a 5 km figure and IPEX or stamp-hole antenna options. Where more reach is needed, the E220-400T30S and the E22-900T30S-V2 both reach 10 km in their listed power classes. For battery sensors with no downlink need, the E43-900T13S3 covers 855-931.5 MHz at 13 dBm with a 1.5 km figure, and the E220-900T30D brings TTL level output compatible with 3.3 V and 5 V IO. Where Wi-Fi infrastructure exists, the E103-W03 serial-to-Wi-Fi module offers a 12 uA hibernate sleep current and an AT command interface with MQTT.

One physical detail decides more field results than the module choice: the antenna and its feed line set the receive sensitivity that preamble detection depends on, and the datasheet range assumes an installation a cabinet rarely provides. Keep the antenna clear of metal and verify detection at the real distance rather than on the bench.

8. FAQ: Wake-on-Radio in Practice

Q1: What is wake on radio and how does it differ from polling?

Wake on radio keeps a receiver in short, periodic listen windows and wakes the host after a wake-up preamble confirms real traffic. Polling has the host wake on a timer, transmit a request and wait for a reply. Wake-on-radio puts the timing in the radio; polling keeps it in firmware.

Q2: How much current does wake-on-radio save compared with polling?

It depends on the listen interval, the radio's listening current and how often the node receives. A duty-cycled receiver can sit in the low microamp region between frames, while each poll costs a full transmit and receive window. With little downlink traffic, that gap drives battery life.

Q3: Why does my wake-on-radio node miss commands?

Missed commands usually mean the preamble and listen timing are not matched, or the link is too weak for reliable preamble detection. Check the likely causes in this order:

• Intermittent missed commands -> confirm the wake-up preamble is longer than the receiver's listen interval.
• Commands missed only at range -> check the antenna, the feed line and the receive sensitivity.
• Commands missed after a while -> check for a rising false wake rate and a host timeout expiring too early.

Q4: How do I choose the wake interval?

Set it from the worst-case response time the application can accept, then measure the average current. A shorter interval lowers latency and raises listening current in roughly linear proportion, so choose the longest interval that still meets the response requirement. Verify the choice at the temperature extremes the node will see.

Q5: Can I use wake-on-radio with any radio module?

No. The duty-cycled listen and preamble detection must be implemented in the radio, so a module that lists a wake-up receive mode supports it directly. A module without that feature can still be polled, but the timing then lives entirely in the host MCU.

9. Practical Checklist Before You Design the Wake Cycle

Work through these five checks before fixing the wake timing in firmware.

1. Match the preamble to the listen interval. Confirm the preamble is longer than the receiver's wake period, with margin for both devices' timing tolerance.
2. Measure the whole board, not just the radio. Characterise sleep and listening current on the real PCB with the antenna fitted, since regulator and pull-up current can exceed the radio's draw.
3. Set the interval from the response requirement. Choose the longest interval that meets the worst-case latency target, then check average current against usable cell capacity and derating.
4. Confirm the radio supports a wake-up receive mode. Treat the scheme as wake-on-radio when the module lists that feature; otherwise the timing sits in the host MCU.
5. Plan for false wakes and link margin. Log interrupts that yield no valid frame, and test preamble detection at the installed distance.