Yes, an RF receiver can run on batteries. The difficult part is keeping it ready for a command without spending the battery while it waits. A handheld remote can sleep between button presses. The receiver has a different job: it must catch a command that may arrive at any time.
For a battery-powered light, latch or small actuator, I would settle two questions before choosing the radio: how long must the battery last, and how long can the user reasonably wait after pressing the button? Those answers tell you more than a “low power” label.
“We only use it twice a day” does not settle the battery life
Infrequent operation helps only if the idle current is low. A receiver drawing 10 mA continuously uses 240 mAh every day, even if nobody touches the remote. An illustrative 2,000 mAh battery would last about 200 hours—just over eight days—before allowing for the load or losses.
That is an arithmetic estimate, not a battery-life rating. Usable capacity depends on chemistry, temperature, current profile and the voltage at which the device stops working. But the estimate is enough to reject a design intended to run for six months.
For a six-month target, using 180 days and an assumed usable capacity of 2,000 mAh, the whole device has an average-current budget of about 0.46 mA. The receiver, controller, power circuit and actual work all have to fit inside it. Leave margin; do not allocate the last microamp on paper.
Ask what “standby” actually means
On one quotation, standby means the receiver is listening continuously with its outputs off. On another, it means the radio is asleep and cannot receive an ordinary packet at that instant. These are different operating conditions.
As a reference, Texas Instruments lists a 200 nA sleep current and a lowest receive current of 14.3 mA for its CC1101 radio. Neither number is a finished receiver-board specification. They illustrate why the operating state matters. See the TI CC1101 product data and datasheet for the conditions behind those figures.
Ask the supplier for current measured at the complete board’s power input, at your intended supply voltage, while it is ready to accept commands. Then ask what response time that setting gives. A sleep-current figure on its own does not answer either question.
A sleeping receiver needs a transmitter that knows how to reach it
One approach is periodic listening: the receiver wakes briefly, checks for a transmission and goes back to sleep. TI describes this mechanism in its Wake-on-Radio application note. It is not continuous reception at sleep current.
The transmitter’s wake-up sequence and the receiver’s listening schedule must be designed together. Depending on the protocol, that can involve a long preamble or a coordinated train of repeated packets. Simply repeating an arbitrary command does not guarantee reception.
Timing sketch: why a brief command can disappear
Receiver: LISTEN → SLEEP → LISTEN → SLEEP → LISTEN
Short transmission: starts and ends inside SLEEP → missed.
Compatible wake-up sequence: reaches a LISTEN window → receiver stays awake → complete command is decoded.
Conceptual sequence only; durations and acquisition requirements depend on the implementation.
If the next listening window is nearly half a second away, the first response cannot be immediate. Reception and command processing add further time. Extending the sleep interval saves energy but can make a quick tap feel unreliable unless the transmitter handles the wake-up sequence after the tap.
My preference is to define the shortest normal button press and the longest acceptable response time before tuning sleep settings. Asking an operator to “hold it a little longer” is a poor substitute for a clear interface requirement.
The relay and the power LED may cost more than the radio
A low-power radio on a board with an always-on indicator, an unsuitable regulator and a continuously energized relay can still make a poor battery product. Check every current path that remains active while the equipment appears to be doing nothing.
Indicator LEDs: a continuous 1 mA indicator consumes 24 mAh per day. That alone exceeds the six-month average-current budget in the example above.
Relay coils: an ordinary non-latching relay needs coil power while energized. Count the actual on-time, not just the number of commands.
Regulators and converters: include quiescent current, conversion losses and behavior at light load. Measure from the battery side.
Drivers and peripherals: motor-driver standby current, sensors and resistor dividers still count when the radio sleeps.
A latching relay can reduce holding energy, but it retains its contact state when coil power disappears. That may be useful for a light and inappropriate for another output. Choose the required power-loss behavior first. Do not exchange predictable behavior for a better battery-life figure.
Do one daily energy calculation before ordering samples
Use currents measured at the same battery input. If you are combining measurements from different voltage rails, convert them to energy and include converter losses rather than adding the currents directly.
Here is a worked example with assumed values, not an ANRIVERS product specification:
Complete device waiting for commands: 0.15 mA for approximately 24 hours = 3.60 mAh per day.
Additional actuator current: 500 mA for 5 seconds, 20 times per day = 13.89 mAh per day.
Total: approximately 17.49 mAh per day, before any other operating overhead.
Assumed usable battery capacity: 2,000 mAh ÷ 17.49 mAh per day = approximately 114 days.
In this example, the actuator uses most of the charge. Reducing waiting current from 0.15 mA to 0.05 mA saves 2.4 mAh per day and extends the estimate to roughly 133 days. It helps, but it does not produce a year of service. If the output remains on for minutes instead of seconds, calculate that case before discussing a larger battery.
Measure a complete cycle, not the quietest number on the meter
A sleeping receiver draws pulses of current when it wakes. A steady display on a handheld meter can hide that activity. Use a current profiler, a suitable logging instrument or a properly selected shunt measurement to capture enough cycles to calculate the average. Check that the measurement setup does not introduce a voltage drop that changes the behavior being measured.
TI’s Current Consumption for a Polling Receiver is a useful engineering reference for accounting for the listening cycle rather than sleep alone.
For a sample evaluation, I would record these five conditions:
Quiet waiting: outputs off, normal firmware running, debug accessories removed. Record average input current over repeated wake cycles.
Ordinary use: short taps and longer presses at different points in the sleep cycle. Record missed commands and the slowest response, not just the average.
Output active: measure battery current and voltage through the full operation, including start-up peaks.
Installation traffic: repeat the waiting-current test at the intended site. Unrelated radio activity may extend listening or processing time, depending on the design.
Battery near its working limit: check reception and output operation at the specified low-voltage and temperature conditions. A board that still receives but cannot drive its load is already out of useful service.
What I would put in the enquiry
“Battery powered” is not a complete specification. Send the battery chemistry and voltage range, target service interval, operations per day, output current and on-time, acceptable button-to-output delay, and installation temperature range.
Then request two figures together: complete-board average waiting current and maximum response time in that same operating mode. Ask whether a matched transmitter is required and what changes when the output is active.
A battery-powered receiver is a reasonable choice when the waiting budget, command timing and load energy all agree. The useful specification is not the smallest current in the datasheet. It is how long the finished device does its job, with the response the user expects.